SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsexternal-cannbot-ops-ascendc-code-review

external-cannbot-ops-ascendc-code-review

Coding & development

View repository

Updated 10-15 17:19

About this skill

Ascend C Code Review Skill

Core Principles

  1. Compliance Mapping - All review actions are mapped to specific clauses of the coding specifications, ensuring 100% coverage
  2. Hypothesis Testing Driven - Adopt the hypothesis testing methodology, systematically collect evidence to determine risks
  3. Auditable and Reusable - The entire review process is logged, and the evidence chain is complete and traceable

Invocation Interface

Required Parameters

When invoking this skill, the following parameters must be explicitly provided:

Parameter 1: Code Snippet

  • The code content to be reviewed
  • Can be a function, code block, file content, etc.

Parameter 2: Review Rule Description

  • Explicitly specify the type of issue to be reviewed
  • For example:检查整数溢出、检查内存泄漏、检查空指针解引用, etc.
  • Or specify a specific specification file path

Parameter 3: Specification File Path(Optional)

  • Specify a specific coding specification file path
  • If not specified, the default is references/cpp-secure.md(Secure Coding Specifications)

Parameter Validation

If any required parameter is missing, you should:

  1. Clearly notify the user which parameters are missing
  2. Abandon the review
  3. Prompt the user to provide complete parameters

Specification Document System

I. General Rules

Document Name Document Path Review Scope Applicable Scenarios Number of Clauses
C++ Secure Coding Specifications references/cpp-secure.md Numeric safety, memory safety, input validation, resource management, concurrency safety C++ code security review 47 clauses
Python Secure Coding Specifications references/python-secure.md Numeric safety, exception handling, file operations, serialization, command execution, network security Python code security review -
C++ Code Style Specifications references/cpp-style.md Naming rules, formatting specifications, comment specifications C++ code style and readability review -
C++ General Coding Specifications references/cpp-general.md 15 categories of specifications including code design, data types, function design, etc. C++ code quality and maintainability review 46 clauses
Secure Compilation Specifications references/compile-secure.md ASLR, stack protection, read-only GOT, immediate binding, non-executable stack Compilation configuration and build script review (Tiling side only) 7 clauses
Ascend C API Best Practices references/ascendc-api.md API blacklist, alignment requirements, pairing checks, restriction constraints Ascend C API usage review (Kernel side only) 9 clauses
Ascend C High-Performance Programming references/ascendc-perf.md Performance optimization, precision standards, Tiling design Ascend C high-performance programming review (Kernel side only) 12 clauses
TOPK Issue Checklist references/ascendc-topk.md Host-side high-frequency issues, attribute acquisition, special value handling, inter-core synchronization Key operator development review points 13 items
SIMT API C-style conventions references/simt-api-analysis.md C++-style API to C-style API conversion, variable name conflicts, header file locations SIMT kernel code API review (Kernel side only) 13 items

II. Domain-Specific Rules

Important: For domain-specific rules, you must first analyze the applicable scenario to which the code belongs, and then enable the corresponding domain review rules; they should not be unconditionally fully enabled.

Document Name Document Path Review Scope Applicable Scenario Number of Clauses
MC² Domain Rules references/mc2-specific.md Communication synchronization, MoE expert routing, quantization precision, hardware constraints, HCCL communication and security Code review for MC² (Matrix Computation & Communication) computation-communication fusion operators. Enable when core features (C1~C2) are met and it does not belong to an excluded scenario. For review methods, see references/mc2-specific.md the "PR Diff→Rule Quick Reference" table 19 items

API Documentation Retrieval

Important: When reviewing API usage involved in Kernel code, you must use the /ascendc-docs-search skill to consult API documentation; it is prohibited to judge from memory or speculation.

Core APIs to Consult During Review

API Category Specific API Review Focus
Data Movement DataCopy, DataCopyPad Alignment requirements, synchronization mechanisms
Memory Management InitBuffer, AllocTensor, FreeTensor, EnQue, DeQue Pairing requirements
Vector Computation Add, Sub, Mul, Div, Cast Parameter limits, precision handling
Reduction Operations ReduceSum, ReduceMax Intermediate precision protection
SIMT Thread Management GetThreadNum, GetThreadIdx, GetBlockIdx, GetBlockNum C++ style→C style conversion, dimension selection
SIMT Math Operations UintDiv, Min, Max, Floor, Ceil, Abs C++ style→C style conversion, UintDiv retention
SIMT Kernel Function Invocation VF_CALL, Dim3 C++ style→C style conversion
SIMT Atomic Operations AtomicAdd, AtomicSub C++ style→C style conversion
SIMT Synchronization ThreadBarrier C++ style→C style conversion

How to Consult: Call the /ascendc-docs-search skill and enter the API name to obtain the official documentation.

Review Process (Hypothesis-Testing Driven)

Phase One: Preparation

  1. Verify whether required parameters are complete
  2. Read the coding specification file according to the review rule description or specified path
  3. Confirm the code snippet to be reviewed
  4. Select the applicable specification document：
    • C++ code security: use cpp-secure.md
    • Python code security: use python-secure.md
    • Code style quality: use cpp-style.md or cpp-general.md
    • Compilation configuration: use compile-secure.md
    • SIMT kernel API: use simt-api-analysis.md
  5. Preparatory Learning for Kernel Code Review：
    • If the code to be reviewed involves the Kernel side (Device side), you must use the /ascendc-docs-search skill to consult API documentation
    • Commonly consulted APIs:DataCopy、DataCopyPad、EnQue、DeQue、Cast , etc.
    • SIMT kernel code requires consulting:GetThreadNum、GetThreadIdx、UintDiv、VF_CALL etc.
    • It is forbidden to judge the correctness of API usage from memory or speculation

Phase 2: Hypothesis Testing (Core)

Step 1: Code Segment Identification

Divide the target code into independent code segments (functions, statement blocks, logical units)

Step 2: Hypothesis Establishment

Establish a hypothesis for each code segment:

  • Null hypothesis H0: This code segment is safe
  • Alternative hypothesis H1: This code segment has risks
  • Confidence value initialization：0%

Step 3: Evidence Collection and Evaluation

Systematically search for evidence by dimension:

Evidence Type Analysis Action Score Rule
Specification violation Identify violation points against specification clauses Valid evidence +40%
Missing contextual defense Check whether there is defensive code within the scope No defense +30%
Function call chain risk Use LSP/Grep to analyze the internal logic of called functions Risk found +25%
Data flow tracing risk Analyze variable sources and computation processes Risk found +25%

Analysis Requirements：

  • Use LSP to obtain symbol definitions in the code, and use Grep to find dependencies
  • For risky code, it must be checked whether defenses exist elsewhere within the current file scope
  • When encountering a function call, the function's internal logic must be examined and comprehensively judged
  • When encountering a risky struct or member variable, its definition and computation process must be examined
  • For basic Ascend C API usage, you must use the /ascendc-docs-search skill to consult the official documentation; it is forbidden to rely on memory or speculation
  • Regulation customization requirements: If the regulation includes dedicated review methods or mandatory requirements, it must be strictly executed according to the guidance of that regulation

Step 4: Evidence Validity Verification

Eliminate false positives:

  • Effective defense has already been performed elsewhere in the scope → eliminate
  • The context can prove that the risk cannot be triggered → eliminate

Step 5: Decision Judgment

Calculate the confidence value and make a decision:

  • Confidence value = Σ valid evidence scores
  • Decision rule: When the confidence value exceeds 60%, determine that the code segment has risks and proceed to report generation; otherwise continue checking the next code segment

Phase 3: Report Generation

If the caller (such as ascendc-ops-reviewer) explicitly requires that no report file be generated, skip this phase and only return the item-by-item review results.

  1. Generate the report according to the code review report template format
  2. Before each issue detail, display the hypothesis testing process (evidence chain and confidence value calculation process)
  3. Clearly mark the clause numbers of violated specifications and the source documents

Notes

  1. Please first read the corresponding coding specification files completely, and conduct the code review according to these specifications; nothing else is counted
  2. During the review process, if a questionable code block contains function call behavior, LSP or search tools must be used for in-depth analysis
  3. Before reviewing Kernel code, you must use the /ascendc-docs-search skill to learn the Ascend C basic API documentation: Obtain the official documentation for core APIs such as DataCopy, EnQue/DeQue, Cast, etc. It is forbidden to judge based on memory or speculation.
  4. Before reviewing SIMT kernel code, you must consult references/simt-api-analysis.md: Understand the conversion rules from C++ style APIs to C style APIs, with special attention that UintDiv must be retained.
  5. For uncertain coding standard issues, list them in the output report in the form of doubts for the user to judge independently.
  6. The problematic code listed in the review report should not be too long; it is sufficient to describe the problematic code clearly.
  7. When returning the review results, you must carefully check whether the line numbers of the risky code lines in the results are correct.
  8. When returning the review results, all risky code blocks should be referenced; you cannot show only one line number.

Red-line issues

Host-side red-line issues

  1. Host-side code must provide divide-by-zero protection for division and modulo operations.
  2. Host-side code array access must provide out-of-bounds protection.
  3. Host-side code addition, multiplication, and subtraction operations must provide overflow and underflow protection.
  4. Host-side code pointer operations must be assigned before access and must provide pointer protection. For example, const bool* getLogtarget = attrs->GetAttrPointer(LOGTARGET_INDEX); this->logTarget_ = *getLogtarget; this operation has no pointer protection.
  5. Before variables are used, they must be effectively initialized. For example, class member variables need to be initialized.
  6. The application, use, and release of resources must match.

Kernel-side red-line issues (SIMT API)

  1. SIMT kernel code must convert C++ style APIs to C style APIs (such as GetThreadNum → blockDim.x）
  2. Simt::UintDiv must be retained; conversion is forbidden (officially specified, no C style replacement).
  3. Variable names cannot be named threadIdx、blockIdx、blockDim、gridDim(conflicts with C style APIs).
  4. Header file simt_api/asc_simt.h must be outside the namespace.
  5. After conversion, it must pass compilation verification to ensure there are no compilation errors.

TOPK issue listSee details:references/ascendc-topk.md(including 13 high-frequency review issues, indicating the applicable scope of Host/Kernel).

SIMT API C-style specificationSee details:references/simt-api-analysis.md(including 13 API conversion rules, applicable only to the Kernel side).

Output specification

The review report must include

  1. Review category (indicating the source of the specification)
  2. Risk point list (including line numbers and code snippets)
  3. Evidence chain (showing the hypothesis testing process)
  4. Suggested fix
  5. Specification clause citation (indicating the clause number and source document)

Output format

See details: agents/ascendc-ops-reviewer/style/code_review_summary_style.txt