Code processing methods, systems, devices, storage media, and software products

Abstract

This application discloses a code processing method, system, device, storage medium, and software product. The method includes: acquiring code to be processed and generating an intermediate representation; constructing a logical dependency structure based on the intermediate representation; converting the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture; setting weights for nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters; determining execution path data in the execution-level dependency structure based on the weights, and outputting the execution path data for subsequent code processing. This application enables performance analysis to be completed statically at compile time, without actually running the analyzed program on the target hardware or relying on performance monitoring facilities of a specific operating system. It achieves compile-time performance analysis across operating systems and runtime environments, raising the analysis granularity to the instruction and microarchitecture levels, and directly revealing the underlying critical paths that determine program execution time.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a code processing method, a code processing system, an electronic device, and a computer-readable storage medium / computer software product. Background Technology

[0002] With the increasing importance of hardware-software co-design, performance optimization of software on different hardware platforms, especially heterogeneous hardware in various embedded and edge computing scenarios, has become a significant challenge. Existing performance analysis techniques are mainly divided into two categories: dynamic analysis tools and static analysis tools. Dynamic analysis tools, represented by Linux platform performance analysis tools such as Performance Events (perf) and the GNU Profiler (gprof), sample and collect runtime data by actually running the program on the target hardware, using hardware performance counters or code instrumentation to generate function-level heatmaps, thereby guiding developers to optimize the most time-consuming functions. Static analysis tools include analyzers integrated with compilers and integrated development environments (IDEs), capable of checking for potential performance problems in the code at compile time, such as redundant computations or inefficient loops. However, this type of analysis is usually based only on source code or intermediate representations (IR), lacking precise modeling of the microarchitectural characteristics of the target hardware.

[0003] Existing performance analysis techniques have significant limitations. For example, the performance analysis tool perf heavily relies on the Linux operating system kernel and is tightly coupled with its scheduler and process management modules, making it unsuitable for real-time operating systems (RTOS) because these systems typically lack similar performance monitoring infrastructure. Furthermore, dynamic tools like perf can only be used at runtime, requiring the target program to be actually executable on specific hardware, severely limiting their applicability in cross-compilation or embedded development scenarios. In terms of analytical granularity, existing tools only provide overviews at the function or basic block level, failing to delve into the instruction level or microprocessor microarchitecture. For instance, they cannot analyze the latency, throughput, or functional unit conflicts of individual instructions, making it difficult to identify underlying bottlenecks in the program's critical path and hindering developers from efficiently locating and resolving the root causes of performance bottlenecks. Summary of the Invention

[0004] The purpose of this application is to provide a code processing method, a code processing system, an electronic device, and a computer-readable storage medium / computer software product, which can solve the problems of existing technologies that must rely on target hardware to run, heavily depend on specific operating system support, and whose analysis granularity is limited to the function or basic block level and cannot reveal the true performance bottlenecks at the microarchitecture level.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a code processing method, the method comprising: Obtain the code to be processed and generate an intermediate representation; Construct a logical dependency structure based on the intermediate expression form; Convert the logical dependency structure into the execution-level dependency structure corresponding to the target environment architecture; Weights are assigned to nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters; The execution path data is determined in the execution-level dependency structure based on the weights, and the execution path data is output for subsequent code processing.

[0006] Optionally, converting the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture includes: Re-decode the low-level instructions generated by the compiler backend; Each low-level instruction obtained from re-decoding is decomposed and mapped into a sequence of operations of one or more execution units within the target execution hardware; The execution-level dependency structure is constructed based on the execution unit operation sequence and the data and resource dependencies between the execution unit operation sequences.

[0007] Optionally, setting weights for nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters includes: Access a pre-built database of execution hardware models; Based on the parameters in the database, latency weights are assigned to nodes in the execution-level dependency structure, and minimum interval period weights determined by throughput or resource conflicts are assigned to edges.

[0008] Optionally, the database includes at least one of the following parameters obtained by benchmark testing for the target execution hardware: latency for each micro-operation or micro-operation category; throughput of each execution unit and execution port; and functional unit resource conflict and port allocation rules.

[0009] Optionally, determining execution path data in the execution-level dependency structure according to the weights and outputting the execution path data for subsequent code processing includes: In the execution-level dependency structure that has been assigned the delay weight and the minimum interval period weight respectively, the delay critical path and the resource critical path are calculated respectively using a dynamic programming algorithm based on topology sorting. The larger value between the delay critical path and the resource critical path is taken as the theoretical minimum number of execution cycles for the current code segment. At least one of the delayed critical path, the resource critical path, and the theoretical minimum number of execution cycles is presented in the form of a visual dependency graph, hotspot annotation, or analysis report for subsequent code processing; wherein, the delayed critical path is the longest path obtained with the delay weight as the path length; the resource critical path is the longest path obtained with the minimum interval cycle weight as the path length.

[0010] Optionally, the method is applied during the compiler compilation process through a non-intrusive interactive framework, the interactive framework comprising: The compiler manages modules and interactive event mechanisms; A compiler interaction plugin loaded as a dynamic library; wherein the compiler interaction plugin is used to be triggered at least one pass stage of the compiler through predefined low-level interaction interfaces and application-level interaction interfaces; the compiler interaction plugin is also used to dynamically adjust the construction granularity of the logical dependency structure and the loading strategy of the hardware performance parameters according to the detected compiler compilation flags; the compiler interaction plugin is also used to perform at least one of the following operations after being triggered: construct the logical dependency structure in the intermediate expression stage; perform re-decoding and construct the execution-level dependency structure after the low-level instructions are generated; read the hardware performance parameters from the execution hardware model database and perform weighted calculation of the nodes and the edges; perform critical path calculation and output an analysis report.

[0011] Optionally, the execution hardware model database includes measured hardware performance parameters of the processor used in the target real-time operating system or bare-metal environment.

[0012] Secondly, embodiments of this application provide a code processing system, the system comprising: The intermediate representation generation module is used to obtain the code to be processed and generate intermediate representations. A logical dependency structure construction module is used to construct a logical dependency structure based on the intermediate expression form; An execution-level dependency structure conversion module is used to convert the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture. The weight setting module is used to set weights for nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters. The execution path data determination module is used to determine the execution path data in the execution-level dependency structure according to the weight, and output the execution path data for subsequent code processing.

[0013] Optionally, the execution-level dependency structure transformation module includes: The recompile module is used to re-decode the low-level instructions generated by the compiler backend; The decomposition and mapping module is used to decompose and map each low-level instruction obtained from the re-decoding into a sequence of operations of one or more execution units within the target execution hardware; An execution-level dependency structure component module is used to construct the execution-level dependency structure based on the execution unit operation sequence and the data and resource dependencies between the execution unit operation sequences.

[0014] Optionally, the weight setting module includes: The database access module is used to access a pre-built execution hardware model database; The weight assignment module is used to assign latency weights to nodes in the execution-level dependency structure and minimum interval period weights determined by throughput or resource conflicts to edges, based on parameters in the database.

[0015] Optionally, the database includes at least one of the following parameters obtained by benchmark testing for the target execution hardware: latency for each micro-operation or micro-operation category; throughput of each execution unit and execution port; and functional unit resource conflict and port allocation rules.

[0016] Optionally, the execution path data determination module includes: The path calculation module is used to calculate the delay critical path and the resource critical path respectively in the execution-level dependency structure that has been assigned the delay weight and the minimum interval period weight, using a dynamic programming algorithm based on topology sorting. The cycle number determination module is used to take the larger value between the delay critical path and the resource critical path as the theoretical minimum execution cycle number of the current code segment; The path presentation module is used to present at least one of the delayed critical path, the resource critical path, and the theoretical minimum number of execution cycles in the form of a visual dependency graph, hotspot annotation, or analysis report for subsequent code processing; wherein, the delayed critical path is the longest path obtained with the delay weight as the path length; the resource critical path is the longest path obtained with the minimum interval cycle weight as the path length.

[0017] Optionally, the system is applied during the compiler compilation process through a non-intrusive interactive framework, the interactive framework comprising: The compiler manages modules and interactive event mechanisms; A compiler interaction plugin loaded as a dynamic library; wherein the compiler interaction plugin is used to be triggered at least one pass stage of the compiler through predefined low-level interaction interfaces and application-level interaction interfaces; the compiler interaction plugin is also used to dynamically adjust the construction granularity of the logical dependency structure and the loading strategy of the hardware performance parameters according to the detected compiler compilation flags; the compiler interaction plugin is also used to perform at least one of the following operations after being triggered: construct the logical dependency structure in the intermediate expression stage; perform re-decoding and construct the execution-level dependency structure after the low-level instructions are generated; read the hardware performance parameters from the execution hardware model database and perform weighted calculation of the nodes and the edges; perform critical path calculation and output an analysis report.

[0018] Optionally, the execution hardware model database includes measured hardware performance parameters of the processor used in the target real-time operating system or bare-metal environment.

[0019] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium / computer software product, wherein a program or instructions are stored on the computer-readable storage medium, and the program or instructions, when executed by a processor, implement the steps of the method described in the first aspect; the computer software product includes a computer program, the computer program is stored on the computer-readable storage medium, and the computer program, when executed by a processor, implements the steps of the method described in the first aspect.

[0021] In this embodiment, by acquiring the code to be processed and generating an intermediate representation during the compilation phase, constructing a logical dependency structure based on the intermediate representation, converting the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture, and then setting weights for nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters, and determining and outputting execution path data in the weighted execution-level dependency structure, the performance analysis is completed statically at compile time without actually running the analyzed program on the target hardware or relying on the performance monitoring facilities of a specific operating system. This overcomes the shortcomings of existing technologies that can only perform analysis at runtime, in a specific operating system environment, and only provide coarse-grained analysis at the function or basic block level. It achieves compile-time performance analysis across operating systems and runtime environments, and elevates the analysis granularity to the instruction and microarchitecture levels, directly revealing the underlying critical paths that determine program execution time. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating the steps of a code processing method according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a compiler interaction framework according to an embodiment of this application; Figure 3 This is a schematic diagram illustrating the complete process from compilation to critical path optimization according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a code processing system according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0025] This application provides a code processing scheme. After the compiler transforms the code to be processed into an intermediate expression, a logical dependency structure is constructed based on this intermediate expression. This logical dependency structure is then converted into an execution-level dependency structure corresponding to the target environment architecture. Next, weights are assigned to nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters. Finally, execution path data is determined and output in the weighted execution-level dependency structure for subsequent code processing. The entire technical solution is completed statically during the compilation phase, obtaining instruction-level and microarchitecture-level execution path data without running the program on the target hardware. This enables high-precision performance analysis and optimization guidance that is independent of the operating system and the runtime environment.

[0026] The following description, in conjunction with the accompanying drawings, details a code processing solution provided by the embodiments of this application through specific examples and application scenarios.

[0027] Reference Figure 1 The diagram illustrates a flowchart of a code processing method according to an embodiment of this application.

[0028] Step 101: Obtain the code to be processed and generate an intermediate representation.

[0029] This step is performed by the compiler frontend. First, lexical and syntactic analysis is conducted on the language code provided by the developer, transforming the text-based code into an abstract syntax tree (AST). Then, the compiler frontend traverses the AST, progressively constructing a platform-independent intermediate representation. This intermediate representation uses a single static assignment method, fully expressing the program's control and data flow, while eliminating most details related to specific hardware architectures.

[0030] The generation of intermediate representations typically involves type checking, semantic checking, and preliminary target-independent optimizations, but these optimizations do not involve specific microarchitectural information. The platform independence of intermediate representations means that all subsequent analysis steps do not depend on the actual existence of the target hardware or any runtime environment. Intermediate representations preserve the complete semantic information of the program and provide a unified, structured input foundation for subsequently building logical dependency structures.

[0031] Step 102: Construct a logical dependency structure based on the intermediate expression form.

[0032] After the intermediate representation is generated, the analysis module traverses all nodes of the intermediate representation to establish a complete logical dependency structure. The logical dependency structure is a directed graph, where nodes correspond to each operation or instruction in the intermediate representation, and edges represent control dependencies and data dependencies between operations. The control dependencies reflect the program's execution order constraints, such as which operations must be executed after a branch jump; data dependencies include true dependencies (read-after-write), anti-dependencies (write-after-read), and output dependencies (write-after-write).

[0033] During the construction process, the analysis module simultaneously collects memory alias information to ensure that implicit data dependencies caused by pointers or references are also accurately recorded. Once the logical dependency structure is built, the graph contains all static execution constraints of the program at the intermediate expression level, fully expressing which operations must be strictly serial and which can theoretically be parallelized, without considering specific microarchitectural resources. This logical dependency structure is independent of the specific target instruction set and does not involve any microarchitectural execution details; therefore, the construction process is extremely fast and memory usage is controllable. As the direct input for subsequent conversion to the execution-level dependency structure, the logical dependency structure carries all semantic dependencies of the program. Subsequent machine-level refinement essentially involves gradually adding the execution constraints of the target microarchitecture to this logical dependency structure without altering the established semantic dependencies. The completeness and accuracy of the logical dependency structure directly determine the reliability of the final critical path analysis results.

[0034] Specifically, the logical dependency structure encompasses all execution constraints at the intermediate representation level. Data dependencies include not only true dependencies between operands but also implicit dependencies arising from pointers or references identified through memory alias analysis. After being converted into an execution-level dependency structure, resource dependencies at the execution hardware level are further introduced.

[0035] Step 103: Convert the logical dependency structure into the execution-level dependency structure corresponding to the target environment architecture.

[0036] After the compiler backend completes instruction selection, register allocation, and scheduling, the platform-independent intermediate representations are mapped to the actual low-level instructions of the target architecture. At this point, the analysis module re-decodes these generated low-level instruction sequences, decomposing each instruction into one or more execution unit operation sequences actually executed within the target execution hardware. These decomposed micro-operations directly correspond to hardware resources such as execution units, issue ports, and functional units in the processor pipeline. The conversion process, based on the original logical dependency structure, replaces each intermediate representation operation with its corresponding execution unit operation sequence. Simultaneously, it transfers semantic-level control and data dependencies to the micro-operation level and introduces additional resource dependencies determined by the target microarchitecture; for example, micro-operations on the same issue port must be executed serially. The resulting execution-level dependency structure retains the directed graph form, but the nodes have become micro-operations, and the edges contain both data and resource dependencies.

[0037] Specifically, during the low-level instruction re-decoding process, complex or fused instructions are decomposed and mapped into multiple execution unit operations. For example, a low-level instruction is decoded into a load operation node, which corresponds to a sequence of execution unit operations within the processor, such as fetching data from the memory subsystem, executing the operation, and writing the result back. This decomposition method can describe the actual execution behavior of low-level operations within the hardware pipeline in greater detail than simple instruction analysis.

[0038] Step 104: Set weights for nodes and edges in the execution-level dependency structure based on the available hardware performance parameters.

[0039] The analysis module accesses a pre-built execution hardware model database, which contains hardware performance parameters obtained through benchmark testing for specific target environment architectures. Parameters in the hardware execution model database are obtained by running specific instruction performance test programs in an isolated environment. For example, by repeatedly executing a single instruction sequence of a specific category on the target execution hardware, the actual clock cycles from instruction issuance to result writing back to the register file are measured to eliminate interference factors outside the pipeline and ensure the authenticity and accuracy of latency and throughput weights. When setting weights, node weights are divided into two categories: node weights correspond to the latency of micro-operations, i.e., the minimum number of clock cycles available from issuance to result for that micro-operation; edge weights correspond to the minimum interval number of cycles caused by resource constraints between micro-operations, mainly derived from throughput limitations of execution ports or functional unit occupancy conflict rules. For the same type of micro-operation, if the database provides a category average, that average is used uniformly; if a precise value at the opcode level is provided, the precise value is used preferentially.

[0040] Once configured, each node in the execution-level dependency structure has a defined latency weight, and each edge has a defined minimum interval weight based on throughput or resource conflicts. The weighting process strictly follows the actual hardware behavior of the target microarchitecture, without relying on any runtime sampling or inference of execution results. The weighted execution-level dependency structure becomes a weighted directed acyclic graph, which can be directly used for subsequent critical path mathematical calculations, thus transforming the performance analysis problem into a classic graph theory longest path problem.

[0041] During the weight configuration process, resource constraints at the hardware performance level are introduced as constraints to enable the model to simulate the parallel execution environment of real hardware. For example, by simulating port pressure (i.e., too many operations emitted to the same hardware port within a clock cycle) and resource conflicts (i.e., multiple operations competing for limited hardware resources such as dividers), edges are assigned a minimum interval period weight determined by throughput or conflict.

[0042] Step 105: Determine the execution path data in the execution-level dependency structure according to the weight, and output the execution path data for subsequent code processing.

[0043] On the execution-level dependency structure where node latency weights and edge resource constraint weights have been completed, the analysis module uses a topology-sort-based dynamic programming algorithm to calculate two longest paths: one with node weights as the path length, yielding the latency critical path; the other with edge weights as the path length, yielding the resource critical path. These two paths represent the theoretical longest execution time under unlimited and actual resource constraints, respectively. The analysis module further takes the larger of the two path lengths as the theoretical minimum execution cycle count for the current code snippet on the target microarchitecture. The final output execution path data includes the complete sequence of execution unit operations on the latency critical path, the bottleneck micro-operations and corresponding functional units on the resource critical path, and the theoretical minimum execution cycle count. The output can be a visualized dependency graph, highlighted code annotations, or a structured analysis report. The output execution path data directly points to the actual performance bottleneck of the current code on the target microarchitecture, providing developers with precise optimization targets for subsequent code processing. The entire determination and output process is completed during the compilation phase, allowing developers to obtain performance prediction results highly consistent with actual hardware behavior without deploying the program to the target device.

[0044] Furthermore, the output execution path data provides a quantitative optimization benchmark for subsequent code processing. If the execution path is mainly constrained by latency limits, subsequent processing should focus on reducing data dependency waiting through instruction scheduling; if the execution path is constrained by throughput limits (i.e., port pressure is the bottleneck), subsequent processing should focus on improving resource utilization.

[0045] In this embodiment, by acquiring the code to be processed and generating an intermediate representation during the compilation phase, constructing a logical dependency structure based on the intermediate representation, converting the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture, and then setting weights for nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters, and determining and outputting execution path data in the weighted execution-level dependency structure, the performance analysis is completed statically at compile time without actually running the analyzed program on the target hardware or relying on the performance monitoring facilities of a specific operating system. This overcomes the shortcomings of existing technologies that can only perform analysis at runtime, in a specific operating system environment, and only provide coarse-grained analysis at the function or basic block level. It achieves compile-time performance analysis across operating systems and runtime environments, and elevates the analysis granularity to the instruction and microarchitecture levels, directly revealing the underlying critical paths that determine program execution time.

[0046] In one exemplary embodiment of this application, one way to convert the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture is as follows: re-decode the low-level instructions generated by the compiler backend; decompose and map each low-level instruction obtained by re-decoding into one or more execution unit operation sequences within the target execution hardware; and construct an execution-level dependency structure based on the execution unit operation sequences and the data and resource dependencies between the execution unit operation sequences.

[0047] In this embodiment, the conversion process occurs after the compiler backend maps the intermediate representation to the low-level instructions of the target environment architecture. The analysis module first captures these low-level instruction sequences, which have undergone instruction selection, register allocation, and preliminary scheduling to form a binary form that matches the specific hardware architecture. Subsequently, the analysis module initiates a re-decoding operation, which decodes each low-level instruction, decomposing its internal logic into the execution unit operation sequences actually executed in the target execution hardware pipeline. These execution unit operation sequences correspond to the specific steps of the processor's internal stages such as instruction fetch, decode, issue, execute, and write-back.

[0048] During the decomposition mapping, the analysis module considers the instruction set characteristics of the target execution hardware, ensuring that complex instructions, such as fusion instructions, are correctly broken down into multiple micro-operations. For example, a multiply-accumulate fusion instruction might be mapped to a sequence of fetch micro-operations, multiplication micro-operations, and addition micro-operations. Next, the analysis module constructs an execution-level dependency structure based on these execution unit operation sequences. This structure is a directed graph where nodes correspond to individual micro-operations, and edges correspond to data and resource dependencies within and between execution unit operation sequences. Data dependencies include read-after-write dependencies, ensuring that subsequent micro-operations must wait for the results of preceding micro-operations to become available. Resource dependencies reflect the sharing of execution units within the execution hardware; for example, serial constraints must be introduced when multiple micro-operations compete for the same execution port. This construction process inherits the semantic dependencies from the logical dependency structure and injects hardware-level constraints from the target execution hardware, enabling the execution-level dependency structure to fully describe the program's execution behavior in the actual pipeline. This embodiment ensures that the transformation is completely static, requiring no code execution and relying only on the compiler backend output and predefined decoding rules, thus providing a refined graph foundation for subsequent weight settings.

[0049] This embodiment achieves a significant improvement in analysis granularity, enabling it to capture the actual decomposition and dependencies of instructions within the hardware. This reveals micro-operational bottlenecks that existing dynamic tools such as perf cannot reach, avoiding the lag and platform dependency issues of having to run programs on the target hardware.

[0050] In one exemplary embodiment of this application, one implementation of setting weights for nodes and edges in an execution-level dependency structure based on accessible hardware performance parameters is as follows: accessing a pre-built execution hardware model database; and assigning latency weights to nodes in the execution-level dependency structure and minimum interval period weights determined by throughput or resource conflicts to edges, based on parameters in the database.

[0051] In this embodiment, the analysis module first connects to an execution hardware model database, a structured storage system containing parameter sets for various target execution hardware. These parameters are acquired on real hardware using dedicated benchmarking programs. When accessing the database, the analysis module queries entries that match the target environment architecture to ensure accurate parameter correspondence. Subsequently, the analysis module traverses all nodes in the execution-level dependency structure, assigning a latency weight to each node. This weight represents the number of clock cycles required for the corresponding micro-operation to complete from issuance, directly derived from the micro-operation latency values ​​recorded in the database. The latency weight assignment considers the specific type of micro-operation; for example, the latency of an arithmetic micro-operation may be multiple cycles, while the latency of a memory access micro-operation depends on the cache hierarchy. Next, the analysis module processes all edges, assigning a minimum interval cycle weight to each edge. This weight reflects the minimum clock interval required between micro-operations due to throughput limitations or resource conflicts. For example, if two micro-operations share the same execution unit with a throughput of one per cycle, the edge weight is at least one cycle; resource conflicts such as port pressure may increase the weight value. This assignment process uses throughput data and conflict rules from the database to ensure that the weights accurately simulate the parallel execution constraints within the execution hardware. Once set, the execution-level dependency structure transforms into a weighted directed graph, where node weights dominate latency bounds analysis and edge weights dominate resource bounds analysis.

[0052] This embodiment provides the basis for a quantitative performance model that can accurately simulate the impact of latency and resource constraints, thereby overcoming the limitations of existing static analysis tools that only check for potential problems based on the code to be processed and cannot quantify microarchitecture-level bottlenecks, thus avoiding the coarseness and inaccuracy of the analysis results.

[0053] In one exemplary embodiment of this application, the database includes at least one of the following parameters obtained by benchmark testing for the target execution hardware: latency of each micro-operation or micro-operation category; throughput of each execution unit and execution port; and functional unit resource conflict and port allocation rules.

[0054] In this embodiment, the database is organized using a key-value pair or relational table structure. The keys correspond to the hardware model and micro-operation type, while the values ​​store measured parameters. The latency parameter for each micro-operation or micro-operation category represents the fixed number of cycles from input availability to output readiness on the target execution hardware. This is obtained by repeatedly executing a single execution unit operation sequence in an isolated environment using a benchmark program to ensure the elimination of interference factors. The throughput parameter for each execution unit and execution port quantifies the number of new micro-operations the hardware can process per clock cycle. For example, the throughput of an integer execution unit might be four per cycle, while the throughput of a floating-point execution unit might be two per cycle. These values ​​are obtained through saturation load testing using a benchmark program. The functional unit resource conflict and port allocation rule parameters describe how micro-operations compete for shared resources, such as specifying which micro-operations are bound to a specific port, and the arbitration rules when multiple micro-operations simultaneously request the same port. These rules are collected by simulating conflict scenarios using a benchmark program to ensure that the parameters capture real hardware behavior. The database supports the inclusion of at least one parameter, but in actual deployments, all three are typically integrated to provide a comprehensive weighted calculation basis.

[0055] This embodiment ensures independent acquisition and accuracy of parameters, supports precise weight settings, thereby solving the problem that existing tools such as perf cannot be applied in real-time operating system environments, and improves the adaptability of analysis to different execution hardware architectures.

[0056] In one exemplary embodiment of this application, an implementation method for determining execution path data in the execution-level dependency structure according to weights and outputting the execution path data for subsequent code processing is as follows: In the execution-level dependency structure that has been assigned delay weights and minimum interval period weights respectively, a dynamic programming algorithm based on topology sorting is used to calculate the delay critical path and the resource critical path respectively; the larger value between the delay critical path and the resource critical path is taken as the theoretical minimum number of execution cycles for the current code segment; at least one of the delay critical path, the resource critical path, and the theoretical minimum number of execution cycles is presented in the form of a visual dependency graph, hotspot annotation, or analysis report for subsequent code processing.

[0057] In this embodiment, the analysis module first performs a topological sort on the weighted execution-level dependency structure to ensure the graph is acyclic and establishes a linearized node order. Then, a dynamic programming algorithm is used to calculate the latency critical path, whose length is the sum of node latency weights, representing the longest execution chain without resource constraints. Simultaneously, a resource critical path is calculated, whose length is the sum of edge minimum interval period weights, representing the longest bottleneck chain under resource constraints. After calculation, the analysis module compares the lengths of the two paths and takes the larger one as the theoretical minimum execution cycle number, which represents the minimum possible execution time of the code snippet on the target execution hardware. In output, the analysis module selects at least one piece of information to present, such as a visual dependency graph displaying path nodes and weighted connections, hotspot annotations highlighting bottleneck micro-operations in the code to be processed, and an analysis report summarizing path details in text. This presentation format is integrated into the compiler output for easy viewing by developers.

[0058] This embodiment enables dual identification and visualization of latency and resource bottlenecks, thereby overcoming the inefficiency of developers guessing optimization points based on experience, and providing intuitive guidance to reduce optimization cycles.

[0059] In one exemplary embodiment of this application, the delay critical path is the longest path obtained with the delay weight as the path length; the resource critical path is the longest path obtained with the minimum interval period weight as the path length.

[0060] In this embodiment, the delay-critical path uses dynamic programming to traverse all possible paths, accumulating the delay weights of nodes along the way, and selecting the path with the largest total weight. This path represents the execution sequence with the longest dependency chain, determining the minimum execution time under ideal infinite parallel resources. The resource-critical path, on the other hand, accumulates the minimum interval period weights along the path, selecting the path with the largest total weight. This path represents the sequence with the most severe resource contention, determining the minimum execution time under actual limited hardware resources. This definition ensures that the two paths capture different performance limits, avoiding the limitations of single-dimensional analysis.

[0061] This embodiment provides precise path definition, which can quantify the impact of dependency chain length and resource conflicts separately, thereby solving the problem that existing tools are unable to reveal the root cause of performance bottlenecks, and providing a more detailed bottleneck location basis for subsequent code processing.

[0062] In one exemplary embodiment of this application, the method is applied to the compiler compilation process through a non-intrusive interactive framework, which includes: a compiler pass management module and an interactive event mechanism; and a compiler interactive plugin loaded as a dynamic library.

[0063] In this embodiment, the compiler pass management module is responsible for scheduling all compilation passes, including optimization passes, transformation passes, and analysis passes, and inserting interactive event mechanisms between specific passes. These events are triggered when a pass begins, ends, or intermediate representations are updated. The compiler interaction plugin, loaded as a dynamic library, is dynamically linked to the compiler at compilation startup, without modifying the compiler's core code; it only injects analysis logic through event listeners. This framework supports multiple compilers, ensuring method portability.

[0064] This implementation achieves compiler-independent extensibility, enabling it to run in a variety of compilation environments. This overcomes the limitations of existing tools such as perf, which are not applicable to real-time operating systems or bare-metal environments, and shortens the development-to-analysis cycle.

[0065] In one exemplary embodiment of this application, a compiler interaction plugin is configured to be triggered at least one pass phase of the compiler via a predefined low-level interaction interface and an application-level interaction interface.

[0066] In this embodiment, the plugin's triggering mechanism relies on a low-level interaction interface that provides low-level access to the compiler's internal data structures, such as directly reading intermediate representation nodes. The application-layer interaction interface provides a high-level Application Programming Interface (API), such as querying the current pass status or registering event callbacks. During at least one pass phase of the compiler, such as the intermediate representation optimization pass or the machine code generation pass, the plugin is triggered by the event mechanism, initiating the analysis operation. This triggering ensures that the plugin is activated only when necessary, reducing overhead.

[0067] This embodiment ensures the timeliness and flexibility of the triggering mechanism, enabling the injection of analysis logic at critical compilation stages. This overcomes the applicability limitations of existing dynamic tools that require the target program to actually execute, and achieves real-time performance insights during compilation.

[0068] In one exemplary embodiment of this application, the compiler interaction plugin is further configured to dynamically adjust the granularity of the logical dependency structure construction and the loading strategy of hardware performance parameters based on the detected compiler compilation flags; the compiler interaction plugin is further configured to perform at least one of the following operations after being triggered: constructing the logical dependency structure at the intermediate representation stage; performing re-decoding and constructing the execution-level dependency structure after the underlying instructions are generated; reading hardware performance parameters from the execution hardware model database and performing weighting of nodes and edges; performing critical path calculation and outputting an analysis report.

[0069] Specifically, the compiler interactive plugin has the ability to adaptively adjust to the compilation environment. Upon triggering, it obtains the flag information output by the compiler flag detection module and dynamically adjusts subsequent analysis behavior based on preset mapping rules: if the detected compilation flag is a preset high-level optimization, the compiler interactive plugin automatically refines the granularity of the logical dependency structure from the function level to the low-level instruction level to capture hidden performance bottlenecks caused by instruction rearrangement or loop unrolling; at the same time, according to the detected target architecture flag, the compiler interactive plugin dynamically loads the matching hardware performance parameters to ensure that the weight setting can accurately reflect the microarchitectural characteristics of the target hardware.

[0070] In this embodiment, the compiler interaction plugin selectively performs operations upon triggering, such as traversing nodes to build a logical dependency structure during the intermediate representation stage; calling the re-decoding module to build an execution-level dependency structure after low-level instruction generation; reading parameters from the database to perform weighting; and executing an algorithm to calculate the critical path and generate a report. The combination of at least one of these operations achieves full-process coverage. The plugin's versatility in this embodiment ensures modularity in the analysis.

[0071] This implementation provides end-to-end support from dependency building to report output, covering multiple analysis phases, thereby overcoming the shortcomings of existing tools in providing microarchitecture-level critical paths and improving the comprehensiveness of optimization guidance.

[0072] In one exemplary embodiment of this application, the execution hardware model database contains measured hardware performance parameters of the processor used in the target real-time operating system or bare-metal environment.

[0073] In this embodiment, the database extension supports real-time operating system or bare-metal processor parameters, which are collected in the corresponding environment through benchmarking to ensure consistency with actual deployment. This inclusion makes the method applicable to non-standard environments.

[0074] This embodiment expands the scope of the analysis, enabling the direct use of measured parameters for weight setting and critical path calculation in real-time operating systems or bare-metal scenarios. This solves the platform limitations of existing tools in embedded development and achieves consistent performance analysis across environments.

[0075] Based on the above description of the code processing method embodiments, a compiler interaction framework is introduced below. (Refer to...) Figure 2 The diagram shows a structural schematic of a compiler interaction framework according to an embodiment of this application.

[0076] The core of this compiler interaction framework is the compiler module, which includes the following components: Compiler compilation flag detection module: At the start of compilation, it detects user-provided compilation flags (such as optimization level -O2, target architecture) and dynamically adjusts the analysis strategy accordingly.

[0077] Intermediate representations by the compiler: The compiler converts the code to be processed into platform-independent intermediate representations, which serve as the basis for optimization and analysis.

[0078] The compiler pass management module manages various passes during the compilation process, including optimization, transformation, and analysis passes. This module supports an interactive event mechanism, allowing external plugins to inject custom operations into specific passes (such as PASS1, PASS2, and PASS3).

[0079] Code processing module: A standardized processing module built into the compiler, used for code optimization, transformation, and analysis.

[0080] Logical dependency structure: generated through analytical passes, combined with interactive data such as program control flow and data flow, to represent the dependencies between code.

[0081] Compiler interaction interfaces include low-level compiler interaction interfaces and application interaction interfaces. The low-level interface provides low-level access to the compiler's internal data structures, while the application interface provides a high-level API for plugins. Dynamic library-style compiler interaction plugins are injected into the compiler through these interfaces, performing analysis, optimization, or transformation operations throughout the compilation lifecycle. Plugins communicate with the compiler through interaction events and data, such as triggering the generation of logical dependency structures in the PASS3 stage.

[0082] Reference Figure 3 This diagram illustrates a complete process from compilation to critical path optimization according to an embodiment of this application. The complete process may specifically include the following steps: Step S1: Generation of intermediate code logic dependency structure.

[0083] This process begins with the compiler starting its work. First, it enters the compiler frontend, where lexical analysis, syntax analysis, and semantic analysis are performed on the code to be processed, generating an intermediate representation (IR). Subsequently, during the compiler optimization and transformation phase, the analytic pass is invoked in the intermediate representation stage to generate a complete logical dependency structure. This graph, combining control flow and data flow, is called the intermediate code logical dependency structure. This logical dependency structure integrates the program's control flow dependencies and data flow dependencies, providing a complete static representation of the program's semantics.

[0084] Step S2: Generation of machine code logic dependency structure.

[0085] This step leads to the compiler backend, where it continues working and maintains the state of the intermediate compiler representation, generating a sequence of machine code. The backend then outputs the intermediate compiler representation. After machine code generation, the compiler generates a sequence of machine code specific to the hardware architecture, calls the machine code re-decoding plugin to re-decode the generated machine code, and then calls the machine code re-decoding plugin again to generate the execution hardware model logical dependency structure for the machine code logical dependency structure. Specifically, it maps low-level instructions (including fused instructions) to sequences of operations on the internal functional units of the execution hardware, generating the execution hardware model logical dependency structure. This diagram illustrates the instruction execution process in the processor pipeline in more detail.

[0086] Step S3: Weighting of logical dependency structure.

[0087] This step, based on the logical dependency structure of the execution hardware model, accesses a pre-built instruction set and execution hardware model database. This database, pre-measured using an instruction set performance testing program, contains microarchitectural information such as instruction latency (number of clock cycles required to produce a result), functional unit throughput (number of new operations that can be executed per cycle), resource conflicts, and port pressure. Simultaneously, combined with actual micro-operation testing programs, latency and throughput weights are added as weights to the data structure of the execution hardware model's logical dependency structure. Based on this database, corresponding latency and throughput weights are assigned to nodes (operations) and edges (dependencies) in the execution hardware model's logical dependency structure.

[0088] Step S4: Critical path search and optimization guidance.

[0089] This step uses graph theory algorithms (such as dynamic programming based on topological sorting) to search for the longest path, or critical path, within the weighted logical dependency structure. The total latency of this path determines the lower bound of the program segment's execution time. Simultaneously, the critical path, its total latency, and throughput limits constrained by the functional unit's throughput are output to the developers. The shortest path within the logical dependency structure of the execution hardware model is searched, and the critical path is optimized, with latency and throughput limits serving as benchmarks. Developers use this information for iterative optimization, such as modifying the algorithm to reduce dependencies, using faster instructions, and balancing the functional unit's load. After optimization, recompilation and analysis provide a quantitative benchmark for the changes in the critical path and the threshold values, demonstrating the effectiveness of the optimization.

[0090] The steps S1 to S4 above constitute a complete closed-loop process from compilation to critical path optimization. The entire process is completed statically during compilation, without running the program on the target hardware, and can generate microarchitecture-level execution path data to guide developers to perform precise performance optimization during the compilation phase.

[0091] It should be noted that the code processing method provided in this application embodiment can be executed by a code processing system, or by a control module within the code processing system for executing the loading code processing method. This application embodiment uses the execution of the loading code processing method by a code processing system as an example to illustrate the code processing method provided in this application embodiment.

[0092] Reference Figure 4 The diagram illustrates the structure of a code processing system according to an embodiment of this application. Specifically, the system may include the following modules: Intermediate representation generation module 41 is used to acquire the code to be processed and generate an intermediate representation. Logical dependency structure construction module 42 is used to construct a logical dependency structure based on the intermediate expression form; The execution-level dependency structure conversion module 43 is used to convert the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture. The weight setting module 44 is used to set weights for nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters. The execution path data determination module 45 is used to determine the execution path data in the execution level dependency structure according to the weight, and output the execution path data for subsequent code processing.

[0093] In one exemplary embodiment of this application, the execution-level dependency structure conversion module 43 includes: The recompile module is used to re-decode the low-level instructions generated by the compiler backend; The decomposition and mapping module is used to decompose and map each low-level instruction obtained from the re-decoding into a sequence of operations of one or more execution units within the target execution hardware; An execution-level dependency structure component module is used to construct the execution-level dependency structure based on the execution unit operation sequence and the data and resource dependencies between the execution unit operation sequences.

[0094] In one exemplary embodiment of this application, the weight setting module 44 includes: The database access module is used to access a pre-built execution hardware model database; The weight assignment module is used to assign latency weights to nodes in the execution-level dependency structure and minimum interval period weights determined by throughput or resource conflicts to edges, based on parameters in the database.

[0095] In one exemplary embodiment of this application, the database includes at least one of the following parameters obtained by benchmark testing for the target execution hardware: latency of each micro-operation or micro-operation category; throughput of each execution unit and execution port; and functional unit resource conflict and port allocation rules.

[0096] In one exemplary embodiment of this application, the execution path data determination module 45 includes: The path calculation module is used to calculate the delay critical path and the resource critical path respectively in the execution-level dependency structure that has been assigned the delay weight and the minimum interval period weight, using a dynamic programming algorithm based on topology sorting. The cycle number determination module is used to take the larger value between the delay critical path and the resource critical path as the theoretical minimum execution cycle number of the current code segment; The path presentation module is used to present at least one of the delayed critical path, the resource critical path, and the theoretical minimum number of execution cycles in the form of a visual dependency graph, hotspot annotation, or analysis report for subsequent code processing; wherein, the delayed critical path is the longest path obtained with the delay weight as the path length; the resource critical path is the longest path obtained with the minimum interval cycle weight as the path length.

[0097] In one exemplary embodiment of this application, the system is applied to a non-intrusive interactive framework during the compiler compilation process, the interactive framework comprising: The compiler manages modules and interactive event mechanisms; A compiler interaction plugin loaded as a dynamic library; wherein the compiler interaction plugin is used to be triggered at least one pass stage of the compiler through predefined low-level interaction interfaces and application-level interaction interfaces; the compiler interaction plugin is also used to dynamically adjust the construction granularity of the logical dependency structure and the loading strategy of the hardware performance parameters according to the detected compiler compilation flags; the compiler interaction plugin is also used to perform at least one of the following operations after being triggered: construct the logical dependency structure in the intermediate expression stage; perform re-decoding and construct the execution-level dependency structure after the low-level instructions are generated; read the hardware performance parameters from the execution hardware model database and perform weighted calculation of the nodes and the edges; perform critical path calculation and output an analysis report.

[0098] In one exemplary embodiment of this application, the execution hardware model database contains measured hardware performance parameters of the processor used in the target real-time operating system or bare-metal environment.

[0099] The code processing system in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, handheld computers, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TeleVision), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0100] The code processing system in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0101] The code processing system provided in this application embodiment can achieve... Figure 1 The method embodiments include various processes implemented by the code processing system, which will not be described again here to avoid repetition.

[0102] Optionally, embodiments of this application also provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the various processes of the above-described code processing method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0103] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0104] Figure 5 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0105] The electronic device 1000 includes, but is not limited to, components such as: a radio frequency unit 1001, a network module 1002, an audio output unit 1003, an input unit 1004, a sensor 1005, a display unit 1006, a user input unit 1007, an interface unit 1008, a memory 1009, and a processor 1010. The input unit 1004 may include a graphics processor 10041 and a microphone 10042. The display unit 1006 may include a display panel 10061. The user input unit 1007 may include a touch panel 10071 and other input devices 10072. The memory 1009 may include applications and an operating system.

[0106] Those skilled in the art will understand that the electronic device 1000 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 1010 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0107] This application also provides a computer-readable storage medium / computer software product. The computer-readable storage medium stores a program or instructions that, when executed by a processor, implement the various processes of the above-described code processing method embodiments and achieve the same technical effects. To avoid repetition, these details will not be repeated here. The computer software product includes a computer program stored on a computer-readable storage medium. When executed by a processor, the computer program implements the various processes of the above-described code processing method embodiments and achieves the same technical effects. To avoid repetition, these details will not be repeated here.

[0108] The processor mentioned above is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0109] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and systems in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0110] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0111] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A code processing method, characterized in that, The method includes: Obtain the code to be processed and generate an intermediate representation; Construct a logical dependency structure based on the intermediate expression form; Convert the logical dependency structure into the execution-level dependency structure corresponding to the target environment architecture; Weights are assigned to nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters; The execution path data is determined in the execution-level dependency structure based on the weights, and the execution path data is output for subsequent code processing.

2. The method according to claim 1, characterized in that, The step of converting the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture includes: Re-decode the low-level instructions generated by the compiler backend; Each low-level instruction obtained from re-decoding is decomposed and mapped into a sequence of operations of one or more execution units within the target execution hardware; The execution-level dependency structure is constructed based on the execution unit operation sequence and the data and resource dependencies between the execution unit operation sequences.

3. The method according to claim 2, characterized in that, The step of setting weights for nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters includes: Access a pre-built database of execution hardware models; Based on the parameters in the database, latency weights are assigned to nodes in the execution-level dependency structure, and minimum interval period weights determined by throughput or resource conflicts are assigned to edges.

4. The method according to claim 3, characterized in that, The database contains at least one of the following parameters obtained through benchmark testing for the target execution hardware: latency for each micro-operation or micro-operation category; throughput of each execution unit and execution port; and functional unit resource conflict and port allocation rules.

5. The method according to claim 1, characterized in that, The step of determining execution path data in the execution-level dependency structure according to the weight, and outputting the execution path data for subsequent code processing, includes: In the execution-level dependency structure that has been assigned the delay weight and the minimum interval period weight respectively, the delay critical path and the resource critical path are calculated respectively using a dynamic programming algorithm based on topology sorting. The larger value between the delay critical path and the resource critical path is taken as the theoretical minimum number of execution cycles for the current code segment. At least one of the delayed critical path, the resource critical path, and the theoretical minimum number of execution cycles is presented in the form of a visual dependency graph, hotspot annotation, or analysis report for subsequent code processing; wherein, the delayed critical path is the longest path obtained with the delay weight as the path length; the resource critical path is the longest path obtained with the minimum interval cycle weight as the path length.

6. The method according to claim 3, characterized in that, The method is applied during the compiler compilation process through a non-intrusive interactive framework, which includes: The compiler manages modules and interactive event mechanisms; A compiler interaction plugin loaded as a dynamic library; wherein the compiler interaction plugin is used to be triggered at least one pass stage of the compiler through predefined low-level interaction interfaces and application-level interaction interfaces; the compiler interaction plugin is also used to dynamically adjust the construction granularity of the logical dependency structure and the loading strategy of the hardware performance parameters according to the detected compiler compilation flags; the compiler interaction plugin is also used to perform at least one of the following operations after being triggered: construct the logical dependency structure in the intermediate expression stage; perform re-decoding and construct the execution-level dependency structure after the low-level instructions are generated; read the hardware performance parameters from the execution hardware model database and perform weighted calculation of the nodes and the edges; perform critical path calculation and output an analysis report.

7. The method according to claim 3 or 6, characterized in that, The execution hardware model database contains measured hardware performance parameters of the processor used in the target real-time operating system or bare-metal environment.

8. A code processing system, characterized in that, The system includes: The intermediate representation generation module is used to obtain the code to be processed and generate intermediate representations. A logical dependency structure construction module is used to construct a logical dependency structure based on the intermediate expression form; An execution-level dependency structure conversion module is used to convert the logical dependency structure into an execution-level dependency structure corresponding to the target environment architecture. The weight setting module is used to set weights for nodes and edges in the execution-level dependency structure based on accessible hardware performance parameters. The execution path data determination module is used to determine the execution path data in the execution-level dependency structure according to the weight, and output the execution path data for subsequent code processing.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the code processing method as described in any one of claims 1-7.

10. A computer-readable storage medium / computer software product, characterized in that, The computer-readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the code processing method as described in any one of claims 1-7. The computer software product includes a computer program stored on a computer-readable storage medium, which, when executed by a processor, implements the steps of the code processing method as described in any one of claims 1-7.

Images