Optimized compiling method and device and computing equipment

Abstract

The invention discloses an optimization compiling method and device and computing equipment. The computing device may edit the compiler and the AutoFDO. AutoFDO can analyze the storage information of various types of memories when an executable program runs and the corresponding relationship between the instructions of the corresponding system architecture instruction set of the disassembly file and each row of codes in the source code, so as to obtain the specific address information of each row of codes in the source code for accessing the memory; and the specific address information of each row of codes in the source code for accessing the memory is sent to the compiler. In the process of optimizing compiling, the compiler can change the scheduling behavior of the instruction for accessing the memory based on the specific address information of the memory accessed by each row of codes in the source code, so that the memory access delay is reduced, part of instructions are merged, and the performance of the finally generated executable program is improved.

Description

Technical Field

[0001] This invention relates to the field of program programming technology, and in particular to an optimized compilation method, apparatus, and computing device. Background Technology

[0002] Profile-guided optimization (PGO) is a compiler optimization technique that uses performance data based on real-world runtime conditions to guide the compiler in generating more optimized code. Open-source compilers can leverage PGO to optimize source code and improve the performance of executable programs.

[0003] In related technologies, compilers can insert detection code into the executable program during the compilation process to calculate the number of executed code blocks and branch jumps, and write the statistics to a configuration file. When the compiler compiles the source code a second time, it can read the statistics from the configuration file to evaluate the cost model for optimization, allowing the compiler to make better optimization decisions and thus better optimize the executable program. However, the act of the compiler inserting detection code intrudes into and alters the original source code of the executable program, which not only reduces the security and reliability of the source code but also reduces the performance of the executable program and increases its bloat. Summary of the Invention

[0004] To address the aforementioned problems, embodiments of this application provide an optimized compilation method. By obtaining the specific address information of each line of code in the source code accessing different types of memory, the scheduling behavior of memory access instructions and the merging of some instructions can be modified based on this specific address information, thereby improving the performance of the final executable program. Furthermore, this application also provides an optimized compilation apparatus and computing device corresponding to this optimized compilation method.

[0005] Therefore, the following technical solutions are adopted in the embodiments of this application:

[0006] In a first aspect, embodiments of this application provide an optimized compilation method, comprising: acquiring storage information, wherein the storage information refers to the address information of various memory accesses by the instructions of the executable program when running the executable program, the executable program being a program compiled based on source code; determining the memory access address information of each line of code in the source code based on a disassembled file and the storage information, wherein the disassembled file is a file obtained by disassembling the executable program, the disassembled file including the correspondence between instructions of a corresponding system architecture instruction set and each line of code in the source code; and optimizing the compilation of the source code using the memory access address information of each line of code in the source code to obtain an optimized executable program.

[0007] In this implementation, the method is typically run by a computing device. The computing device can use a compiler and AutoFDO. AutoFDO can parse the storage information of various types of memory during the execution of the executable program to obtain the specific memory address information for each line of code in the source code and the correspondence between the instructions of the corresponding system architecture instruction set in the disassembled file and each line of code in the source code. It then determines the specific memory address information for each line of code in the source code and sends this information to the compiler. During the optimization compilation process, the compiler can modify the scheduling behavior of memory access instructions based on the specific memory address information for each line of code in the source code, thereby reducing memory access latency and merging some instructions to improve the performance of the final executable program.

[0008] In one embodiment, before acquiring the stored information, the method further includes: compiling the source code using a compiler to obtain the executable program; and sending the executable program to a single board, the single board being used to run the executable program.

[0009] In this implementation, the computing device can pre-generate an executable program based on the source code to provide test files for the board under test in order to obtain optimization conditions.

[0010] In one embodiment, the single board includes the various types of memory, which include at least two types of memory, with different access latencies and different free storage spaces.

[0011] In this implementation, the single board can be configured with different types of memory to provide free storage space for storing data and instructions when the single board runs the executable program. Different types of memory have different access latency and free storage space. The computing device can optimize the memory access of each line of code in the source code based on the memory access latency and free storage space, which can improve the performance of the final executable program.

[0012] In one implementation, before determining the memory address information for each line of code in the source code based on the disassembled file and the storage information, the method further includes: obtaining the processor's runtime information when the executable program is running; and constructing a trace file based on the processor's runtime information and the storage information of the various memory types.

[0013] In this embodiment, after obtaining the storage information of various memory locations, the computing device can add the storage information of various memory locations to the original trace file, thereby further optimizing the compilation process based on the storage information of various memory locations in the original optimization scheme, so as to improve the performance of the final executable program.

[0014] In one implementation, before optimizing and compiling the source code using the memory address information of each line of code in the source code to obtain an optimized executable program, the method further includes: determining frequently executed code blocks in the source code based on the disassembled file and the processor's runtime information; and constructing a sampling profile file based on the memory address information of each line of code in the source code and the frequently executed code blocks in the source code.

[0015] In this embodiment, after obtaining the memory address information of each line of code in the source code, the computing device can add the memory address information of each line of code in the source code to the original profile file. This allows for further optimization of the compilation process based on the memory address information of each line of code in the source code, thereby improving the performance of the final executable program.

[0016] In one implementation, optimizing the source code by using the memory address information of each line of code in the source code to obtain an optimized executable program specifically includes: using the memory address information of each line of code in the source code to change the scheduling behavior of a specified instruction in the source code, and merging some instructions in the source code; and using frequently executed code blocks in the source code to recompile the source code after changing the instructions in the source code to obtain the optimized executable program.

[0017] In this implementation, the computing device can modify the scheduling behavior of memory access instructions based on the specific address information of each line of code in the source code, thereby reducing memory access latency and merging some instructions to improve the performance of the final executable program.

[0018] Secondly, embodiments of this application provide an optimized compilation apparatus, comprising: a transceiver unit, configured to acquire storage information, wherein the storage information refers to the address information of various memory accesses by instructions of the executable program when running the executable program, wherein the executable program is a program compiled based on source code; a processing unit, configured to determine the address information of memory accesses for each line of code in the source code based on a disassembled file and the storage information, wherein the disassembled file is a file obtained by disassembling the executable program, and the disassembled file includes the correspondence between instructions of a corresponding system architecture instruction set and each line of code in the source code; the processing unit is further configured to optimize and compile the source code using the address information of memory accesses for each line of code in the source code to obtain an optimized executable program.

[0019] In one embodiment, the processing unit is further configured to compile the source code using a compiler to obtain the executable program; the transceiver unit is further configured to send the executable program to the single board, and the single board is configured to run the executable program.

[0020] In one embodiment, the single board includes the various types of memory, which include at least two types of memory, with different access latencies and different free storage spaces.

[0021] In one embodiment, the transceiver unit is further configured to acquire the processor's operating information when the executable program is running; the processing unit is further configured to construct a trace file based on the processor's operating information and the storage information of the various memory locations.

[0022] In one embodiment, the processing unit is further configured to determine frequently executed code blocks in the source code based on the disassembled file and the processor's runtime information; and to construct a sampling profile file based on the memory address information of each line of code in the source code and the frequently executed code blocks in the source code.

[0023] In one embodiment, the processing unit is specifically configured to use the address information of memory accessed by each line of code in the source code to change the scheduling behavior of specified instructions in the source code, and to merge some instructions in the source code; and to use frequently executed code blocks in the source code to recompile the source code after changing the instructions in the source code to obtain the optimized executable program.

[0024] Thirdly, embodiments of this application provide a computing device, including: at least one memory; and at least one processor, the processor being configured to execute instructions stored in the memory to cause the computing device to perform the various possible implementations of the first aspect.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium including computer program instructions, which, when executed by a computing device, perform various possible implementations of the first aspect.

[0026] Fifthly, embodiments of this application provide a computer program product containing instructions, characterized in that the computer program product stores instructions that, when executed by a computing device, cause the computing device to implement various possible implementations of the first aspect. Attached Figure Description

[0027] The accompanying drawings used in the description of the embodiments or prior art are briefly introduced below.

[0028] Figure 1 A schematic diagram illustrating the process of compiler optimization of executable programs in related technologies;

[0029] Figure 2 This is a schematic diagram of the structure of an optimized compilation system provided in the embodiments of this application;

[0030] Figure 3 This is a flowchart illustrating an optimized compilation method provided in an embodiment of this application;

[0031] Figure 4 This is a schematic diagram of the structure of an optimized compilation device provided in the embodiments of this application. Detailed Implementation

[0032] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0033] In this article, the term "and / or" describes 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, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0034] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. For example, "first response message" and "second response message," etc., are used to distinguish different response messages, not to describe a specific order of response messages.

[0035] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0036] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0037] To address the issues arising from compiler optimization methods that insert detection code, related technologies have proposed an alternative approach to executable program optimization. For example... Figure 1 As shown, during the first compilation, the compiler of the relevant technology can compile the source code to obtain an executable program. The compiler can then disassemble the executable program to obtain a disassembled file. Simultaneously, the processor loads and runs the executable program to obtain a trace file showing the code execution path. Automated feedback-directed optimization (AutoFDO) can parse the disassembled file and trace file to obtain a profile file. The profile file includes information on the number of times code blocks are executed and the probability of branch jumps. During the second compilation, the compiler can utilize the profile file to help make optimization decisions during the optimization process, resulting in a better-performing executable program.

[0038] Compilers for related technologies can address the usability issues of instrumentation-based PGO techniques by leveraging feedback optimization features. However, AutoFDO does not support processing memory-related information in trace files, preventing the compiler from obtaining information about memory operations. Furthermore, the compiler lacks a memory optimization module specifically for PGO techniques, hindering targeted optimization of memory operations.

[0039] To address the shortcomings of related technologies, this application provides an optimized compilation method, an optimized compilation system, and a computing device. The computing device can use a compiler and AutoFDO. AutoFDO can parse the storage information of various types of memory during executable program execution and the correspondence between the instructions of the corresponding system architecture instruction set in the disassembled file and each line of code in the source code, determining the specific memory address information accessed by each line of code in the source code. This specific memory address information is then sent to the compiler. During the optimization compilation process, the compiler can modify the scheduling behavior of memory access instructions based on the specific memory address information of each line of code in the source code, thereby reducing memory access latency and merging some instructions to improve the performance of the final executable program.

[0040] Figure 2 This is a schematic diagram of the structure of an optimized compilation system provided in an embodiment of this application. For example... Figure 2 As shown, the optimized compilation system 20 includes a computing device 200 and a single-board unit 300. From a software perspective, the computing device 200 can be divided into a compiler 210 and an AutoFDO 220. Both the compiler 210 and the AutoFDO 220 are run by the processor inside the computing device 200.

[0041] Compiler 210 is a program that converts source code (high-level language) into object code (low-level language). Compiler 210 is an important tool in computer programming, capable of converting human-readable high-level language code into computer-executable machine code so that the computer can understand and execute it. In the embodiments of this application, during the process of compiling source code into an executable program, compiler 210 can compile according to the static characteristics of the source code to generate an executable program. Static characteristics refer to code attributes and structures visible at compile time, such as variable types, function and class definitions, and syntax structures.

[0042] In one embodiment, compiler 210 performs lexical and syntactic analysis, parsing the source code into an abstract syntax tree or other intermediate representation. During this process, compiler 210 analyzes the static features of the code, checking syntax rules, identifier declarations and usages, type checking, etc. Based on the analysis results, compiler 210 determines the correctness and legality of the source code and constructs corresponding data structures to represent the program's logical structure and characteristics. Next, compiler 210 performs semantic analysis and optimization, determining the static features and semantic meaning of the code. Compiler 210 can perform various optimization operations, such as constant folding, optimizing unnecessary calculations, and loop unrolling, to improve the efficiency and performance of the generated target code. Finally, compiler 210 converts the source code into machine code or other executable code to generate target code. During the generation of target code, compiler 210 can map the static features in the code to underlying machine instructions, generating an executable program or object file.

[0043] The executable program generated by compiler 210 can be disassembled to generate a disassembled file. Disassembly refers to the process of converting machine code into assembly language. Typically, the executable program generated by compiler 210 consists of machine code, which is binary instructions that a computer can directly execute. The disassembly process can restore the machine code instructions to their corresponding assembly language instructions, allowing humans to understand and read the program's assembly code. The disassembled file records information such as the program's assembly instructions, labels, and addresses, usually presented in text form. The disassembled text can be used for debugging, reverse engineering, code auditing, and other purposes, helping developers understand the program's underlying implementation details, analyze the program's algorithms and logic, and check for vulnerabilities or security risks. In this embodiment, the disassembled file includes line number information of the source code corresponding to the instructions of the corresponding system architecture instruction set. When compiler 210 performs disassembly, some debugging tools can provide the correspondence between the instructions of the corresponding architecture instruction set and each line of code in the source code. This correspondence may be embedded in the disassembled file in comments or other forms, associating the instructions of the corresponding system architecture instruction set with the line numbers or symbols of the source code. Developers can more accurately analyze program logic, debug code, and optimize performance by matching instructions in the corresponding system architecture instruction set with each line of code in the source code.

[0044] The single-board 300 is used to test the executable program of the computing device 200 and report the test results to the computing device 200. The single-board 300 can be a standalone test component, other computing devices, etc. The single-board 300 can be a motherboard, integrated circuits, etc., inside the computing device 200. The following example uses the single-board 300 as a standalone test component.

[0045] The single-board 300 may include a processor 310, various types of memory, and a performance monitoring unit (PMU) 340. The processor 310 may include multiple cores. Each core can perform all the computational and data processing functions of the processor 310. When the processor 310 runs an executable program, the latency of accessing different types of memory and the free storage space of each type of memory will vary. Generally, the shorter the latency of memory accessed by the processor 310, the smaller its free storage space. Conversely, the longer the latency of memory accessed by the processor 310, the larger its free storage space.

[0046] like Figure 2 As shown, the memory in the single-board 300 includes a shared L2 cache (SL2) 320 and synchronous dynamic random access memory (SDRAM) 330, configured for each core of the processor 310. When the processor 310 runs an executable program, accessing SL2 has the shortest latency, accessing SDRAM 330 has the longest latency, and accessing SL2 320 has a latency between SL2 and SDRAM 330. When the processor 310 runs an executable program, PL2 provides the least amount of free storage space, SDRAM 330 provides the most, and SL2 320 provides a free storage space between PL2 and SDRAM 330.

[0047] In this embodiment, when the processor 310 runs an executable program, the PL2 of each core provides fast access to the data and instructions required by the processor core. PL2, as a backup cache for the L1 cache, stores data blocks and instructions read from SL2 320 and SDRAM 330 for use by the core of processor 310. PL2 has low access latency and high bandwidth, which can accelerate data acquisition and processing, thereby improving processor performance.

[0048] The SL2 320 can reside in a shared on-chip interconnect network among multiple cores, providing data sharing and collaborative capabilities between them. For example, when a core needs to access data, and determines that the data is not in its configured PL2, it can retrieve the data from the SL2 320. The SL2 320 can also store data blocks from the SDRAM 330 for other cores to read quickly, reducing the number of accesses to the SDRAM 330 and improving overall system performance.

[0049] SDRAM 330, as part of main memory, is used to store the data and instructions required for accessing executable programs. When the processor determines that the data to be accessed is not in PL2 and SL2 320, it can retrieve the data from SDRAM 330. SDRAM 330 operates synchronously and, under the control of an external bus, provides high-speed data access and a large storage capacity.

[0050] PMU 214 can monitor the status of other devices on board 300 in real time, such as processor 310, and the PL2, SL2 320, and SDRAM 330 of each core of processor 310. In this embodiment, PMU 214 can monitor the running information of processor 310 when running an executable program, such as function call traces and branch jumps. PMU 214 can monitor the storage information of PL2 of each core of processor 310 when running an executable program, such as the specific address information when the executable program's instructions access PL2 memory, that is, the memory address corresponding to the executable program's instructions. PMU 214 can monitor the storage information of SL2 320 of processor 310 when running an executable program, such as the specific address information when the executable program's instructions access SL2 320 memory, that is, the memory address corresponding to the executable program's instructions. PMU 214 can monitor the storage information of SDRAM 330 when the processor 310 is running an executable program, such as the specific address information when the executable program's instructions access SDRAM 330 memory, that is, the memory address accessed by the executable program's instructions. Finally, PMU 214 can construct a trace file from the processor 310's running information and the storage information of PL2, SL2 320 and SDRAM 330 of each core. The executable program's instructions refer to the instructions in the instruction set of the corresponding system architecture that the executable program runs under.

[0051] AutoFDO 220 is a tool for optimizing binary executable files generated by compiler 210. AutoFDO 220 collects execution data during the runtime of the executable program's code and feeds this data back to compiler 210. During subsequent optimization compilation, this feedback information is used to better guide compiler 210's optimization decisions. In this embodiment, the user can manually input disassembled files and trace files into AutoFDO 220. After receiving the disassembled files and trace files, AutoFDO 220 parses them to obtain the processor 310's runtime information from the trace file, as well as the storage information of each core's PL2, SL2 320, and SDRAM 330, and the instructions of the corresponding architecture instruction set in the disassembled file, and the correspondence between the instructions of the corresponding architecture instruction set and each line of code in the source code.

[0052] AutoFDO 220 uses function call paths and branch jumps from trace files, combined with instructions from the corresponding system architecture instruction set in disassembled files, to statistically analyze the execution frequency and branch jump frequency of each function. AutoFDO 220 matches executed instructions with code regions to identify hotspot code areas, thus obtaining frequently executed code blocks. Based on the parsed executed instructions and frequently executed code blocks, AutoFDO 220 generates an initial profile file, which can be used to guide the optimization strategies of performance optimization tools.

[0053] Since AutoFDO 220 cannot parse storage information, computing device 200 can set up a parsing module 221 in AutoFDO 220. Parsing module 221 can determine the specific memory address information accessed by each line of code in the source code based on the memory access addresses corresponding to the instructions of the executable programs of each core's PL2, SL2 320, and SDRAM 330 in the trace file, and the correspondence between the instructions of the corresponding architecture instruction set in the disassembled file and each line of code in the source code. Because each line of code in the source code accesses specific memory addresses, parsing module 221 can also map virtual addresses to physical addresses, determining the specific storage device where the specific memory address information accessed by each line of code in the source code resides. AutoFDO 220 can combine the initial profile file and the specific memory address information accessed by each line of code in the source code output by parsing module 221 to form the final profile file, and send the final profile file to compiler 210.

[0054] After receiving the final profile file, compiler 210 performs a second compilation of the source code. Compiler 210 can be configured with a feedback optimization module 211. The feedback optimization module 211 can modify the scheduling behavior of memory access instructions based on the specific memory address information of each line of code in the source code provided in the final profile file. For example, the feedback optimization module 211 can utilize hardware features to schedule multiple instructions accessing distant memory to access nearby memory, thereby reducing memory access latency. Furthermore, the feedback optimization module 210 can merge some instructions based on the specific memory address information of each line of code in the source code. For instance, if the feedback optimization module 210 detects multiple adjacent distant memory accesses in the source code, it can optimize the instructions, consolidating multiple adjacent distant memory accesses into a single instruction, reducing the number of memory access instructions and improving the performance of the final executable program.

[0055] During performance optimization, compiler 210 uses the initial profile file within the final profile file to optimize the source code compiled a second time. Based on actual runtime data from the initial profile file, such as function execution frequency, loop iteration counts, and branch values, compiler 210 uses statistics and analysis to identify hotspot code and frequently occurring code paths, generating an optimization scheme. This scheme includes techniques such as code reordering, eliminating redundant calculations, loop unrolling, function inlining, and removing unreachable code. Compiler 210 can then select which code paths to optimize and when to optimize them, recompiling the source code to generate the final optimized target code, resulting in the final executable program.

[0056] In this embodiment, after the compiler compiles the executable program from the source code for the first time, the single-board computer runs the executable program. When the single-board computer runs the executable program, it can send the address information of each memory accessed to AutoFDO. AutoFDO can determine the specific address information of each line of code in the source code that accesses memory based on the storage information of various types of memory in the executable program and the correspondence between the instructions of the corresponding system architecture instruction set in the disassembled file and each line of code in the source code. When the compiler compiles the source code a second time, it can change the scheduling behavior of the memory access instructions based on the specific address information of each line of code in the source code, thereby reducing memory access latency and merging some instructions to improve the performance of the final executable program.

[0057] Figure 3 This is a flowchart illustrating an optimized compilation method provided in an embodiment of this application. Figure 3 As shown, the optimized compilation method is executed by the computing device 200, and the specific implementation process is as follows:

[0058] S301, compiler 210 compiles the source code into an executable program and sends the executable program to board 300.

[0059] The compiler 210 employs two compilation operations in the process of compiling the source code into an executable program. During the first compilation, the executable program generated by the compiler 210 can be run by the processor 310 to obtain state information when the computing device 200 runs the executable program. During the second compilation, the compiler 210 can compile the source code based on the state information, optimizing the compilation process to obtain executable program code with better performance.

[0060] During the initial compilation, compiler 210 compiles the source code based on its static characteristics, generating an executable program, which is then sent to board 300 for execution. Static characteristics refer to code attributes and structures visible at compile time, such as variable types, function and class definitions, and syntax structures. In one embodiment, compiler 210 performs lexical and syntactic analysis, parsing the source code into an abstract syntax tree or other intermediate representation. During this process, compiler 210 analyzes the static characteristics of the code, checking syntax rules, identifier declarations and usages, type checking, etc. Based on the analysis results, compiler 210 determines the correctness and legality of the source code and constructs corresponding data structures to represent the program's logical structure and characteristics. Next, compiler 210 performs semantic analysis and optimization to determine the static characteristics and semantic meaning of the code. Compiler 210 can perform various optimization operations, such as constant folding, optimizing unnecessary calculations, and loop unrolling, to improve the efficiency and performance of the generated target code. Finally, compiler 210 converts the source code into machine code or other executable code to generate target code. During the process of generating target code, compiler 210 can map static features in the code to underlying machine instructions to generate executable programs or object files.

[0061] After compiler 210 obtains the executable program, it performs a disassembly operation to generate a disassembled file. Disassembly is the process of converting machine code into assembly language. Typically, the executable program generated by compiler 210 consists of machine code, which is binary instructions that a computer can directly execute. The disassembly process can restore the machine code instructions to their corresponding assembly language instructions, allowing humans to understand and read the program's assembly code. The disassembled file records the program's assembly instructions, labels, addresses, and other information, usually presented in text format. Disassembled text can be used for debugging, reverse engineering, code auditing, and other purposes. It can help developers understand the program's underlying implementation details, analyze the program's algorithms and logic, and check for vulnerabilities or security risks.

[0062] In this embodiment, the disassembled file includes line number information of the source code corresponding to the instructions of the corresponding system architecture instruction set. When the compiler 210 performs disassembly, some debugging tools can provide the correspondence between the instructions of the corresponding system architecture instruction set and each line of code in the source code. This correspondence may be embedded in the disassembled file in the form of debug_info / debug_line comments or other forms, associating the instructions of the corresponding system architecture instruction set with the line numbers or symbols of the source code. Developers can use the correspondence between the instructions of the corresponding system architecture instruction set and each line of code in the source code to more accurately analyze the program logic, debug the code, and perform performance optimization.

[0063] S302, AutoFDO 220 retrieves storage information.

[0064] After receiving the executable program, the processor 310 on board 300 can run it. At this time, the PL2 cache of each core of processor 310 provides fast access to the data and instructions needed by the processor core. PL2, as a backup cache for the L1 cache, stores data blocks and instructions read from SL2 320 and SDRAM 330 for use by the core of processor 310. PL2 has low access latency and high bandwidth, which can accelerate data acquisition and processing, thereby improving processor performance.

[0065] The PMU 214 can monitor the status of other devices on the single-board 300 in real time, such as the processor 310, SL2 320, and SDRAM 330. The PMU 214 can monitor the execution information of the processor 310 when running an executable program, such as function call traces and branch jumps. The PMU 214 can monitor the storage information of the PL2 memory of each core of the processor 310 when running an executable program, such as the specific address information when the executable program's instructions access PL2 memory, i.e., the memory address corresponding to the instruction. The PMU 214 can monitor the storage information of the SL2 320 when the processor 310 runs an executable program, such as the specific address information when the executable program's instructions access SL2 320 memory, i.e., the memory address corresponding to the instruction. The PMU 214 can monitor the storage information of the SDRAM 330 when the processor 310 runs an executable program, such as the specific address information when the executable program's instructions access SDRAM 330 memory, i.e., the memory address corresponding to the instruction. Finally, PMU 214 can construct a trace file from the operating information of processor 310 and the storage information of PL2, SL2 320 and SDRAM 330 of each core. The executable program's instructions refer to the instructions in the instruction set of the corresponding system architecture under which the executable program runs.

[0066] S303, AutoFDO 220, determines the memory address information for each line of code in the source code based on the disassembled file and storage information.

[0067] Users can manually input disassembled files and trace files into the AutoFDO 220. After receiving the disassembled files and trace files, the AutoFDO 220 parses them to obtain the processor 310's operating information, the memory information of each core's PL2, SL2 320, and SDRAM 330, the instructions of the executable program in the disassembled file, and the correspondence between the executable program's instructions and each line of code in the source code.

[0068] AutoFDO 220 uses function call paths and branch jumps from trace files, combined with instructions from the corresponding system architecture instruction set in disassembled files, to statistically analyze the execution frequency and branch jump frequency of each function. AutoFDO 220 matches executed instructions with code regions to identify hotspot code areas, i.e., frequently executed code blocks. Based on the parsed executed instructions and hotspot code areas, AutoFDO 220 generates an initial profile file, which can be used to guide the optimization strategies of performance optimization tools.

[0069] AutoFDO 220 can determine the specific memory address information accessed by each line of code in the source code by using the memory access addresses corresponding to the instructions of the executable programs for each core's PL2, SL2 320, and SDRAM 330 in the trace file, as well as the correspondence between the instructions of the corresponding system architecture instruction set in the disassembled file and each line of code in the source code. Because of this specific memory address information, AutoFDO 220 can map virtual addresses to physical addresses to determine the specific storage device where the memory access information of each line of code in the source code resides. AutoFDO 220 can then combine the initial profile file and the specific memory address information of each line of code in the source code to form the final profile file, and send the final profile file to compiler 210.

[0070] S304, compiler 210 uses the memory address information of each line of code in the source code to optimize and compile the source code, resulting in an optimized executable program.

[0071] After receiving the final profile file, compiler 210 can optimize the second compilation process using it. Compiler 210 can modify the scheduling behavior of memory access instructions based on the specific memory address information of each line of code in the source code provided in the final profile file. For example, the feedback optimization module 210 can utilize hardware features to schedule multiple instructions accessing distant memory to accessing nearby memory, thereby reducing memory access latency. Furthermore, the feedback optimization module 210 can merge some instructions based on the specific memory address information of each line of code in the source code. For instance, if the feedback optimization module 210 detects multiple adjacent distant memory accesses in the source code, it can optimize the instructions, consolidating them into a single instruction, thus reducing the number of instructions and improving the performance of the final executable program.

[0072] Compiler 210 uses actual runtime data from the initial profile file, such as function execution frequency, loop iteration count, and branch values, to identify hotspot code and frequently occurring code paths through statistical analysis, generating an optimization scheme. This scheme includes techniques such as code reordering, eliminating redundant calculations, loop unrolling, function inlining, and removing unreachable code. Based on this optimization scheme, Compiler 210 selects which code paths to optimize and when to perform optimizations, recompiling the source code to generate the final optimized target code, resulting in the final executable program.

[0073] In this embodiment, the computing device 100 can use a compiler 210 and an AutoFDO 220. The AutoFDO 220 can parse the storage information of various types of memory used by the single-board 300 when running the executable program, and the correspondence between the instructions of the corresponding system architecture instruction set in the disassembled file and each line of code in the source code, determining the specific memory address information accessed by each line of code in the source code, and sending this information to the compiler 210. During the optimization compilation process, the compiler 210 can, based on the specific memory address information of each line of code in the source code, change the scheduling behavior of memory access instructions, thereby reducing memory access latency and merging some instructions to improve the performance of the final executable program.

[0074] Figure 4 This is a schematic diagram of the structure of an optimized compilation device provided in an embodiment of this application. Figure 4 As shown, the optimized compilation device 400 can be divided into a transceiver unit 410 and a processing unit 420 according to its execution functions. The specific implementation process of the optimized compilation device 400 is as follows:

[0075] The transceiver unit 410 is used to acquire memory information. Memory information refers to the address information of various memory locations accessed by the executable program's instructions when it runs. The executable program is a program compiled from source code. The processing unit 420 is used to determine the memory address information accessed by each line of code in the source code based on the disassembled file and the memory information. The disassembled file is a file obtained by disassembling the executable program. The disassembled file includes the correspondence between instructions of the corresponding system architecture instruction set and each line of code in the source code. The processing unit 420 is also used to optimize and compile the source code using the memory address information accessed by each line of code in the source code, obtaining an optimized executable program.

[0076] In one embodiment, the processing unit 420 is further configured to compile the source code using a compiler to obtain an executable program. The transceiver unit 410 is further configured to send the executable program to the single board, which then runs the executable program.

[0077] In one implementation, the board includes various types of memory. These various types of memory include at least two types. The access latency of the different types of memory is different. The free storage space of the different types of memory is also different.

[0078] In one embodiment, the transceiver unit 410 is further configured to acquire processor runtime information during the execution of the executable program. The processing unit is further configured to construct a trace file based on the processor runtime information and various memory storage information.

[0079] In one embodiment, the processing unit 420 is further configured to determine frequently executed code blocks in the source code based on the disassembled file and the processor's runtime information. The processing unit 420 is also configured to construct a sampling profile file based on the memory address information of each line of code accessing memory in the source code and the frequently executed code blocks in the source code.

[0080] In one implementation, the processing unit 420 is specifically used to utilize the memory address information accessed by each line of code in the source code, modify the scheduling behavior of specified instructions in the source code, and merge parts of the source code instructions. Specifically, the processing unit 420 is used to recompile the source code after modifying the instructions by utilizing frequently executed code blocks in the source code, thereby obtaining an optimized executable program.

[0081] This application embodiment also provides a computing device, which includes at least one memory and multiple processors, among which a main processor is included, the main processor being capable of performing tasks such as... Figures 1-3 The aforementioned corresponding protection technical solutions enable the computing device to have the technical effects of the aforementioned protection technical solutions.

[0082] This application embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed in a computer, causes the computer to perform the above-described actions. Figures 1-3 And any of the optimized compilation methods described in the corresponding description.

[0083] This application also provides a computer program product, which stores instructions that, when executed by a computer, cause the computer to perform the above-described actions. Figures 1-3 And any of the optimized compilation methods described in the corresponding description.

[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0085] Furthermore, various aspects or features of the embodiments of this application can be implemented as methods, apparatus, or articles of manufacture using standard programming and / or engineering techniques. The term "article of manufacture" as used in this application encompasses a computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact discs (CDs), digital versatile discs (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). Additionally, the various storage media described herein may represent one or more devices and / or other machine-readable media for storing information. The term "machine-readable medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0086] In the above embodiments, Figure 4The optimized compilation apparatus 400 described herein can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0087] It should be understood that in the various embodiments of this application, 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 this application.

[0088] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0089] In the several embodiments provided in this application, it should be understood that the disclosed systems, 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 system, 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 apparatuses or units may be electrical, mechanical, or other forms.

[0090] 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 purpose of this embodiment according to actual needs.

[0091] If the aforementioned function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application embodiment, essentially, or the part that contributes to the prior art, or a part of the technical solution, 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, a server, or an access network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. 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.

[0092] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.

Claims

1. An optimization compilation method, characterized in that: include: Acquiring storage information, wherein the storage information refers to address information of various memories accessed by instructions of the executable program when the executable program is run, wherein the executable program is a program compiled based on source code; Based on the disassembly file and the storage information, determining the address information of each line of code in the source code accessing the memory, the disassembly file being a file obtained by disassembling the executable program, and the disassembly file including the correspondence between the instructions of the corresponding system architecture instruction set and each line of code in the source code; The source code is optimized and compiled using the address information of each line of code in the source code to access the memory, thereby obtaining an optimized executable program.

2. The method according to claim 1, characterized in that Before acquiring the storage information, the method further includes: Compiling the source code by a compiler to obtain the executable program; The executable program is sent to a single board, and the single board is used to run the executable program.

3. The method according to claim 2, characterized in that The single board includes the various memories, and the various memories include at least two types of memories. The access delays of different types of memories are different, and the free storage spaces of different types of memories are different.

4. The method according to any one of claims 1 to 3, characterized in that: Before determining the address information of each line of code in the source code accessing the memory based on the disassembly file and the storage information, the method further includes: Acquiring operation information of the processor when running the executable program; A trace file is constructed based on the operation information of the processor and the storage information of the various memories.

5. The method according to claim 4, characterized in that Before optimizing and compiling the source code by using the address information of each line of code in the source code to access the memory to obtain the optimized executable program, the method further includes: Determining frequently executed code blocks in the source code based on the disassembly file and the operation information of the processor; A sampling profile file is formed based on the address information of memory access by each line of code in the source code and the frequently executed code blocks in the source code.

6. The method according to claim 5, characterized in that The optimizing and compiling the source code by using the address information of each line of code in the source code to access the memory to obtain the optimized executable program specifically includes: Using address information of each line of code in the source code to access memory, changing the scheduling behavior of specified instructions of the source code, and merging some instructions of the source code; The frequently executed code blocks in the source code are used to recompile the source code after the instructions of the source code are changed to obtain the optimized executable program.

7. An optimization compilation device, characterized in that: include: A transceiver unit, used to obtain storage information, wherein the storage information refers to address information of various memories accessed by instructions of the executable program when the executable program is run, and the executable program is a program compiled based on source code; A processing unit, configured to determine address information of memory accessed by each line of code in the source code based on a disassembly file and the storage information, wherein the disassembly file is a file obtained by disassembling the executable program, and the disassembly file includes a correspondence between instructions of a corresponding system architecture instruction set and each line of code in the source code; The processing unit is further used to optimize and compile the source code using the address information of each line of code in the source code accessing the memory to obtain an optimized executable program.

8. The device according to claim 7, characterized in that The processing unit is further used to compile the source code through a compiler to obtain the executable program; The transceiver unit is further used to send the executable program to the single board, and the single board is used to run the executable program.

9. The device according to claim 8, characterized in that The single board includes the various memories, and the various memories include at least two types of memories. The access delays of different types of memories are different, and the free storage spaces of different types of memories are different.

10. The device according to any one of claims 7 to 9, characterized in that: The transceiver unit is further used to obtain the operation information of the processor when running the executable program; The processing unit is further used to form a trace file based on the operation information of the processor and the storage information of the various memories.

11. The device according to claim 10, characterized in that The processing unit is further configured to determine a frequently executed code block in the source code based on the disassembly file and the operation information of the processor; and A sampling profile file is formed based on the address information of memory access by each line of code in the source code and the frequently executed code blocks in the source code.

12. The device according to claim 11, characterized in that The processing unit is specifically used to use the address information of each line of code in the source code to access the memory, change the scheduling behavior of the specified instructions of the source code, and merge some instructions of the source code; as well as The frequently executed code blocks in the source code are used to recompile the source code after the instructions of the source code are changed to obtain the optimized executable program.

13. A computing device, characterized in that: include: at least one memory; At least one processor, wherein the processor is configured to execute instructions stored in the memory so that the computing device executes the method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a computing device, the computing device performs the method according to any one of claims 1 to 6.

15. A computer program product comprising instructions, characterized in that The computer program product stores instructions, which, when executed by a computing device, enable the computing device to implement the method according to any one of claims 1 to 6.

Images