Profile information cross-architecture migration compiling method and device

Abstract

The invention discloses a Profile information cross-architecture migration compiling method and device.The method comprises the steps that a compiler of a mature architecture such as X86 is used, first Profile information collected during program compiling and second Profile information obtained during running are used, the first Profile information comprises optimization decision information during program compiling, and the second Profile information comprises optimization decision information during program running; the second Profile information comprises feature data during actual running of the program; when program compiling is carried out on an emerging framework such as RISC-V, the first Profile information is mapped to the compiling process, and an intermediate representation (IR) of a program is obtained; and optimizing the IR of the program by utilizing the second Profile information, and generating an executable file of the program. According to the method, the problem of migrating the Profile information from a mature architecture to an emerging architecture is solved, so that the emerging architecture can efficiently utilize the existing performance tuning experience, and the hardware potential is fully played.

Description

Technical Field

[0001] This invention relates to the field of compiler optimization, and in particular to a compilation method and apparatus for migrating profile information across architectures. Background Technology

[0002] With the rapid evolution of computer architecture, emerging architectures, represented by RISC-V, have accelerated their development in recent years, exhibiting a trend towards diversification and customization. Compared to the rapid iteration of hardware, the development of compiler technology has lagged behind, especially in compiler optimization on RISC-V, which is still in the exploratory stage and lacks systematic and engineering experience. At the same time, RISC-V processor design is in a rapid iteration phase, which means that existing traditional compiler optimization techniques often cannot fully adapt to the characteristics of the new architecture.

[0003] Traditional compiler optimization techniques have achieved significant optimization results on mature architectures such as x86, enabling compilers to fully utilize specific hardware features. However, as an emerging architecture, the high flexibility and versatility of the RISC-V architecture mean that these traditional optimization techniques are less effective than expected when facing new architectures, failing to fully realize their optimization potential and potentially facing compatibility and effectiveness issues in some cases. Summary of the Invention

[0004] The main technical problem solved by this invention is: how to overcome the technical problem in the prior art that profile data collected by one architecture cannot be accurately and directly migrated to the IR structure of another architecture, thus causing the cross-architecture profile migration effect to fail.

[0005] To address the aforementioned issues, this invention proposes collecting runtime profile information on a mature architecture (such as the x86 architecture) and innovatively designing a corresponding mapping mechanism. This enables the collected profile data to be accurately mapped to the IR structure of another architecture, thereby providing precise and reliable compilation optimization guidance for emerging architectures like RISC-V. Ultimately, this effectively solves the problems of insufficient compilation optimization adaptability and limited optimization effects caused by the lack of mature optimization experience in the RISC-V architecture.

[0006] In a first aspect, embodiments of the present invention provide a compilation method for migrating Profile information across architectures, the method comprising:

[0007] In the x86 compiler, the first profile information obtained during program compilation and the second profile information obtained during runtime are collected. The first profile information includes optimization decision information of the program during compilation, and the second profile information includes feature data of the program during actual runtime.

[0008] When compiling a program using the RISC-V compiler, the first Profile information is mapped to the compilation process to obtain the IR of the program;

[0009] Using the second Profile information, the IR of the program is optimized to generate the executable file of the program.

[0010] In a specific embodiment of the present invention, the first Profile information obtained during the compilation of the acquisition program includes:

[0011] Each function call point is evaluated to determine whether the called function should be inlined. The first profile information includes inlining judgment information and cost information for the function call point.

[0012] In a specific embodiment of the present invention, the first Profile information obtained during the compilation of the acquisition program further includes:

[0013] When a function contains a loop structure, the loop unrolling strategy is determined by evaluating the size and number of iterations of each loop, and the first Profile information includes the loop unrolling strategy.

[0014] In a specific embodiment of the present invention, the first Profile information obtained during the compilation of the acquisition program further includes:

[0015] The CFG of the program is optimized, and the optimization information is recorded in the first Profile information.

[0016] In a specific embodiment of the present invention, when compiling a program using the RISC-V compiler, mapping the first Profile information to the compilation process to obtain the IR of the program includes:

[0017] The RISC-V compiler reads the function inlining information in the first Profile information, bypasses its own cost model, and performs the same function inlining operation as the function inlining information.

[0018] The RISC-V compiler reads the loop unrolling strategy from the first Profile information and executes the loop unrolling strategy.

[0019] The RISC-V compiler reads the control flow simplification information from the first Profile information and executes the control flow transformation in the control flow simplification information.

[0020] In a specific embodiment of the present invention, the second Profile information includes the number of function calls, the execution frequency of basic blocks, and jump information.

[0021] In a specific embodiment of the present invention, optimizing the IR of the program using the first Profile information and the second Profile information includes:

[0022] Using the function call count, basic block execution frequency, and jump information from the second Profile information, Profile annotations are inserted into the IR of the program, and the IR of the program after annotation is optimized using the first Profile information to generate the executable file of the program.

[0023] Secondly, embodiments of the present invention provide a compilation apparatus for cross-architecture migration of profile information, the apparatus comprising:

[0024] The acquisition module is used to acquire first profile information obtained during program compilation and second profile information obtained during runtime in the x86 compiler. The first profile information includes decision information of the program during the optimization process of compilation, and the second profile information includes feature data of the program during actual runtime.

[0025] The processing module is used to map the first Profile information to the compilation process when compiling a program using the RISC-V compiler to obtain the IR of the program; and to optimize the IR of the program using the first Profile information and the second Profile information to generate the executable file of the program.

[0026] In a specific embodiment of the present invention, the above-mentioned acquisition module is used to evaluate each function call point and determine whether the called function should be inlined. The first Profile information includes inlining judgment information and cost information of the function call point.

[0027] In a specific embodiment of the present invention, the above-mentioned acquisition module is used to evaluate the loop unrolling strategy based on the size and number of iterations of each loop when there is a loop structure in the function, and the first Profile information includes the loop unrolling strategy.

[0028] In a specific embodiment of the present invention, the above-mentioned acquisition module is used to optimize the CFG of the program and record the optimization information into the first Profile information.

[0029] In a specific embodiment of the present invention, the processing module is used by the RISC-V compiler to read the function inlining information in the first Profile information, bypass its own cost model, and perform the same function inlining operation as the function inlining information.

[0030] The RISC-V compiler reads the loop unrolling strategy from the first Profile information and executes the loop unrolling strategy.

[0031] The RISC-V compiler reads the control flow simplification information from the first Profile information and executes the control flow transformation in the control flow simplification information.

[0032] In a specific embodiment of the present invention, the processing module is used to optimize the IR of the program using the first Profile information and the second Profile information, including:

[0033] Using the function call count, basic block execution frequency, and jump information from the second Profile information, Profile annotations are inserted into the IR of the program, and the IR of the program after annotation is optimized using the first Profile information to generate the executable file of the program.

[0034] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the compilation method for cross-architecture migration of profile information.

[0035] Fourthly, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of a compilation method for cross-architecture migration of profile information as described above.

[0036] Compared with existing technologies, it has the following outstanding advantages:

[0037] Compared with existing technologies, this invention first aligns the Integrity Reference Array (IR) and then migrates the Profile. Based on this idea, a feasible and iterative cross-architecture compilation optimization method is constructed, solving the problem of the difficulty in reusing traditional PGO across heterogeneous architectures. This invention can achieve the following technical effects:

[0038] 1. Enable profile information to be available across architectures

[0039] By recording key mid-level optimization decisions (such as function inlining, loop unrolling, and control flow simplification) in the compile-time profile, and aligning the execution according to these decisions during the target architecture's compilation, the IRs on both sides are kept consistent at the function and basic block levels. On this basis, the runtime profile is then migrated to ensure that the profile information can be migrated accurately and efficiently.

[0040] 2. Accelerate the optimization of the new architecture to reduce data collection and verification costs.

[0041] Efficiently acquire profile information on mature architectures and migrate it to emerging architectures, reducing the overhead of instrumentation and environment building from scratch on the target side, shortening early optimization and exploration time, and reducing the cost of repeated trial and error.

[0042] 3. Reuse optimization experience from mature architectures

[0043] By first aligning the IR structure and then using runtime summary information, practices such as inlining, looping, and code layout that have been validated on mature architectures such as x86 can be applied to new architectures such as RISC-V. Adjustments can then be made based on the actual running results on the target side, thereby reducing the need for starting from scratch, shortening the tuning time, and improving the initial optimization effect. Attached Figure Description

[0044] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0045] Figure 1 This is a schematic diagram of a compilation method for cross-architecture migration of profile information according to the present invention;

[0046] Figure 2 This is a flowchart illustrating a compilation method for cross-architecture migration of Profile information according to the present invention.

[0047] Figure 3 This is a schematic diagram of the compile-time Profile information in an embodiment of the present invention;

[0048] Figure 4 This is a schematic diagram of the compile-time Profile information in an embodiment of the present invention;

[0049] Figure 5 This is a schematic diagram of the compile-time Profile information in an embodiment of the present invention;

[0050] Figure 6 This is a schematic diagram of runtime Profile information in an embodiment of the present invention;

[0051] Figure 7This is a schematic diagram of runtime Profile information in an embodiment of the present invention;

[0052] Figure 8 This is a schematic diagram of the compilation device module for cross-architecture migration of Profile information in an embodiment of the present invention;

[0053] Figure 9 This is a schematic diagram of the computer hardware of the present invention. Detailed Implementation

[0054] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0055] It should also be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0056] It should also be understood that, in various embodiments of the present invention, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0057] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0058] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the objectives of the embodiments described in this application, depending on actual needs.

[0059] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0060] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical application embodiments of the present invention, or the parts that contribute to the prior art or are part of the technical application embodiments, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0061] To make the above-mentioned features and effects of the present invention clearer and easier to understand, specific embodiments are described below in conjunction with the accompanying drawings. This specification discloses one or more embodiments incorporating the features of the present invention. The disclosed embodiments are merely illustrative. The scope of protection of the present invention is not limited to the disclosed embodiments, but is defined by the appended claims.

[0062] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.

[0063] With the rapid evolution of computer architecture, emerging architectures, represented by RISC-V, are developing rapidly towards diversification and customization. However, in stark contrast, the development of compiler technology has lagged behind. Especially in the RISC-V ecosystem, compiler optimization is still in the exploratory stage, lacking systematic and engineering-based experience. In addition, the rapid iteration of RISC-V processor design itself makes it difficult for traditional compiler optimization techniques based on mature architectures such as x86 to fully adapt to its new features.

[0064] These traditional optimization techniques aim to fully leverage the advantages of specific hardware, but when faced with the highly flexible and diverse designs of RISC-V, their optimization potential often cannot be fully realized, and they even face serious challenges in terms of adaptability and effectiveness.

[0065] Against this backdrop, PGO (Profile-Guided Optimization) technology demonstrates its unique value. Its core is a "collect first, optimize later" compilation paradigm: first, through instrumentation or sampling, profile information is collected during the actual program execution; then, during secondary compilation, the compiler uses this precise data to guide key decisions, such as adjusting inlining thresholds, optimizing loop strategies, rearranging code and basic block layouts to achieve hot and cold code separation, and performing branch reordering, thereby achieving deeper performance optimization.

[0066] PGO technology follows the principle of "same-architecture optimization," which means running instrumentation programs on the target architecture to collect profile information and using it for final compilation optimization within the same architecture. However, when migrating profile information across architectures, a fundamental contradiction arises: architectural differences lead to divergent optimization decisions.

[0067] The core issue lies in the differences between compiler inline logic (IR) and the underlying optimization logic across different architectures. Although instrumentation can be uniformly implemented at the IR level, many optimization passes are heavily influenced by the hardware characteristics of the target architecture during subsequent compilation processes. Therefore, even with the same IR code, the same optimization pass may employ different function inlining strategies, basic block layouts, and other techniques depending on the target architecture.

[0068] This divergence in optimization decisions means that profile data collected on architecture A (such as function call frequency and basic block execution order) cannot be precisely matched with the IR structure of architecture B. Ultimately, using profile data from architecture A to guide compilation optimization on architecture B will be significantly less effective or even fail.

[0069] Therefore, PGO technology can feed back the execution path and hotspot information of real workloads to the compiler, thereby guiding the compiler to make more targeted optimization decisions and fully tap the performance potential of the hardware architecture. An innovative approach is proposed to migrate and apply profile data already collected on mature architectures (such as x86) to emerging architectures (such as RISC-V) for compilation optimization. First, it can directly "graft" the extensive optimization experience accumulated in the x86 system to the RISC-V ecosystem, effectively compensating for its lack of experience and practice in compilation tuning. Second, this method can save the high cost of building simulation execution and performance analysis environments on the RISC-V platform, thus significantly accelerating the optimization process and providing an efficient shortcut to the maturity of the RISC-V ecosystem.

[0070] However, in actual cross-architecture optimization, directly using profile data collected from one architecture (such as x86) for the compilation process of another architecture (such as RISC-V) often fails to achieve the expected optimization effect and may even lead to performance degradation, i.e., "negative optimization". The fundamental reason is that there are differences in the compiler IR structure between different architectures, which makes it impossible for the profile data collected from the source architecture to be accurately located and matched in the IR of the target architecture.

[0071] Furthermore, this difference in IR structure primarily stems from the compiler's sensitivity to the characteristics of the target architecture during the optimization process. Even with identical source code and consistent pass sequences in the compilation flow, the hardware characteristics of different architectures may lead to different optimization decisions during execution, specifically in inlining strategies, loop unrolling levels, control flow simplification methods, and basic block merging and splitting. These differences ultimately result in inconsistencies between function boundaries and basic block partitioning in the IR of the two architectures, causing the profile data from the source architecture to lose its accurate mapping in the target architecture, thus failing to effectively guide optimization.

[0072] To address this challenge, this invention proposes aligning the IR structures between different architectures before migrating Profile information across architectures. Based on IR structure alignment, Profile information is correctly and stably mapped to the target architecture, thereby enabling it to play its optimization guidance role. Therefore, the core problem this invention aims to solve is: how to establish a stable and consistent IR structure alignment mechanism between different architectures, ensuring reliable mappability between functions and basic blocks, thereby supporting the effective migration and utilization of cross-architecture Profile data.

[0073] To address the above problems, this invention proposes a two-step cross-architecture profile information migration method. By innovatively combining compile-time profile information and runtime profile information, it systematically solves the profile migration failure problem caused by inconsistencies in the IR structure. During compile-time structure alignment, optimization decision information (referred to as "compile-time profile") from the source architecture during compilation is collected, including function inlining decisions, loop unrolling strategies, and control flow optimization paths. Using this information, the target architecture is guided to generate an IR structure highly consistent with the source architecture during compilation. During runtime behavior migration, while ensuring IR structure alignment, runtime profile information collected from the source architecture (such as execution frequency and branch probability) is accurately mapped to the target architecture, thereby achieving efficient reuse of program behavior features. This invention proposes a cross-architecture migration method that combines compile-time profile information and runtime profile information, solving the problem of inaccurate application of runtime profile information caused by IR inconsistencies through structure alignment.

[0074] To achieve the aforementioned structural alignment, this invention proposes a novel compile-time profile information collection method. This method focuses on key compilation optimization stages, recording the implementation details of core optimization strategies such as function inlining, loop unrolling, and control flow simplification in a fine-grained manner. Specifically, this includes whether a function is inlined, the number of loop unrolling iterations, and the simplified control flow path. By collecting this detailed compile-time decision information, accurate structural mapping can be provided for cross-architecture migration, thereby guiding fine-grained performance tuning of emerging architectures (such as RISC-V). This invention proposes a fine-grained compile-time profile information collection method that, by recording key optimization decisions, can guide fine-grained performance tuning of emerging architectures during cross-architecture migration.

[0075] Building upon traditional runtime profile information, this invention further proposes a heuristic optimization method based on real-time feedback. This method achieves self-correction of compilation strategies by monitoring the effectiveness of optimization strategies during actual runtime. During program execution, fine-grained performance metrics such as the actual execution time of inline functions, memory access patterns, and cache hit rates are collected. These runtime data are used to evaluate the actual benefits of specific optimizations. When an optimization is detected to cause performance degradation, the compiler will automatically adjust or roll back the optimization strategy in the next compilation round, avoiding the repeated application of ineffective optimizations. This invention proposes an adaptive optimization method based on runtime feedback, dynamically evaluating and automatically correcting optimization strategies through performance metrics to avoid negative optimizations caused by architectural differences.

[0076] This invention significantly extends the traditional profile information collection process. While retaining the original runtime information collection, it innovatively adds the collection of compile-time profile information to support cross-architecture IR structure alignment.

[0077] This invention constructs a two-stage profile information collection system that combines compile-time and runtime profile information collection, including compile-time profile information collection and runtime profile information collection.

[0078] Compile-time profile information collection refers to the process performed during source code compilation to generate the Information Retrieval (IR). Its purpose is to record key compiler optimization decisions, providing a basis for cross-architecture alignment. The main collection modules include: function inlining information, which records which functions are inlined and which are not, providing a basis for subsequent optimization decisions; loop unrolling information, which records which loops are unrolled and the specific number of unrolls, providing data support for adjusting unrolling strategies and avoiding code bloat; and control flow simplification information, which records removed redundant basic blocks, optimized jump paths, etc., ensuring the portability of control flow optimization logic.

[0079] Runtime profile information collection is performed during actual program execution to add fine-grained evaluation of the actual effectiveness of optimization decisions. This includes: inlining effect evaluation, which collects the execution time, memory access patterns, and cache hit rate of inlined functions to determine the actual benefits of inlining and avoid cache performance degradation caused by excessive inlining; loop unrolling effect evaluation, which monitors the memory usage, cache hit rate, and CPU cycle consumption of unrolled loops to provide precise feedback on whether to unroll further and to what extent; and control flow optimization effect evaluation, which collects the execution frequency, jump latency, and cache status of optimized paths to verify whether control flow simplification truly brings performance improvements.

[0080] Furthermore, to address the inconsistency in IR structure caused by differences in hardware and compilation, this invention proposes a two-step strategy of "structural alignment first, behavior migration second" to achieve cross-architecture migration and mapping of Profile information.

[0081] First, based on the IR structure alignment of the compile-time profile, the compile-time profile information collected from the source architecture is loaded and followed during the compilation of the target architecture. That is, on the target architecture, compilation is performed according to the optimization decisions of the source architecture (such as the same inlining selection and the same number of loop unrollings), thereby generating an IR structure that is highly similar to the source architecture.

[0082] Next, runtime profile migration based on mapping relationships establishes a precise mapping relationship between functions and basic blocks between the two architectures, building upon IR structure alignment. This includes precise matching, which prioritizes matching using static information such as symbol tables, basic block names, and addresses; and fuzzy matching, which uses heuristic methods based on function and calling patterns to assist alignment for remaining units that cannot be precisely matched. Once the mapping relationship is established, runtime profile information (such as execution frequency) from the source architecture can be accurately migrated to the corresponding units in the target architecture, thereby guiding precise compilation optimization in the target architecture.

[0083] Therefore, performance optimization is one of the key challenges in software ecosystem migration (such as from x86 to RISC-V architecture). Proof-of-Growth (PGO) is a core technology for improving program performance. However, due to the differences in hardware characteristics, memory management, and compiler backend processing between different instruction set architectures (ISAs), directly using profile data collected on x86 architecture for compilation optimization on RISC-V architecture will lead to IR structure mismatch, thereby causing optimization failure or even negative effects.

[0084] This application adopts a two-step strategy, the core idea of ​​which is: first, to align the IR structures of the two architectures using compile-time profile information, and then to accurately map the runtime profile information using the aligned IR structures.

[0085] The embodiments of this application aim to solve the fundamental problem of cross-architecture profile information migration, and ensure that the optimization experience gained on the x86 architecture can be safely and effectively applied to the RISC-V architecture, thereby achieving high-performance cross-architecture code migration.

[0086] like Figure 1 and Figure 2 As shown, the embodiments of this application include the following steps:

[0087] S1. On the x86 architecture, collect the compile-time ProfileA and the runtime ProfileB respectively.

[0088] A compile-time profile is a file generated during the compilation phase. It records the various "decisions" and "judgments" made by the compiler during optimization. During compilation, the compiler records the logic and rationale behind optimization decisions through analysis or lightweight instrumentation. For example, it records whether a function was inlined, why, whether a loop was unrolled, why, and how the control flow graph was simplified. Its purpose is to guide the compiler in constructing the program's information flow (IR) structure.

[0089] First, when compiling source code using the LLVM compiler on the x86 platform, key decisions made by the compiler during optimization, ProfileA, are recorded through instrumentation or analysis mode. This information ensures that optimization logic can be recorded and reused. ProfileA includes function inlining information, loop unrolling information, and control flow simplification information.

[0090] The function inlining information includes recording the "inlining cost" and "threshold" evaluation results for each function call point. For each potential function call point (such as calling the `call` function), the compiler evaluates the "cost" and "benefit" of inlining it. If the "cost" is lower than a certain "threshold," inlining is performed. The ProfileA file records that "at location X, function Y is inlined because its cost C < threshold T." When compiling for RISC-V, the compiler reads this information and forces the same inlining decision to be performed at the same location, thus ensuring the consistency of function body structure across the two architectures.

[0091] For example, for the function `store_blessed`, the decision on whether to inline multiple call points within it is recorded. This ensures that the same inlining decision can be reproduced on the RISC-V architecture, thus maintaining a consistent function body structure. Figure 3 As shown, the ProfileA file records the inline decision machine cost information for multiple call points.

[0092] Loop unrolling information includes records of the loop's size, estimated number of iterations, and the compiler's decision on whether to apply a loop unrolling strategy. For a loop, the compiler evaluates its body size and estimated number of iterations. If it is determined to be a small loop with a fixed and infrequent number of iterations, it decides to unroll it. For example, ProfileA records that "Loop L is unrolled because its body size S and number of iterations T conform to strategy P." This ensures that on the RISC-V architecture, the same loop will be unrolled in the same way, preventing differences in loop structure due to architectural variations.

[0093] like Figure 4 As shown, ProfileA records that a runtime loop unrolling strategy was enabled when processing multiple loops in the Perl_pmtrans function. By unrolling loops, the compiler reduces loop control overhead and improves data locality. The compiler evaluates the "size" and "number of iterations" of each loop to determine whether to unroll it.

[0094] Control flow simplification information includes recording the compiler's transformation decisions for the CFG, such as the removal of redundant jumps, merging of basic blocks, and movement of cold path code. This is the most critical step in achieving IR structure alignment. It records the transformation history of the CFG, ensuring that during RISC-V compilation, an IR highly consistent with x86 in terms of basic block boundaries and jump relationships can be generated.

[0095] like Figure 5 As shown, ProfileA records the movement of certain instructions that are not immediately needed to be executed to later execution paths in the CFG to reduce invalid execution, shorten hot paths, and improve execution efficiency. This is key to achieving IR structure alignment, ensuring that the basic block boundaries and jump relationships generated by x86 and RISC-V are highly similar.

[0096] Next, runtime profile information is collected. The compiled binary file with instrumentation is run under typical workloads on the x86 platform, and data reflecting the actual runtime characteristics of the program, namely ProfileB, is collected. ProfileB includes the number of function executions, the execution frequency of basic blocks, the probability of branch jumps, and memory usage patterns.

[0097] like Figure 6 and Figure 7 The ProfileB file records the number of times the function is executed, the execution frequency of the basic block, the probability of branch jumps, and memory usage patterns.

[0098] In some embodiments, ProfileA and ProfileB can be merged to generate ProfileC.

[0099] Due to differences in hardware characteristics, instruction set architecture, memory management, and caching systems between x86 and RISC-V, directly migrating compile-time profile information from the x86 architecture to the RISC-V architecture may lead to inconsistencies in the instruction set architecture (IR). This embodiment uses compile-time profile information to ensure basic block alignment between the two architectures.

[0100] S2. When compiling for the RISC-V architecture, first use the compile-time ProfileA to force IR structure alignment, and then use the mapped runtime Profile to guide the final optimization.

[0101] First, when compiling for the RISC-V architecture, the compile-time ProfileA collected on x86 is loaded. Based on this information, the compiler will force the same optimization decisions during the RISC-V IR generation stage as on the x86 side. For example, the compile-time profileA records whether to inline the `call` function in the `store_blessed` function; by recording this decision, the RISC-V compiler can perform the same inlining decision based on the compile-time profileA information.

[0102] Next, the same loop unrolling strategy is applied. On x86, the compiler reduces loop control overhead through loop unrolling. When migrating to RISC-V, the compiler can refer to the loop unrolling information of x86 to ensure that the same unrolling strategy is used during RISC-V compilation.

[0103] Finally, the same control flow simplification transformation is performed. By using control flow optimization information collected at compile time, such as removing redundant jumps and simplifying the control flow graph, the basic block structure and jump paths of both architectures are ensured to be similar, thereby ensuring that the two architectures can generate similar IRs.

[0104] For example, in the alignment of function inlining decisions, the x86 compiler profile records that in the function `store_blessed`, the call point of the `call` function was evaluated for inlining (based on code size, call frequency, etc.), and a "inlining" decision was made. On the RISC-V side, without the embodiment of this application, the RISC-V compiler would re-evaluate based on its own cost model, and might decide not to inline due to architectural differences (such as the belief that inlining would cause excessive register pressure). When applying the embodiment of this application: the compiler reads the compile-time profile, finds that the x86 side decides to inline at this point, bypasses its own cost model, and forces the same inlining operation. The IR of the `store_blessed` function contains the code body of the inlined `call` function in both architectures, maintaining complete structural consistency.

[0105] In the alignment of loop unrolling strategies, on the x86 side, when processing a loop, the profile records the compiler's decision to "unroll 4 times" based on the judgment of "small loop body" and "fixed number of iterations". On the RISC-V side, without the embodiments of this application, the RISC-V compiler may consider the expanded code size too large to be conducive to caching, and choose not to unroll or partially unroll. When applying the embodiments of this application, the compiler forces the reading and execution of the "unroll 4 times" instruction in the profile. The loop is unrolled equally in the IR of both architectures, eliminating the differences in the number of basic blocks and layout caused by different loop structures.

[0106] In the consistency of control flow simplification, the x86 compiler analyzes and identifies code paths (such as error handling branches) that are almost impossible to execute (cold paths). Therefore, it simplifies the control flow—for example, moving the code for that path to the end of a function and adjusting jump instructions to optimize the instruction continuity of hot paths. Without the embodiments of this application, the RISC-V compiler may generate different control flow graphs. When applying the embodiments of this application: the compiler strictly reproduces all control flow transformations on the x86 side. This is the most direct step in achieving basic block alignment. It ensures that the IRs of the two architectures have the exact same set of basic blocks, the same jump relationships, and the same boundary divisions. This makes "basic block A" a completely equivalent entity in the IRs of x86 and RISC-V.

[0107] This step forces alignment between the x86 and RISC-V architectures' IRs in terms of the structure of functions, basic blocks, and control flow paths.

[0108] Running a pre-compiled instrumented binary on an x86 platform generates a ProfileD file that records runtime information about the program. When compiling source code for a RISC-V architecture, use `-fprofile-use=`. <dir>The / x86_runtime_profile option can draw on x86 compilation optimization experience. Specifically, it will insert information such as the number of function executions and the execution frequency and jump situation of basic blocks at the IRIR level. The compiler will then use this information to guide optimization.

[0109] In some embodiments, the RISC-V architecture uses ProfileC to guide compilation, instrumentation, and execution, generating a runtime ProfileD file.

[0110] Merge ProfileC and ProfileD files to generate ProfileE.

[0111] Specifically, the LLVM compiler compiles and generates the executable file based on the ProfileE file. It performs classic PGO optimizations, such as: Basic block reordering: placing frequently executed basic blocks in adjacent memory locations to improve instruction cache efficiency; Function reordering: grouping hot functions together to optimize instruction locality; Register allocation optimization: allocating more register resources to frequently executed code paths; Prediction optimization: guiding the generation of the branch predictor based on branch probabilities.

[0112] To ensure the optimization effect, this embodiment also introduces a feedback verification loop, which can perform secondary profile collection. Using the RISC-V binary file generated after the porting and optimization, it is run in a real environment to collect a new runtime profile. The performance of this iteration is compared with the initial version. If the performance improvement does not meet expectations, it indicates that the ported profile information may not be fully suitable for the RISC-V architecture. In this case, some or all of the original profiles can be discarded in the next compilation, and instead, the new profile collected in this iteration or architecture-independent heuristic optimizations can be relied upon to achieve adaptive optimization.

[0113] In some embodiments, when compiling source code for the RISC-V architecture, the compiler option -fprofile-use= is used. <dir>The ` / x86_runtime_profile` method loads the runtime profile file previously collected on the x86 platform. This process is not a simple "learning from experience," but a precise, automated optimization process that occurs within the compiler. Its core mechanism is as follows:

[0114] To bind x86 behavioral data to the RISC-V code structure, the compiler performs the following operations: First, it matches the IR generated from the source code currently being compiled for RISC-V with the program structure recorded in the x86 runtime ProfileA file. Since the IR structure alignment between the two architectures is ensured at compile time, the compiler can then losslessly and accurately map the x86 profile data to the corresponding RISC-V code units. For example, "function A was called 1000 times" recorded in the x86 profile will be accurately associated with "function A" in the RISC-V compilation flow. Similarly, "basic block B (located in the if true branch) was executed 800 times" recorded in the x86 profile will be accurately associated with "basic block B" in the RISC-V compilation flow, which has the exact same structure.

[0115] After mapping, the compiler inserts special profile annotations for various code elements at the RISC-V IR level. These annotations are essentially "performance tags" for the code, specifically including: function execution count: marking hot and cold functions; basic block execution frequency: identifying the most frequently executed core paths in the program; branch jump probability: recording the probability of each if-else and switch-case branch being executed (e.g., the probability of an if condition being true is 90%). At this point, IR is no longer just a logical representation of the program, but becomes an optimization blueprint with an execution heatmap.

[0116] The compiler performs targeted optimizations based on "heatmaps," and the instruction references (IRs) carrying this annotation information enter subsequent optimization stages. The compiler no longer relies on general heuristics but makes extremely precise optimization decisions based on the actual "execution heatmap." Key optimization techniques include: Function inlining: Inlining frequently called small functions directly to the call site, eliminating function call overhead. The compiler prioritizes inlining functions marked as hotspots by the profile. Basic block layout optimization: Arranging frequently executed basic blocks contiguously in memory. This significantly improves instruction cache locality and reduces cache misses. Branch optimization: Based on jump probabilities, branches with higher probabilities are scheduled for sequential execution, while branches with lower probabilities are set as branches requiring jumps. This optimizes the processor's branch prediction unit performance. Cold paths can be moved to the end of the code segment to avoid occupying valuable hotspot code space. Register allocation: Allocating more physical registers for frequently executed code paths to reduce memory access.

[0117] This application embodiment uses the compiler to treat the observed runtime behavior of programs on the x86 platform as prior knowledge to guide the better construction and optimization of code on the RISC-V platform. This application embodiment innovatively solves the core challenge of cross-architecture IR structure alignment by separating PGO information into two dimensions: compile-time decisions and runtime frequencies, and utilizing compile-time profiles. This enables lossless portability of runtime profiles, ultimately replicating or even surpassing the optimization effects on the source architecture (x86) on the target architecture (RISC-V). This method provides a systematic and highly feasible solution to the cross-platform performance migration problem in the era of heterogeneous computing.

[0118] It should be noted that this application first proposes a two-step cross-architecture profile information migration method, which innovatively combines compile-time profile information with runtime profile information. This method first aligns the IRs (Integrated Reference Components) of different architectures using compile-time profile information, thereby achieving accurate and efficient application of runtime program behavior information in new architectures and avoiding the waste or invalidation of optimization experience. Specifically, it collects compile-time profile information (such as function inlining decisions, loop unrolling decisions, control flow optimization decisions, etc.) and ensures the consistency of the IR structure between different architectures. This compile-time optimization decision information can help the compiler perform correct optimization migration when crossing architectures, ensuring that the program's structure on the target architecture is similar to that of the original architecture. Thus, it innovatively combines compile-time profile information with runtime profile information, solving the problem of inaccurate application of runtime profile information caused by inconsistent IR structures.

[0119] Next, this application proposes a novel compile-time profile information acquisition method. This method focuses on key compiler optimization techniques such as function inlining, loop unrolling, and control flow simplification, collecting detailed optimization information, such as whether functions are inlined and the number of loop unrolls, to guide fine-grained performance tuning on emerging architectures. By focusing on the main optimization characteristics of optimization strategies such as function inlining and loop unrolling, fine-grained guidance for fine-tuning performance on emerging architectures can be provided during cross-architecture profile information migration.

[0120] Finally, this application proposes a heuristic optimization method based on runtime feedback information. Building upon the traditional runtime profile information flow, it further collects the dynamic execution effect of function inlining, evaluating the actual effect of inlining through fine-grained features such as the execution time, memory access pattern, and cache hit rate of the inlined function. This method utilizes real-time feedback from runtime data to ensure the compiler automatically adjusts the inlining strategy in the next compilation round, avoiding the reuse of ineffective optimizations. It automatically adjusts the optimization strategy based on runtime performance. If a specific optimization behavior is detected to cause performance degradation, such as a decrease in cache hit rate or an increase in memory overhead, the compiler will automatically correct or roll back the optimization behavior in the next optimization round.

[0121] Next, the method of the present invention will be described in detail with reference to another specific embodiment. For example... Figure 8 As shown, a compilation apparatus for migrating profile information across architectures includes:

[0122] The acquisition module is used to acquire first profile information obtained during program compilation and second profile information obtained during runtime in the x86 compiler. The first profile information includes decision information of the program during the optimization process of compilation, and the second profile information includes feature data of the program during actual runtime.

[0123] The processing module is used to map the first Profile information to the compilation process when compiling a program using the RISC-V compiler to obtain the IR of the program; and to optimize the IR of the program using the first Profile information and the second Profile information to generate the executable file of the program.

[0124] In a specific embodiment of the present invention, the above-mentioned acquisition module is used to evaluate each function call point and determine whether the called function should be inlined. The first Profile information includes inlining judgment information and cost information of the function call point.

[0125] In a specific embodiment of the present invention, the above-mentioned acquisition module is used to evaluate the loop unrolling strategy based on the size and number of iterations of each loop when there is a loop structure in the function, and the first Profile information includes the loop unrolling strategy.

[0126] In a specific embodiment of the present invention, the above-mentioned acquisition module is used to optimize the CFG of the program and record the optimization information into the first Profile information.

[0127] In a specific embodiment of the present invention, the processing module is used by the RISC-V compiler to read the function inlining information in the first Profile information, bypass its own cost model, and perform the same function inlining operation as the function inlining information.

[0128] The RISC-V compiler reads the loop unrolling strategy from the first Profile information and executes the loop unrolling strategy.

[0129] The RISC-V compiler reads the control flow simplification information from the first Profile information and executes the control flow transformation in the control flow simplification information.

[0130] In a specific embodiment of the present invention, the processing module is used to optimize the IR of the program using the first Profile information and the second Profile information, including:

[0131] Using the function call count, basic block execution frequency, and jump information from the second Profile information, Profile annotations are inserted into the IR of the program, and the IR of the program after annotation is optimized using the first Profile information to generate the executable file of the program.

[0132] This invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a compilation method for cross-architecture migration of profile information.

[0133] This invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of a compilation method for cross-architecture migration of profile information as described above.

[0134] In addition, combined Figure 1 The compilation method for cross-architecture migration of profile information described in this embodiment of the invention can be implemented by an electronic device, such as a computer device. Figure 9 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention.

[0135] In some embodiments, the computer device may further include a communication interface 83 and a bus 80. For example, Figure 9 As shown, the processor 81, memory 82, and communication interface 83 are connected through bus 80 and complete communication with each other.

[0136] Specifically, the processor 81 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0137] The memory 82 can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions executed by the processor 81.

[0138] The processor 81 reads and executes computer program instructions stored in the memory 82 to implement any of the compilation methods for cross-architecture migration of Profile information in the above embodiments.

[0139] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0140] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.< / dir> < / dir>

Claims

1. A compilation method for migrating profile information across architectures, characterized in that, The method includes: Using an X86 compiler, the program collects first profile information obtained during compilation and second profile information obtained during runtime. The first profile information includes optimization decision information during the program compilation process, and the second profile information includes feature data of the program during actual runtime. When compiling a program using a RISC-V compiler, the first Profile information is mapped to the compilation process to obtain the intermediate representation (IR) of the program. Using the second Profile information, the IR of the program is optimized to generate the executable file of the program.

2. The method according to claim 1, characterized in that, The first profile information obtained during the compilation of the data collection program includes: Each function call point is evaluated to determine whether the called function should be inlined. The first profile information includes inlining judgment information and cost information for the function call point.

3. The method according to claim 2, characterized in that, The first profile information obtained during the compilation of the data acquisition program also includes: When a function contains a loop structure, the loop unrolling strategy is determined by evaluating the size and number of iterations of each loop, and the first Profile information includes the loop unrolling strategy.

4. The method according to claim 3, characterized in that, The first profile information obtained during the compilation of the data acquisition program also includes: The control flow graph (CFG) of the program is optimized, and the optimization information is recorded in the first profile information.

5. The method according to claim 4, characterized in that, When compiling a program using the RISC-V compiler, the first Profile information is mapped to the compilation process to obtain the IR of the program, including: The RISC-V compiler reads the function inlining information in the first Profile information, bypasses its own cost model, and performs the same function inlining operation as the function inlining information. The RISC-V compiler reads the loop unrolling strategy from the first Profile information and executes the loop unrolling strategy. The RISC-V compiler reads the control flow simplification information from the first Profile information and executes the control flow transformation in the control flow simplification information.

6. The method according to claim 1, characterized in that, The second profile information includes the number of function calls, the frequency of basic block execution, and jump information.

7. The method according to claim 6, characterized in that, The step of optimizing the IR of the program using the first profile information and the second profile information includes: Using the function call count, basic block execution frequency, and jump information from the second Profile information, Profile annotations are inserted into the IR of the program, and the IR of the program after annotation is optimized using the first Profile information to generate the executable file of the program.

8. A compilation apparatus for migrating profile information across architectures, characterized in that, The device includes: The acquisition module is used to acquire first profile information obtained during program compilation and second profile information obtained during runtime in the x86 compiler. The first profile information includes decision information of the program during the optimization process of compilation, and the second profile information includes feature data of the program during actual runtime. The processing module is used to map the first Profile information to the compilation process when compiling a program using the RISC-V compiler to obtain the IR of the program; and to optimize the IR of the program using the first Profile information and the second Profile information to generate the executable file of the program.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the compilation method for cross-architecture migration of Profile information as described in any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the compilation method for cross-architecture migration of Profile information as described in any one of claims 1 to 7.

Images