Compiler document processing method based on large language model, electronic equipment and medium

Abstract

The invention discloses a compiler document processing method based on a large language model, electronic equipment and a medium, and relates to the technical field of software tuning, the method comprises the following steps: determining optimization options respectively associated with each piece of statement information representing an optimization level or a compiling stage in a compiler document; performing optimization option aggregation processing of the same optimization level and the same rule cluster on all optimization options to obtain semantic blocks; the semantic blocks and preset staged prompt words are input into a large language model, a seven-tuple semantic unit for each optimization option is output and obtained, and the seven-tuple semantic units represent structured feature information of the optimization options in a compiler document under multiple dimensions; and optimizing a compiler corresponding to the compiler document according to all the seven-tuple semantic units. According to the method and the device, the compiler document can be accurately and effectively analyzed and optimized, so that the overall performance of the compiler can be improved.

Description

Technical Field

[0001] This application relates to specific software tuning technology, and in particular to compiler documentation processing methods based on large language models, electronic devices, and computer-readable storage media. Background Technology

[0002] Optimization of the compiler includes the analysis and optimization of the compiler requirements specification document (hereinafter referred to as the compiler document).

[0003] The analysis and optimization of compiler documentation can be achieved through a combination of manual annotation and rule engines. For example, manual review and categorization of compiler optimization options in the documentation can be done, including annotations of option names, functional descriptions, conditions of action, and dependencies with other options. Subsequently, rule engines, such as regular expressions, pattern matching, or specific parsers, can automate the remaining documentation to extract key information about some optimization options. For instance, regular expressions can be used to identify "option name -f" sequences and extract adjacent sentences as functional descriptions of the options. However, this approach relies on manually designed rules, leading to low efficiency, high labor costs, and low accuracy due to the potential for omissions or errors in manual annotation. Ultimately, this approach cannot accurately and effectively analyze and optimize compiler documentation, thus impacting the overall performance of the compiler.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a compiler documentation processing method, electronic device, and computer-readable storage medium based on a large language model, aiming to solve the technical problem of how to accurately and effectively analyze and optimize compiler documentation to support the improvement of the overall performance of the compiler.

[0006] To achieve the above objectives, this application proposes a compiler documentation processing method based on a large language model, the method comprising: Identify the optimization options in the compiler documentation that are associated with each statement, representing the optimization level or compilation stage. For each statement information, all optimization options are aggregated into optimization options of the same optimization level and the same rule cluster to obtain a semantic block. The rule cluster represents the semantic function information and / or option name information of the optimization option. The semantic block and the preset staged prompt words are input into the large language model, and the output is a seven-tuple semantic unit for each optimization option. The seven-tuple semantic unit represents the structured feature information of the optimization option in multiple dimensions in the compiler document. The compiler corresponding to the compiler document is tuned based on all seven-tuple semantic units.

[0007] In addition, to achieve the above objectives, this application also proposes an electronic device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the compiler document processing method based on a large language model as described above.

[0008] In addition, to achieve the above objectives, this application also proposes a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the compiler document processing method based on a large language model as described above.

[0009] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the compiler document processing method based on a large language model as described above.

[0010] In this embodiment, by determining the optimization options in the compiler document that are associated with each statement representing the optimization level or compilation stage, and aggregating all optimization options into optimization options of the same optimization level and the same rule cluster, a semantic block is obtained. This ensures that the optimization options contained in the semantic block belong to the same optimization level, and that the semantic function information and / or option name information match. This allows the compiler document to convert each optimization option into a semantically concentrated and context-complete semantic block, taking into account the characteristics of concentrated level definitions and scattered option descriptions. This enables subsequent large language models to perform model processing (such as information extraction) within a semantically consistent input range through semantic blocks, thereby improving the recognition accuracy and information coverage of the large language model. It utilizes a large language model combined with phased prompts to extract information from semantic blocks in stages, obtaining a seven-tuple semantic unit for each optimization option. This determines the structured feature information of the optimization option in multiple dimensions of the compiler documentation. Subsequently, the scattered and ambiguous natural language information (i.e., optimization options) in the compiler documentation can be systematically expressed through the seven-tuple semantic unit, reflecting the multi-dimensional information of the optimization option in the compiler documentation, such as function description, activation conditions, dependencies, conflicts, and inclusions. In other words, it can convert the unstructured content in the compiler documentation into a structured knowledge representation, thereby effectively improving the efficiency and accuracy of compiler testing, performance tuning, and the construction of highly reliable compilers. This enables accurate and effective analysis and optimization of compiler documentation to support the improvement of the overall performance of the compiler, such as improving the tuning effect of the compiler. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating the first embodiment of the compiler document processing method based on a large language model in this application. Figure 2 A schematic diagram illustrating a scenario provided for the first embodiment of the compiler document processing method based on a large language model in this application; Figure 3 This is a flowchart illustrating the second embodiment of the compiler document processing method based on a large language model in this application. Figure 4This is a flowchart illustrating the third embodiment of the compiler document processing method based on a large language model in this application. Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the compiler document processing method based on a large language model in the embodiments of this application.

[0014] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0015] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0016] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0017] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone; or a compiler; or an electronic device with compiler functions; or an electronic device capable of implementing the above functions; or a compiler document processing device based on a large language model; etc. The following description uses an electronic device as an example to illustrate this embodiment and the subsequent embodiments.

[0018] In this embodiment, the processing methods for analyzing and optimizing compiler documentation can include various approaches. For example, a combination of manual annotation and rule engines can be used. This primarily involves manually sorting and classifying compiler optimization options in the documentation, such as annotating the name, function description, conditions of action, and dependencies with other options. Subsequently, rule engines, such as those using regular expressions, pattern matching, or specific parsers, automatically process the remaining documentation content to extract key information about some optimization options. For instance, regular expressions can be used to identify the "option name-fX" format in the documentation and extract adjacent sentences as function descriptions of the options. Another approach is to use machine learning / NLP (Natural Language Processing)-based optimization parameter selection schemes, and through the mapping relationship between program features and optimization options, automatically predict or recommend the optimal combination of compiler parameters, thereby improving the execution performance of the target code or shortening compilation time.

[0019] Alternatively, since the analysis and optimization of compiler documentation relies on manual annotation or rule engine design, especially when dealing with multiple requirement specification documents for different compilers, it requires manually sorting out the document structure, designing rule templates and keyword libraries, which is time-consuming and labor-intensive, resulting in low efficiency and high labor costs in extracting compiler documentation. Furthermore, manual annotation is prone to omissions or errors, and machine learning / NLP-based optimization parameter selection schemes often fail to accurately identify the function, activation conditions, preconditions, and conflict relationships of optimization options when handling complex semantics, conditional dependencies, or cross-paragraph relationships. This leads to incomplete or erroneous extraction results, resulting in low accuracy and insufficient information completeness in the extraction of compiler documentation. Furthermore, optimization parameter selection schemes based on machine learning / NLP focus more on keyword matching or statistical feature extraction, lacking a deep understanding of the semantics of compiler optimization options, activation conditions, preconditions, and conflict relationships. Moreover, existing large models lack a structured extraction mechanism for compiler document features, resulting in unstable output content formats, inconsistent field definitions, and difficulty in identifying implicit conditional dependencies and semantic relationships in documents. Consequently, the extracted results are semantically inconsistent and unusable.

[0020] Based on the shortcomings of the aforementioned methods for analyzing and optimizing compiler documentation, this application introduces a large language model to automatically analyze and extract key information from compiler documentation (such as compiler requirements specification documents), and defines a seven-tuple (T = ...) of optimization options in the compiler documentation. option_name, description,activation_conditions, prerequisite_options, conflicting_options,containment_conditions, other_relations This paper establishes a structured information model that can fully describe the semantic attributes of compiler optimization options. This structured information model can systematically express the scattered and ambiguous natural language information in compiler documentation, and can simultaneously represent multi-dimensional information such as function descriptions, activation conditions, dependencies, conflicts, and inclusions. Through this structural definition method, unstructured content in compiler documentation can be transformed into unified, computable, and analyzable knowledge units (such as seven-tuple fields), providing a standardized semantic interface for subsequent large-scale model information extraction and dependency reasoning.

[0021] Optionally, considering the organizational characteristics of compiler documentation—namely, "centralized level definitions and scattered option descriptions"—this embodiment can also implement a semantic segmentation method based on the similarity between optimization levels and rule clusters. This method can automatically identify language boundaries and divide the compiler documentation according to its inherent hierarchical structure and naming conventions, resulting in semantic blocks. At a macro level, the document structure can be divided according to optimization levels (e.g., -O1, -O2, -O3) (i.e., the aggregation of optimization options at the same optimization level). At a local level, similar optimization options can be aggregated based on rule cluster characteristics (e.g., options with the same prefix or suffix, such as -ftree-*, -funroll-*, etc.) (i.e., aggregation of optimization options at the same optimization level and within the same rule cluster), resulting in semantic blocks. This approach can automatically generate short text blocks (i.e., semantic blocks) with concentrated semantics and complete context, enabling large language models to perform information extraction within a semantically consistent input range, significantly improving the recognition accuracy and information coverage of large language models.

[0022] Optionally, in this embodiment, a phased prompt-driven large language model extraction mechanism is also provided for the large language model. This mechanism addresses the coexistence of explicit definitions and implicit relationships in compiler documentation by dividing information extraction into two phases. The large language model can execute a first-stage task for the first phase and a second-stage task for the second phase based on the phased prompts. The first phase can focus on identifying and understanding the functions of optimization options in semantic blocks, extracting option names and functional descriptions. The second phase, based on the semantic understanding of the first phase, can identify the enabling, dependency, conflict, inclusion, and implicit relationships between various optimization options. This approach allows the large language model to first construct a semantic understanding space for optimization options and identify their logical connections at the semantic level. Especially when dealing with implicit relationships, the large language model can identify potential implicit relationships through semantic matching and contextual reasoning, thereby achieving unified modeling of explicit and implicit information in the compiler documentation.

[0023] Optionally, to address the shortcomings of high manual costs and poor adaptability of rule engines in compiler documentation analysis, this embodiment utilizes the natural language understanding and information extraction capabilities of large language models to automatically identify and extract key information of optimization options from unstructured compiler documentation, and construct structured knowledge representations (such as seven-tuple semantic units), thereby effectively improving the efficiency and accuracy of compiler testing, performance tuning, and the construction of highly reliable compilers.

[0024] Furthermore, in this embodiment, the semantic understanding and knowledge extraction capabilities of the large language model are utilized to automate the extraction and analysis of unstructured information in the compiler documentation. Since the large language model is pre-trained on a large corpus, it possesses the ability to perform semantic parsing and relation recognition of natural language descriptions. Therefore, in this embodiment, specific staged prompts can be designed to convert the descriptive text of optimization options in the compiler documentation into a structured information extraction task. This allows the large language model to identify key information such as the name, functional description, applicable conditions, dependencies, and conflict relationships of optimization options from the document (i.e., semantic blocks) based on contextual understanding.

[0025] Based on this, embodiments of this application provide a compiler documentation processing method based on a large language model, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the compiler document processing method based on a large language model according to this application.

[0026] In this embodiment, the compiler document processing method based on the large language model includes steps S10 to S40.

[0027] Step S10: Determine the optimization options in the compiler documentation that are associated with each statement information representing the optimization level or compilation stage. Optionally, compiler documentation can be documents used by the compiler during processing operations. Compiler documentation may include compiler requirements specification documents, which can be documents described in natural language that record information related to compiler optimization options. This information may include the function, purpose, applicable conditions, dependencies, and conflicts between optimization options.

[0028] Alternatively, compiler documentation (such as compiler requirements specification documents) can be a type of text data, typically organized by optimization level as the top-level unit, with descriptions of the specific optimization options enabled or associated with each optimization level distributed below it. These optimization options can be distributed in different locations within the compiler documentation, exhibiting a structural characteristic of "centralized level definitions and dispersed option descriptions".

[0029] Optionally, compiler documentation exhibits two general patterns: hierarchical activation relationships and rule cluster similarity. Therefore, compiler documentation can be divided based on these two general patterns to obtain semantic blocks.

[0030] Optionally, for hierarchical activation relationships, compiler documentation typically contains semantic patterns describing the relationship between different optimization levels and their subordinate options (i.e., optimization options belonging to that optimization level). For example, a certain type of optimization level enables a specific set of optimization options. This pattern may be described in various languages ​​in different compilers (e.g., "a higher optimization level enables the following options", "this level implies ..."), but essentially it reflects the mapping of "level → set of options".

[0031] Optionally, for rule cluster similarity, at each optimization level, aggregation can be based on the similarity of rule clusters of optimization options, such as common prefixes or the same optimization family. Examples include shared prefixes (-ftree-, -fpeel-), and control of similar optimization behaviors (such as loop unrolling, data flow propagation, etc.). These rule clusters reflect the semantic relevance of optimization options and should be maintained during slicing, avoiding being split into different blocks.

[0032] Optionally, optimization options can be control switches or parameters that the compiler allows users or the system to choose during program compilation, and are specific strategies used to affect code generation, performance improvement, or resource utilization.

[0033] Optionally, key information about optimization options can be extracted from the compiler requirements specification document. This optimization option information can be elements related to specific optimization options in the compiler requirements specification document, such as the option name, function description, activation conditions, prerequisite options, conflicting options, and relationships with other optimization options.

[0034] Alternatively, the optimization level can be a set of preset compilation strategies controlled by a single command-line flag (such as -O1, -O2, -O3, -Os), with the aim of providing different trade-offs between compilation time, the performance (execution speed) of the generated code, and its size.

[0035] Optionally, each optimization level includes one or more optimization options.

[0036] Alternatively, the compilation phase can be the compilation processing phase run by the compiler.

[0037] Optionally, the statement information representing the optimization level or compilation stage may include statements, paragraphs, and text information in the compiler documentation that describe the optimization level, and may also include statements, paragraphs, and text information in the compiler documentation that describe the stage.

[0038] Optionally, this embodiment can perform semantic segmentation of long compiler documents based on optimization level and rule cluster similarity according to the inherent structure and semantic features of the compiler document. This allows the compiler document to be divided into a group of short segments (i.e. semantic blocks) with concentrated semantics, complete content, and close internal connections without changing the text content in the compiler document. This enables the subsequent large language model to perform information extraction tasks within a smaller, semantically consistent context.

[0039] Optionally, a partitioning module unit can be set up to divide the compiler document into semantic blocks. This partitioning module unit can implement the operations of steps S10-S20 to obtain the semantic blocks corresponding to the compiler document. The input of this partitioning module unit can be a compiler requirements specification document of any format (such as the optimization option description of GCC (GNU Compiler Collection), LLVM, or Rustc (Rust compiler)), denoted as D. The output of this partitioning module unit can be a set of semantic blocks S={S1,S2,…,Sn}, where each semantic block Si contains several interrelated optimization options and their descriptions, dependencies, and activation conditions. Here, i is an integer from 1 to n, and n is an integer greater than 1.

[0040] Optionally, semantic pattern matching can be used to identify statements in the compiler documentation that represent optimization levels or compilation stages. Alternatively, language models can be used to perform text recognition on the compiler documentation to determine individual statements representing optimization levels or compilation stages. For example, segments describing different optimization levels or compilation stages.

[0041] Optionally, full-text search and identification can be performed on the compiler documentation to determine the optimization options corresponding to the optimization option information associated with each statement information (such as the text description information related to the optimization options and optimization option information). Full-text search and identification can be performed using a language model, or other methods can be used without restriction.

[0042] Step S20: For all optimization options corresponding to each statement information, perform optimization option aggregation processing for optimization options of the same optimization level and the same rule cluster to obtain a semantic block, wherein the rule cluster represents the semantic function information and option name information of the optimization option; Optionally, the semantic functional information of the optimization option may include the functional characteristics of the optimization option, such as the functional characteristics used for control flow optimization.

[0043] Optionally, the option name information of the optimization option may include the option name of the optimization option, the character or string information contained in the option name, the prefix information or suffix information of the option name, etc.

[0044] Optionally, after determining all optimization options corresponding to each statement in the compiler documentation, the compiler documentation can be divided into short passages or local text fragments that are semantically focused, content-complete, and internally closely related, and these fragments can be used as semantic blocks.

[0045] Optionally, for each statement information, all optimization options can be aggregated according to the same optimization level and rule cluster to obtain local text fragments, which are then used as semantic blocks. That is, for each text fragment representing an optimization option, aggregation processing is performed according to the rules for aggregation of optimization options with the same optimization level and rule cluster, resulting in multiple semantic blocks.

[0046] Optionally, each semantic block includes at least one optimization option or a local text fragment embodying the optimization option, and the original text order information of each optimization option (i.e., the order in the compiler document) is preserved.

[0047] Step S30: Input the semantic block and the preset staged prompt words into the large language model, and output a seven-tuple semantic unit for each optimization option. The seven-tuple semantic unit represents the structured feature information of the optimization option in multiple dimensions in the compiler document. Optionally, the structured feature information of optimization options in multiple dimensions in the compiler documentation can be the information represented by the seven-tuple of optimization options, and the structured feature information can be reflected by the fields (such as characters or strings) that represent the seven-tuple of optimization options.

[0048] Optionally, a unified information representation model can be established to describe all semantic features of compiler optimization options. This is achieved by structurally modeling the scattered, natural language descriptions in the compiler documentation and converting each optimization option into a seven-tuple semantic unit (i.e., a seven-tuple semantic unit) to support subsequent information extraction and dependency analysis based on a large language model.

[0049] Optionally, optimization options in compiler documentation contain various types of information, such as feature descriptions, default enable levels, dependencies, and conflict conditions. This information is distributed across different locations (e.g., different paragraphs) in the compiler documentation and is expressed inconsistently. Therefore, in this embodiment, to achieve consistent extraction and analysis across documents and compilers, a semantically complete and structurally unified representation can be defined, namely, a seven-tuple of optimization options. By abstracting optimization options into seven independently identifiable and interconnected fields using the seven-tuple, a unified expression framework for optimization options that balances information completeness and structural scalability can be established.

[0050] For example, for optimization option F, its complete information can be represented by a 7-tuple, namely: T = option_name, description, activation_conditions, prerequisite_options, conflicting_options, containment_conditions, other_relations ; The definitions of each field in the seven-tuple (i.e., the first field to the seventh field) are shown in Table 1 below (the options in Table 1 are optimization options or optimization options corresponding to optimization options).

[0051]

[0052] Table 1 Optionally, multiple dimensions (such as the dimensions corresponding to the seven fields) in the seven-tuple of optimization options can collectively cover all the logical relationships of optimization options that can be identified in the compiler documentation, that is, retaining functional descriptions while expressing hierarchical and dependency information, thereby achieving semantic completeness and structural uniformity of information extraction.

[0053] Alternatively, the seven-tuple of optimization options in this embodiment has the following advantages (semantic completeness, relational expressibility, and cross-compiler generality).

[0054] Optionally, the seven fields corresponding to the seven-tuple of optimization options (i.e., fields one through seven) can collectively cover all key information dimensions of the optimization options in the compiler documentation, such as definition, enablement, dependency, conflict, extension, and interconnection. This ensures that the information of all optimization options can be mapped to a finite set of fields. Through the design of semantic fields such as enablement, dependency, conflict, and inclusion, the seven-tuple of optimization options allows the logical relationships between optimization options to be explicitly represented in a structured manner, forming a traceable set of semantic relationships, providing a foundation for subsequent consistency verification and dependency analysis. Furthermore, the seven-tuple can be independent of specific document formats or compiler architectures (such as GCC, LLVM, Rustc), and can uniformly represent optimization options from different sources using the same field pattern.

[0055] Optionally, each optimization option can be semantically equivalent to an instance of a 7-tuple. The 7-tuple can be the smallest encapsulation unit for the information expression of the optimization option. By setting the 7-tuple corresponding to the optimization option, it is possible to transform the scattered natural language descriptions in different compiler documents into a unified, computable, and associative knowledge representation unit without depending on the specific document format of the compiler document, thus providing a unified semantic basis for the subsequent prompt word design and information extraction process.

[0056] Optionally, phased prompts can be set in advance to prompt the large language model to perform corresponding model training for the input semantic blocks.

[0057] Optionally, semantic blocks and phased prompts can be input into a pre-trained large language model. The large language model processes the semantic blocks in stages according to the phased prompts, extracts relevant parameter information from the semantic blocks, such as information related to optimization options, and performs corresponding model processing to output a seven-tuple semantic unit for each optimization option.

[0058] Step S40: Optimize the compiler corresponding to the compiler document based on all seven-tuple semantic units.

[0059] Optionally, after obtaining all the seven-tuple semantic units from the large language model output, the compiler can be tuned so that when the compiler runs and needs to call optimization options, it can generate the corresponding strategy based on the seven-tuple semantic unit corresponding to the optimization option and execute it, thereby improving the compiler's performance.

[0060] In addition, to aid in understanding the compiler document processing method based on the large language model in this embodiment, the following examples are provided.

[0061] For example, such as Figure 2 As shown, a document acquisition operation is first performed to obtain the compiler's documentation, such as the compiler requirements specification document. Then, the compiler documentation is processed by segmenting semantic blocks (the specific process can be referred to in steps S10-S20) to obtain multiple semantic blocks, such as semantic block b1, semantic block b2, semantic block b3, semantic block b4, etc. Each semantic block and the preset phased prompt words (PROMPT) are input into the large language model, and a JSON array (i.e., a seven-tuple semantic unit) is output. This array is written into the knowledge base for storage so that the compiler's strategy parameters can be tuned later based on the JSON array in the knowledge base.

[0062] In this embodiment, by identifying the optimization options in the compiler documentation that are associated with each statement representing the optimization level or compilation stage, and aggregating all optimization options into optimization options of the same optimization level and rule cluster, a semantic block is obtained. This ensures that the optimization options contained in the semantic block belong to the same optimization level, and that the semantic function information and / or option name information match. Furthermore, taking advantage of the concentrated level definitions and scattered option descriptions in the compiler documentation, each optimization option in the compiler documentation can be converted into a semantically concentrated and context-complete semantic block. This allows the subsequent large language model to perform model processing (such as information extraction) within a semantically consistent input range through the semantic block, thereby improving the recognition accuracy and information coverage of the large language model. It utilizes a large language model combined with phased prompts to extract information from semantic blocks in stages, obtaining a seven-tuple semantic unit for each optimization option. This determines the structured feature information of the optimization option in multiple dimensions of the compiler documentation. Subsequently, the scattered and ambiguous natural language information (i.e., optimization options) in the compiler documentation can be systematically expressed through the seven-tuple semantic unit, reflecting the multi-dimensional information of the optimization option in the compiler documentation, such as function description, activation conditions, dependencies, conflicts, and inclusions. In other words, it can convert the unstructured content in the compiler documentation into a structured knowledge representation, thereby effectively improving the efficiency and accuracy of compiler testing, performance tuning, and the construction of highly reliable compilers. This enables accurate and effective analysis and optimization of compiler documentation to support the improvement of the overall performance of the compiler, such as improving the tuning effect of the compiler.

[0063] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 In step S30, the semantic block and the preset phased prompt words are input into the large language model, and the output is a seven-tuple semantic unit for each optimization option, including steps S31 to S33.

[0064] Step S31: Input the semantic block and the preset phased prompt words into the big language model, and generate a first-stage task to instruct the big language model to perform functional semantic understanding of each optimization option in the semantic block, and a second-stage task to instruct the big language model to perform conditional association recognition of each optimization option in the semantic block based on the phased prompt words. Optionally, considering the complex semantic structure and coexistence of explicit and implicit relationships in current compiler documentation, staged prompt words can be set. This allows a mechanism that drives the large language model to extract information from semantic blocks through staged prompt words. This mechanism can combine the inherent features of the document represented by the semantic blocks, such as option hierarchy, rule cluster aggregation, and implicit dependencies, to achieve progressive information extraction from functional semantic understanding to option relationship modeling through a two-stage extraction process. By optimizing the logical organization and description of compiler-related technical documents, the semantic completeness and logical consistency of the structured results are ensured.

[0065] Optionally, the compiler documentation includes two levels of information: an explicit definition layer, which directly describes the function and activation method of each optimization option; and an implicit association layer, which uses conditional statements or indirect representations to show the dependencies and relationships between optimization options.

[0066] Optionally, a phased extraction mechanism can be used to assign the information at the two levels to different scanning tasks (i.e., the first-stage task and the second-stage task), so that the large language model can first understand the option semantics of the optimization options (i.e., functional semantic understanding), then identify the relationship network (i.e., conditional association relationship identification), and map the extraction results to the seven-tuple results, filling in the corresponding fields (such as the first field) at different stages.

[0067] Optionally, a first-stage task and a second-stage task can be performed to train a large language model based on the phased prompt words. The first-stage task can focus on defining information (such as semantic function information and option name information), and the second-stage task can focus on "relationship" information (such as enabling, dependency, conflict, inclusion, implicit connection, etc.).

[0068] Step S32: In the large language model, the semantic representation information of each optimization option is identified according to the first stage task. The semantic representation information represents the semantic function information and option name information of the optimization option. Optionally, in the first stage, the task objective of the large language model could be to identify the unique identifier (e.g., option name, such as "turn on switch 1") of each optimization option in the semantic block; and to understand its functional description, scope of application, and execution semantics. This corresponds to the explicit definition layer.

[0069] Therefore, the large language model can perform a single scan (i.e., text scan) on the semantic block according to the first stage task, and extract the semantic representation information of each optimization option in the semantic block, such as the semantic function information of the optimization option (e.g., "enable loop unrolling", "perform constant propagation optimization", "perform dead code deletion", "activate global data flow analysis" operations, etc.) and the option name information of the optimization option (e.g., "turn on switch 1").

[0070] Step S33: Based on the second-stage task and the semantic representation information of each optimization option, determine the conditional association relationship of each optimization option, obtain the seven-tuple semantic unit of each optimization option, and output each seven-tuple semantic unit.

[0071] Optionally, in the second stage, the task objective of the large language model can be to identify the logical connections between each optimization option in the semantic block, i.e., the corresponding implicit association layer.

[0072] Optionally, the large language model can determine the conditional relationships between optimization options based on the results of the first-stage task (i.e., the semantic representation information of each optimization option) and the second-stage task. These relationships include activation relationships (indicating that an optimization option or optimization level can activate another optimization option), dependency relationships (indicating that an optimization option can only take effect under specific conditions), conflict relationships (indicating that there is mutual exclusion or overriding between optimization options), inclusion relationships (indicating that an optimization option can automatically trigger other behaviors or another optimization option), and implicit relationships (when the compiler documentation or semantic block does not directly specify the associated optimization option, but its existence can be inferred through functional concepts, conditional expressions, or semantic hints, it is recorded as an implicit relationship).

[0073] Optionally, implicit associations can be indirect connections that are ambiguous in their description but semantically discernible, and can belong to any of the following: enable relationship, dependency relationship, conflict relationship, containment relationship, etc. For example, if the optimization option in the semantic block contains the text "If loop unrolling is active, two passes are performed", although the text does not specify the specific optimization option, the semantics extracted in the first stage can determine that "loop unrolling" corresponds to -funroll-loops (an optimization option for loop unrolling).

[0074] Optionally, the large language model can represent the conditional relationships corresponding to each determined optimization option in the form of fields of different dimensions (such as the first field to the seventh field), and add them to the preset seven-tuple template to obtain the structured feature information of the optimization option in multiple dimensions in the compiler document (i.e., the seven-tuple field corresponding to the optimization option).

[0075] Optionally, the 7-tuple field corresponding to the optimization option represents the 7-tuple corresponding to the optimization option.

[0076] Optionally, the seven-tuple field corresponding to each optimization option can be encapsulated to obtain the seven-tuple semantic unit corresponding to each optimization option, and the seven-tuple semantic unit corresponding to each optimization option can be output.

[0077] In this embodiment, by performing a first-stage task based on phased prompt words in a large language model, the semantic representation information of each optimization option is obtained. Then, a second-stage task is performed to obtain and output a seven-tuple semantic unit, thereby ensuring the accuracy of the output seven-tuple semantic unit.

[0078] Optionally, the structured feature information includes a seven-tuple field for optimization options.

[0079] Optionally, step S33, which involves determining the conditional association of each optimization option based on the semantic representation information of the second-stage task and each optimization option, and obtaining the seven-tuple semantic unit of each optimization option, includes steps a10-a30.

[0080] Step a10: Scan each optimization option according to the second phase task; Step a20: Perform semantic analysis based on the semantic representation information of the scanned optimization options to obtain the seven-tuple field of the scanned optimization options. The seven-tuple field includes a first field representing the option name information of the scanned optimization options, a second field representing the semantic function information of the scanned optimization options, a third field representing the display activation conditions of the scanned optimization options, a fourth field representing the preconditions required or dependent optimization options before the scanned optimization options take effect, a fifth field representing optimization options that are mutually exclusive with the scanned optimization options or other optimization options that disable the scanned optimization options, a sixth field representing optimization options or behaviors that are included, enabled or automatically triggered by the scanned optimization options, and a seventh field representing other semantic relationships of the scanned optimization options. Step a30: Encapsulate the seven-tuple field into a JSON array, and output the JSON array as the seven-tuple semantic unit corresponding to the scan optimization options.

[0081] Optionally, when the large language model performs information extraction processing for each optimization option based on the semantic representation information of the second-stage task and each optimization option, the fields representing the logical relationship of the optimization options extracted for each optimization option can be added to the seven-tuple template to obtain the structured feature information of the optimization option in multiple dimensions in the compiler document, that is, the seven-tuple field, and encapsulate it into a JSON array for output.

[0082] Optionally, the large language model performs the first-stage task in the first stage, constructing a functional semantic space for optimization options (i.e., semantic representation information corresponding to each optimization option). Then, in the second stage, it performs the second-stage task, which involves establishing a network of associations between optimization options within the functional semantic space obtained in the first stage, ultimately resulting in a seven-tuple field with seven-tuples as the unified structural unit. option_name, description, activation_conditions, prerequisite_options, conflicting_options, containment_conditions, other_relations It is then encapsulated as a JSON array for output.

[0083] Optionally, this embodiment can perform result verification and organization on the seven-tuple semantic units output by the large language model. This includes performing syntax and field integrity checks to ensure each entry conforms to the seven-tuple structure requirements, merging and deduplicating duplicate or partially overlapping option entries, and maintaining data consistency and traceability order. The output seven-tuple semantic units can also be stored and applied. Verified seven-tuple semantic units are uniformly saved as standardized files for querying, visualization, and subsequent analysis. These seven-tuple semantic units can be directly used for compiler testing and verification, optimization option dependency analysis, and automated tuning research; that is, they can be used for compiler tuning.

[0084] In this embodiment, when the second-stage task is executed in the large language model, the corresponding seven-tuple field can be determined based on the semantic representation information of the optimization options, and it can be encapsulated as a JSON array for output. This can convert the unstructured content in the compiler document into a structured knowledge representation, thereby effectively improving the efficiency and accuracy of compiler testing, performance tuning, and the construction of a highly reliable compiler.

[0085] Based on the first or second embodiment of this application, in the third embodiment of this application, the same or similar content as the first or second embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 In step S20, all optimization options corresponding to each statement information are aggregated for optimization options of the same optimization level and the same rule cluster to obtain semantic blocks, including steps S21-S23.

[0086] Step S21: Determine the optimization level corresponding to each statement information; Step S22: Based on the optimization level and at least one optimization option belonging to the same statement information, construct a mapping table containing the mapping relationship between at least one optimization level and at least one optimization option; Step S23: Determine the optimization options of the same optimization level and the same rule cluster according to the mapping table, and perform aggregation processing on the optimization options of the same optimization level and the same rule cluster to obtain semantic blocks.

[0087] Optionally, the optimization level corresponding to different statement information in the compiler documentation can be determined. For example, if the optimization level of the statement information is -O1, then the optimization level corresponding to that statement information can be determined to be -O1. If the optimization level of the statement information is -O2, then the optimization level corresponding to that statement information can be determined to be -O2.

[0088] Optionally, optimization option parameters associated with each statement can be extracted from the compiler documentation, and a mapping table between optimization levels and options can be established. This mapping table can include multiple optimization levels and optimization options corresponding to each optimization level, with each optimization level corresponding to at least one optimization option.

[0089] For example, the semantic pattern function of the device or compiler itself can be used to detect and identify natural language structures that enable relationships in the compiler documentation (such as 'turns on the following flags', 'implies the following optimizations', 'this level enables', etc.) to automatically capture the 'level-option' mapping relationship, build the corresponding mapping table, and apply it to compiler documentation with different expressions.

[0090] Optionally, optimization options can be aggregated based on the corresponding mapping relationship between each optimization level and optimization option included in the mapping table to indirectly divide the compiler document and obtain each semantic block. The aggregation processing rule can be to aggregate optimization options that belong to the same optimization level and whose rule cluster similarity is greater than a preset similarity threshold (i.e., the same rule cluster) into structurally consistent local text fragments and use them as the corresponding semantic blocks.

[0091] In this embodiment, a mapping table is constructed based on the optimization level and optimization options belonging to the same statement information. Then, the optimization options are aggregated based on the mapping table to obtain semantic blocks, thereby ensuring the accuracy and effectiveness of the obtained semantic blocks.

[0092] Optionally, step S23, which involves determining the optimization options for the same optimization level and the same rule cluster based on the mapping table, includes steps b10-b20.

[0093] Step b10: Determine the option name information for each optimization option corresponding to each optimization level in the mapping table; Step b20: All optimization options with the same optimization level and matching option name information are treated as optimization options of the same optimization level and the same rule cluster.

[0094] Optionally, when performing the aggregation of optimization options, all optimization options corresponding to each optimization level can be determined first based on the mapping table, and the option name information of each optimization option can be identified, such as the option name of the optimization option, or the prefix information contained in the option name, or the suffix information contained in the option name, or the identification information at any position in the option name.

[0095] Optionally, optimization options belonging to the same optimization level and containing the same prefix information in their option names can be aggregated into a semantic block, belonging to the same optimization level and rule cluster. Similarly, optimization options belonging to the same optimization level and containing the same suffix information in their option names can be aggregated into a semantic block, belonging to the same optimization level and rule cluster. Furthermore, optimization options belonging to the same optimization level and containing the same option name can be aggregated into a semantic block, belonging to the same optimization level and rule cluster. Finally, optimization options belonging to the same optimization level and containing the same identifier information in the same position in their option names can be aggregated into a semantic block.

[0096] In this embodiment, optimization options with the same optimization level and matching option name information are aggregated to obtain semantic blocks, thereby ensuring the accuracy and effectiveness of the obtained semantic blocks.

[0097] Optionally, step S23, which involves determining the optimization options for the same optimization level and the same rule cluster based on the mapping table, includes steps b30-b40.

[0098] Step b30: Determine the semantic function information of each optimization option corresponding to each optimization level in the mapping table; Step b40: All optimization options with the same optimization level and matching semantic functional information are treated as optimization options of the same rule cluster with the same optimization level.

[0099] Optionally, when performing the aggregation of optimization options, all optimization options corresponding to each optimization level can be determined first based on the mapping table, and the semantic function information of each optimization option can be identified, such as the function of the optimization option (e.g., to start the next compilation stage).

[0100] Optionally, similarity correlation detection can be performed on the semantic functional information of each optimization option under the same optimization level. If the similarity correlation between at least two optimization options is greater than a preset correlation threshold, then the semantic functional information of these at least two optimization options can be determined to be matched. For example, if the semantic functional information is related to data flow propagation, then their corresponding semantic functional information can be determined to be matched. Then, all optimization options at the same optimization level and with matched semantic functional information can be aggregated as optimization options of the same optimization level and the same rule cluster to obtain a semantic block.

[0101] In this embodiment, by aggregating optimization options with the same optimization level and matching semantic functional information, a semantic block is obtained, thereby ensuring the accuracy and effectiveness of the obtained semantic block.

[0102] Optionally, after step S23, which involves aggregating optimization options of the same optimization level and the same rule cluster to obtain a semantic block, steps c10-c50 are also included.

[0103] Step c10: If there are optimization options that have not been aggregated, then treat the optimization options that have not been aggregated as isolated option parameters, and check whether there are optimization options in the mapping table that have a contextual relationship with the isolated option parameters. Step c20: If it does not exist, construct a semantic block containing isolated option parameters; Step c30: If it exists, then the optimization option that has a contextual relationship with the isolated option parameter is taken as the neighbor option parameter, and the semantic functional weak association between the isolated option parameter and the neighbor option parameter is detected. Step c40: If there is a weak semantic association, then merge the isolated option parameters into the semantic block containing the neighbor option parameters. Step c50: If there is no weak semantic association, construct a semantic block containing isolated option parameters.

[0104] Optionally, optimization options that have not undergone aggregation (i.e., isolated option parameters) can also be processed accordingly to obtain semantic blocks corresponding to the isolated option parameters, i.e., text fragments containing the isolated option parameters.

[0105] Optionally, if there is one optimization level corresponding to one optimization option in the mapping table (i.e., there is only one optimization option that has a mapping relationship with the optimization level), then the optimization option can be used as an isolated option parameter; if there is one optimization level corresponding to multiple optimization options in the mapping table, but at least one optimization option has a rule cluster that is too different from the rule clusters of other optimization options and does not participate in the aggregation process, then it can be used as an isolated option parameter; alternatively, optimization options that do not appear in the mapping table in the compiler documentation can be used as isolated option parameters.

[0106] Optionally, for isolated option parameters, it can be checked whether other optimization options in the mapping table have a contextual association with the isolated option parameter in the compiler documentation. If there is an optimization option with a contextual association with the isolated option parameter, it can be used as a neighbor option parameter, and the number of neighbor option parameters can be at least one.

[0107] Optionally, it is possible to detect whether there is a weak semantic functional relationship between isolated option parameters and their corresponding neighboring option parameters, such as detecting whether isolated option parameters and neighboring option parameters belong to the same optimization stage or data structure.

[0108] Optionally, if a weak semantic relationship exists, such as isolated option parameters and neighboring option parameters belonging to the same optimization stage or data structure, then a semantic block containing neighboring option parameters can be determined, and the isolated option parameters can be incorporated into that neighboring option parameter semantic block. If no weak semantic relationship exists, then a semantic block containing isolated option parameters can be directly constructed, for example, by using a local text fragment containing isolated option parameters as the semantic block containing isolated option parameters.

[0109] Optionally, for the neighbor option parameter, it can be first detected whether the neighbor option parameter is an optimized option that has not been aggregated. If so, the operation of steps c10-c50 can be performed on the neighbor option parameter to obtain a semantic block containing the neighbor option parameter.

[0110] In this embodiment, by processing isolated option parameters accordingly, such as directly constructing semantic blocks for isolated option parameters and merging them into semantic blocks containing neighboring option parameters, it is possible to convert all optimization options in the compiler documentation into corresponding semantic blocks before proceeding with the subsequent large language model processing. This avoids the phenomenon of missing some optimization options when the large language model performs subsequent information extraction.

[0111] Optionally, before step S30, which inputs the semantic block and the preset phased prompt words into the large language model and outputs a seven-tuple semantic unit for each optimization option, steps d10-d30 are also included.

[0112] Step d10: Check whether the block length of each semantic block is within the preset block length range; Step d20: If there is a semantic block whose block length is not within the preset block length range, and the block length of the semantic block is greater than the maximum value within the preset block length range, then the semantic block is split by the optimization option to obtain a semantic block whose block length is within the preset block length range. Step d30: If there is a semantic block whose block length is not within the preset block length range, and the block length of the semantic block is less than the minimum value within the preset block length range, then the semantic blocks are merged to obtain a semantic block whose block length is within the preset block length range.

[0113] Optionally, there can be multiple semantic blocks, that is, there can be semantic blocks containing one optimization option or semantic blocks containing multiple optimization options.

[0114] Optionally, the preset block length range can be the range in advance where the large language model performs best, such as 300-800 words.

[0115] Optionally, after generating the semantic blocks corresponding to each optimization option, the block length of each semantic block can be detected to control the block length of each semantic block within the range that the large language model can process.

[0116] Optionally, the length of each semantic block can be detected. For semantic blocks whose length is within the preset block length range, no processing is performed. For example, if semantic block d1 contains 400 words, then within the range of 300-800 words, the length of semantic block d1 can be determined to be within the preset block length range.

[0117] Optionally, for semantic blocks whose block length is outside the preset block length range, but whose block length is greater than the maximum value of the preset block length range, optimization options can be split into smaller parts. Furthermore, when splitting optimization options within a semantic block, the original order of the optimization options in the compiler documentation must be preserved to ensure traceability of the optimization options.

[0118] For example, if semantic block d2 contains 900 words, which is clearly outside the 300-800 word range and exceeds the maximum value of the preset block length range of 800, then semantic block d2 can be split into optimization options. For instance, if semantic block d2 contains optimization option 1 with 300 words, optimization option 2 with 400 words, and optimization option 3 with 200 words, and the original order information of optimization option 1, optimization option 2, and optimization option 3 in the compiler documentation includes optimization option 1 being before optimization option 2, and optimization option 2 being before optimization option 3, then optimization option 1 can be split from semantic block d2 to obtain a semantic block with 300 words and a semantic block with 600 words, and the block lengths of both semantic blocks are within the preset block length range.

[0119] Optionally, for semantic blocks whose block length is outside the preset block length range, and whose block length is less than the minimum value of the preset block length range, semantic block merging can be performed to make the block length of the merged semantic block within the preset block length range. Furthermore, when merging semantic blocks, the original order information of optimization options in the compiler documentation must be preserved to ensure the traceability of optimization options.

[0120] Optionally, when merging semantic blocks, adjacent semantic blocks that are semantically continuous or logically dependent are merged first. For example, if there is semantic continuity or functional logical interdependence between optimization option 5 in semantic block d3 and optimization option 6 in semantic block d4, and the block length of semantic block d3 is less than the minimum value of the preset block length range, then semantic block d3 and semantic block d4 can be merged to obtain a new semantic block. The block length of the new semantic block can then be checked to see if it is within the preset block length range. If not, the corresponding semantic block merging or optimization option splitting steps are performed until the length of all semantic blocks obtained is within the preset block length range.

[0121] In this embodiment, by splitting or merging semantic blocks whose block length is outside the preset block length range, the block length of the semantic blocks finally input into the large language model is within the preset block length range. This enables the large language model to perform extraction within the semantically consistent input range, significantly improving the recognition accuracy and information coverage of the large language model.

[0122] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the compiler document processing method based on a large language model as described in Embodiment 1 above.

[0123] The following is for reference. Figure 5 The figure illustrates a structural diagram of an electronic device suitable for implementing embodiments of this application. The electronic devices in the embodiments of this application may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. The devices shown in the figure are merely examples and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0124] The electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for device operation. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. While electronic devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0125] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0126] The electronic device provided in this application employs the compiler documentation processing method based on a large language model as described in the above embodiments, which can accurately and effectively analyze and optimize compiler documentation to support improvements in the overall performance of the compiler. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the compiler documentation processing method based on a large language model provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0127] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0128] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0129] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the compiler document processing method based on a large language model in the above embodiments.

[0130] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0131] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0132] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by an electronic device, enable the electronic device to perform the steps of the aforementioned compiler document processing method based on a large language model.

[0133] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0134] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0135] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0136] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the compiler document processing method based on the large language model described above. This program can accurately and effectively analyze and optimize compiler documents to support improvements in the overall performance of the compiler. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the compiler document processing method based on the large language model provided in the above embodiments, and will not be repeated here.

[0137] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the compiler document processing method based on a large language model as described above.

[0138] The computer program product provided in this application can accurately and effectively analyze and optimize compiler documentation to support improvements in the overall performance of the compiler. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the compiler documentation processing method based on a large language model provided in the above embodiments, and will not be repeated here.

[0139] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A compiler document processing method based on a large language model, characterized in that, The method includes: Identify the optimization options in the compiler documentation that are associated with each statement, representing the optimization level or compilation stage. For all optimization options corresponding to each statement information, perform optimization option aggregation processing of the same optimization level and the same rule cluster to obtain a semantic block, wherein the rule cluster represents the semantic function information and / or option name information of the optimization option; The semantic block and the preset phased prompt words are input into the large language model, and the output is a seven-tuple semantic unit for each optimization option, wherein the seven-tuple semantic unit represents the structured feature information of the optimization option in multiple dimensions in the compiler document; The compiler corresponding to the compiler document is tuned based on all the seven-tuple semantic units.

2. The compiler document processing method based on a large language model as described in claim 1, characterized in that, The step of inputting the semantic block and preset staged prompt words into a large language model and outputting a seven-tuple semantic unit for each optimization option includes: The semantic block and preset phased prompt words are input into the large language model, and a first-stage task is generated based on the phased prompt words to instruct the large language model to perform functional semantic understanding of each optimization option in the semantic block, and a second-stage task is generated to instruct the large language model to perform conditional association recognition of each optimization option in the semantic block. In the large language model, the semantic representation information of each optimization option is identified according to the first stage task, wherein the semantic representation information represents the semantic function information and option name information of the optimization option; Based on the second-stage task and the semantic representation information of each optimization option, the conditional association relationship of each optimization option is determined, the seven-tuple semantic unit of each optimization option is obtained, and each seven-tuple semantic unit is output.

3. The compiler document processing method based on a large language model as described in claim 2, characterized in that, The structured feature information includes the seven-tuple field of the optimization options. The step of determining the conditional association relationships of each optimization option based on the semantic representation information of the second-stage task and each optimization option, and obtaining the seven-tuple semantic unit of each optimization option, includes: The optimization options are scanned according to the second phase task; Semantic analysis is performed based on the semantic representation information of the scanned optimization options to obtain a seven-tuple field of the scanned optimization options. The seven-tuple field includes a first field representing the option name information of the scanned optimization options, a second field representing the semantic function information of the scanned optimization options, a third field representing the display activation conditions of the scanned optimization options, a fourth field representing the preconditions required or dependent optimization options before the scanned optimization options take effect, a fifth field representing optimization options that are mutually exclusive with the scanned optimization options or other optimization options that disable the scanned optimization options, a sixth field representing optimization options or behaviors that are included, enabled or automatically triggered by the scanned optimization options, and a seventh field representing other semantic relationships of the scanned optimization options. The seven-tuple field is encapsulated into a JSON array, and the JSON array is output as the seven-tuple semantic unit corresponding to the optimization option of the scan.

4. The compiler document processing method based on a large language model as described in claim 1, characterized in that, The step of aggregating all optimization options corresponding to each statement information with optimization options of the same optimization level and the same rule cluster to obtain a semantic block includes: Determine the optimization level corresponding to each of the aforementioned statement information; Based on the optimization level belonging to the same statement information and at least one optimization option, construct a mapping table containing the mapping relationship between at least one optimization level and at least one optimization option; Based on the mapping table, optimization options of the same optimization level and the same rule cluster are determined, and the optimization options of the same optimization level and the same rule cluster are aggregated to obtain semantic blocks.

5. The compiler document processing method based on a large language model as described in claim 4, characterized in that, The step of determining the optimization options for the same optimization level and the same rule cluster based on the mapping table includes: Determine the option name information for each optimization option corresponding to each optimization level in the mapping table; All optimization options with the same optimization level and matching option name information are considered as optimization options of the same optimization level and the same rule cluster.

6. The compiler document processing method based on a large language model as described in claim 4, characterized in that, The step of determining the optimization options for the same optimization level and the same rule cluster based on the mapping table includes: Determine the semantic functional information of each optimization option corresponding to each optimization level in the mapping table; All optimization options that are at the same optimization level and whose semantic functional information matches are considered as optimization options of the same rule cluster at the same optimization level.

7. The compiler document processing method based on a large language model as described in claim 4, characterized in that, After the step of aggregating optimization options of the same optimization level and the same rule cluster to obtain semantic blocks, the following steps are included: If there are optimization options that have not been aggregated, then the optimization options that have not been aggregated are treated as isolated option parameters, and it is checked whether there are optimization options in the mapping table that have a contextual relationship with the isolated option parameters; If it does not exist, construct a semantic block containing the isolated option parameter; If they exist, the optimized option that has a contextual relationship with the isolated option parameter is taken as the neighbor option parameter, and the semantic functional weak association between the isolated option parameter and the neighbor option parameter is detected. If a weak semantic association exists, the isolated option parameter is merged into a semantic block that contains the neighbor option parameter; If there is no weak semantic association, then construct a semantic block containing the isolated option parameters.

8. The compiler document processing method based on a large language model as described in claim 1, characterized in that, Before the step of inputting the semantic block and preset staged prompt words into the large language model and outputting a seven-tuple semantic unit for each optimization option, the following steps are included: Detect whether the block length of each semantic block is within a preset block length range; If there is a semantic block whose block length is not within the preset block length range, and the block length of the semantic block is greater than the maximum value within the preset block length range, then the semantic block is split by the optimization option to obtain a semantic block whose block length is within the preset block length range. If there exists a semantic block whose block length is not within the preset block length range, and the block length of the semantic block is less than the minimum value within the preset block length range, then the semantic blocks are merged to obtain semantic blocks whose block length is within the preset block length range.

9. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the compiler document processing method based on a large language model as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the compiler document processing method based on a large language model as described in any one of claims 1 to 8.

Images