Method and device for combining large code language models (code-LLM) with compilers

Abstract

The disclosed exemplary apparatus includes interface circuitry, machine-readable instructions, and programmable circuitry to instantiate or execute at least one of the machine-readable instructions to receive input source code through a large code language model (LLM), generate one or more code representations of the input source code, analyze the one or more code representations of the input source code; and compile one or more code representations of the input source code into one or more executable instructions on the computer.

Description

FIELD OF DISCLOSUREThis disclosure relates generally to software processing and, more particularly, to methods and apparatus for combining large code language models (code LLMs) with compilers.PRIOR ARTLarge speech models (LLM) include artificial intelligence algorithms that operate in conjunction with neural network techniques and use a large number of parameters to interpret and generate computer-based code. Code sections or full programs are generated using LLM based on input instructions. Thus, the efficiency of code writing by LLM-based auto-completion and code generation can be improved.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 illustrates example components of a compiler including various program representations. FIG. 2 illustrates an example of providing a large language model (LLM) as a code editor plugin. FIG. 3 illustrates an example database with associations between an input program and a corresponding relevant program representation (e.g., abstract syntax tree (AST)). FIG. 4 illustrates associations between various program elements and their sub-trees in an abstract syntax tree (AST). FIG. 5 illustrates an example provisioning phase with an end-to-end scenario of database search including example code evaluator circuitry. FIG. 6 illustrates an exemplary serial program and parallel version proposed by ChatGPT™. FIG. 7 illustrates an example output of the serial program of FIG. 6, including the outputs of the ChatGPT™ parallel program and the output of a serial program parallelized by automatic parallelization of the GCC compiler (GNU compiler collection). FIG. 8 is a block diagram representative of the code compiler circuitry that may be implemented in the example environment of FIG. 5. FIG. 9 is a flow diagram representing example machine readable instructions and / or example operations that may be executed, instantiated, and / or performed by example programmable circuitry to implement the example code compiler circuitry of FIG. 8. FIG. 10 is a flowchart representing example machine readable instructions and / or example operations that may be executed, instantiated, and / or performed by example programmable circuitry to implement the example code compiler circuitry of FIG. 8 to perform training using identified code representation(s). FIG. 11 is a flow diagram representing example machine readable instructions and / or example operations that may be executed, instantiated, and / or performed by example programmable circuitry to implement the example code compiler circuitry of FIG. 8 to search database assignments using input code. FIG. 12 is a block diagram of an example processing platform including programmable circuitry structured to execute, instantiate, and / or perform the example machine readable instructions and / or perform the example operations of FIGS. 9-11 to implement the code compiler circuitry of FIG. 8. FIG. 13 is a block diagram of an example implementation of the programmable circuitry of FIG. 12. FIG. 14 is a block diagram of another example implementation of the programmable circuitry of FIG. 12. FIG. 15 is a block diagram of an example software / firmware / instruction distribution platform (e.g., one or more servers) for distributing software, instructions, and / or firmware (e.g., corresponding to the example machine readable instructions of FIGS. 9-11 ) to client devices associated with end users and / or consumers (e.g., for licenseing, sale, and / or use), retailers (e.g., for sale, resale, license, and / or underlization), and / or original equipment manufacturers (OEMs) (e.g., for inclusion in products, which are to be distributed, for example, to retailers and / or to other end users such as direct customers).Generally, the same reference numerals are used throughout the drawing(s) and the accompanying written description to refer to the same or similar parts. The figures are not to scale. Unless specifically stated otherwise, descriptors such as "first," "second," "third," etc. are used herein without implying or otherwise indicating any meaning of priority, physical order, arrangement in a list and / or order in any way, but are used merely as labels and / or arbitrary names to distinguish elements for ease of understanding of the disclosed examples. In some examples, the descriptor "first" may be used to refer to an element in the detailed description, while the same element in a claim may be referred to with a different descriptor, such as "second" or "third.". In such cases, it will be appreciated that such descriptors are used merely to uniquely identify those elements that might otherwise share a same name, for example.As used herein, the term "in communication," including variations thereof, encompasses direct communication and / or indirect communication via one or more intermediary components and does not require direct physical (e.g., wired) communication and / or constant communication, but instead additionally includes targeted communication at periodic intervals, scheduled intervals, aperiodic intervals, and / or one-time events.As used herein, "programmable circuitry" is defined to include (i) one or more special purpose electrical circuits (e.g., an application specific circuit (ASIC)) structured to perform one or more specific operations and one or more semiconductor-based logic devices (e.g., electrical hardware implemented by one or more transistors), and / or (ii) one or more general purpose semiconductor-based electrical circuits programmable with instructions to perform specific function(s) and / or operation(s) and including one or more semiconductor-based logic devices (e.g., electrical hardware implemented by one or more transistors). Examples of programmable circuitry include programmable microprocessors such as central processing units (CPUs) that can execute first instructions to perform one or more operations and / or functions, field programmable gate arrays (FPGAs) that can be programmed with second instructions to effect configurations and / or structuring of the FPGAs to instantiate one or more operations and / or functions corresponding to the first instructions, graphics processing units (GPUs) that can execute first instructions to perform one or more operations and / or functions, digital signal processors (DSPs) that can execute first instructions to perform one or more operations and / or functions, XPUs,Network Processing Units (NPUs), one or more microcontrollers capable of executing first instructions to perform one or more operations and / or functions, and / or integrated circuits such as application specific integrated circuits (ASICs). For example, an XPU may be implemented by a heterogeneous computer system that includes multiple types of programmable circuitry (e.g., one or more FPGAs, one or more CPUs, one or more GPUs, one or more NPUs, one or more DSPs, etc., and / or a combination thereof) and orchestration technology (e.g., application programming interfaces (APIs)) that may distribute computing tasks to each of the various types of programmable circuitry that are suitable and available for executing the computing tasks.Integrated circuits / circuitry is defined herein as one or more semiconductor packages that include one or more circuit elements such as transistors, capacitors, inductors, resistors, current paths, diodes, etc. An integrated circuit may be implemented, for example, as an ASIC and / or FPGA and / or chip and / or microchip and / or programmable circuit arrangement and / or semiconductor substrate having a plurality of circuit elements and / or a system-on-chip (SoC), etc.DETAILED DESCRIPTIONLarge code language models (LLM) such as OpenAI Codex™ or ChatGPT™ represent depth learning algorithms that can be used to recognize, gather, predict, and / or generate content using large sets of data. The use of LLM enables artificial intelligence (AI)-based models to generate human-like content. Starting from relatively simpler problems in predicting a subsequent program token (e.g., code completion), code LLMs are used to solve more complex problems such as code generation and code translation. These code LLMs are provided as programming assistance technologies via plugins for common code editors (e.g. Visual Studio Code). However, while code LLMs can solve simpler programming problems than code completion, code LLMs do not solve complex programming problems that require program inference functions. Compilers, on the other hand, have functions for program inference, but cannot analyze incomplete programs (i.e., programs that cannot be compiled). Alternatively, code LLMs (e.g., GitHub CoPilot) may process incomplete programs (e.g., as plug-in for code editors). In the methods and apparatuses described herein, the programming capabilities of code LLM may be improved by use in combination with a compiler, such that code LLM may solve complex programming problems when provided in code editors (e.g., as plug-in).Natural language LLMs do not have logical and mathematical inference capabilities. Known approaches based on improved prompt engineering have attempted to introduce such inference abilities. Such approaches include chain of thought (chain of ideas) and least to most or LtM style prompt, where CoT style provides multiple inference intermediates for an LLM in addition to the original prompt. The LtM prompt proceeds one step further than the CoT prompt by dividing the problem into sub-problems and providing an LLM with responses to these sub-problems. This helps an LLM to break the problems into sub-problems and solve these sub-problems. Most initial code LLM borrowed from LLM from natural languages represented primarily programs as sequences of tokens for input to underlying AI models. Because programs have a particular structure, several current code LLMs (e.g., PolyCode, CodeT5+, etc.) have proposed using various typical program representations (e.g., abstract syntax tree (AST) and control flow graph (CFG)) along with and / or in place of a sequence of tokens. These program representations improve upon using a sequence of token representations by capturing some underlying program characteristics (e.g., dataflow information, control flow information, etc.).However, Prompt Engineering techniques for improving natural language inference capabilities of LLM are based on manual approaches. Also, it remains unclear how simply prompt engineering techniques can be scaled for various types of code LLM issues. Thus, code parallelization problems are based on loop-based dependency information that must first be extracted for a particular input program. Therefore, LLM must first extract this information before processing the information for inference, which is conceptually associated with the invention, which compilers can best. Moreover, existing code LLMs using compiler-based program representations cannot make conclusions about programs because program representations represent only one component of the inference process. However, the inference process also includes program analysis passes that include compilers, but existing code LLMs are not trained to perform such program analyses.The methods and apparatus described herein combine code LLM with compilers. In the examples described herein, program inference capabilities are added to the code LLM. Compilers may for example already formally infer different program properties by using, among other things, different program representations such as AST, CFG and dataflow graph (DFG). Unlike code LLMs, compilers cannot infer incomplete programs because such programs cannot be parsed and therefore these code representations cannot be generated for incomplete programs. Accordingly, compilers cannot be provided in code editors if the code under development is not compilable. In the examples described herein, merging LLMs with compilers takes advantage of the strengths of the individual ones and simultaneously eliminates the existing weaknesses. Moreover, methods and apparatus disclosed herein may be provided as part of a software program or as a stand-alone software as-a-service (e.g., optimization as-a-service) model to support designers with complex problems. For example, software designers do not know how to achieve the best performance from certain hardware (e.g., Xeon CPUs), but engineers can optimize software to achieve significant performance improvements. Existing code LLMs cannot help in such cases because code optimization is a complex problem (where code parallelization is a sub-problem) that requires program inference capabilities. The methods and apparatus described herein enable code LLMs to solve complex programming problems and improve general programming efficiency.FIG. 1 illustrates example components 100 of a compiler including various program representations. Compilers perform the inference using various program representations, including abstract syntax tree (AST), control flow graph (CFG), and / or dataflow graph (DFG). The program representations enable different passes for concluding different program properties. Various program representations include various types of program information used by compiler-based analysis / transformation passes. Thus, a specific program representation in conjunction with a particular analysis run allows compilers to infer programs. For example, optimization passes such as dead code elimination (DCE) are based on control flow graphs (CFG) and dataflow graphs (DFG) to determine whether an assignment instruction is reachable. For example, the reachability analysis is based on control flow information collected in a CFG. In the context of code parallelization, the loop-carried dependency is the key information that allows the parallelization pass (e.g., LoopAccessAnal pass from LLVM) to decide whether a loop can be parallelized.In the example of FIG. 1, an input program 105 is passed to lexical analysis 110, which represents the first phase of a compiler that converts high-level inputs into a sequence of tokens 115, where a lexical token is a sequence of characters that can be treated as a unit in the grammar of a programming language. Tokens may include type tokens, bookmark tokens and / or alphabetical tokens. The output from the sequence of tokens 115 may be sent to an example parser to perform parsing 120. In the example of FIG. 1, parsing is performed with abstract parse trees (AST) 125 representing the structure of the program code. The AST serves as a representation of the abstract syntactic structure of text (e.g., source code) written in formal language such that each node of the tree identifies a construct that appears in the text. AST is passed to example semantic analysis 130, which determines whether a particular program is semantically consistent with a language definition using the syntax tree and a symbol table. An example of a control flow graph (CFG) and / or a dataflow graph (DFG) 135 is generated in which the dataflow accounts for the source, destination, and / or data transformations. For example, the CFG is a representation of all paths that may be traversed during execution of a program, while the DFG is a representation of the data flow through a program (e.g., identification of variables that include values at various locations in the program, etc.). Outputs of the CFG and DFG based analyses are used for example code generation and optimization 140, resulting in an example binary output 145.Unlike code completion, complex programming tasks require a more complicated approach. For example, code parallelization requires correct program inference based on loop-carried dependency information. Current techniques such as a GPT-3.5 model (e.g., via ChatGPT™) may be tried for parallelization of a simple for-loop in the C programming language. However, while a program such as ChatGPT™ can correctly analyze simpler cases and respond to whether or not the loop can be parallelized, more complicated cases result in false responses. For example, if ChatGPT™ presents the following code, it correctly responds that the loop cannot be parallelized:.. int a

[10] ;The reason why the above loop cannot be parallelized is that it has a backward loop-carried dependence, so that a current iteration of the loop depends on the previous iteration. However, when ChatGPT™ presents the code shown below and asks whether the code can be parallelized, it provides a false response (e.g., a false parallelized version of a loop as shown in more detail in FIGS. 6 and 7):.. int a

[10] ;In particular, the above example is more complicated because although the program has a loop-carried dependency (e.g., the same reason that the first loop cannot be parallelized at the top), the distance of the loop dependency is 2 in the second example (e.g., a[i]=a[i+2]) and therefore the loop can be parallelized. A parallelized version of ChatGPT™ (e.g., as in connection with FIGS. 6-7 ) is incorrect (e.g., correct parallelization analyzes that the successive elements a[i] and a[i+1] may be processed in parallel), as described in more detail in connection with FIG. 6. Therefore, existing code LLMs cannot infer programs and are unsuccessful when presented with complex programming tasks. For example, there are currently no known code LLMs that can conduct program conclusions using compilers to solve complex programming problems. In the examples described herein, activation of code LLM to perform program inferences may be based on the observation that compilers already have these capabilities and may build code LLMs on these capabilities of compilers.As a rule, code LLMs do not have programming inference capabilities, since code LLMs are not specifically designed to infer programs. Instead, code LLMs are trained on pairs of input programs, output programs, and / or labels and are prompted to learn the mapping function that generates the output program and / or label for a particular input program (e.g., code translation problem output program, code classification problem label, etc.). Therefore, code LLMs are requested to learn the corresponding program representations along with the corresponding code analyses to solve a particular programming problem. Most code LLMs typically represent input programs as a sequence of tokens. In some examples, LLMs use basic program representations such as the abstract syntax tree (e.g., AST) as shown in connection with FIG. 1. However, these basic representations are not sufficient to perform complex program analysis. Complex analysis passes occur later in the compilation process, for example, and are out of range of the current LLM. However, LLMs also have inherent advantages, such as functioning as plugins in code editors (e.g., Visual Studio Code) as programmer assistance technologies. In such scenarios, the code is typically under development and is not compilable. As a result, complex compiler passes (e.g., a LoopTime analysis pass) are not feasible in such examples. However, LLMs can operate with such non-compilable code and improve productivity of the programmers through support. In the examples described herein, program inference capabilities are added to code LLM so that code LLM can infer programs by combining existing compiler and LLM strengths. In the examples provided herein, LLM generate program representations required by the compiler from incomplete programs and take advantage of the strength of the code LLM in handling incomplete programs. Also, existing compiler program inference capabilities may be utilized by applying compilers to the program representations, with the existing compiler strengths utilized in program analysis.FIG. 2 illustrates an example provision 200 of a code LLM as a code editor plug-in. In the example of FIG. 2, a code LLM with program inference capabilities is provided as a plugin to a code editor 205. For example, if a programmer 210 writes code, the plugin may query 215 whether the code can be vectorized. The code LLM program representation generator 225 then processes the non-compilable code to generate its representation and transmit the representation to a compiler 230 to perform analysis passes on this representation and answer the given question (e.g., "can the code be vectored?"). The specific program representation generated by the generator may vary as needed. For example, in a code vectoring question, the representation would be a dataflow graph (DFG), while in a code parallelization question, the representation would be loop-based dependency information. Thus, an example set of possible program representations 220 is open upward in FIG. 2. The generated program representations are transmitted to compiler 230 for the compilation process, as shown in connection with FIG. 1.FIG. 3 illustrates an example database with associations 300 between an input program and a corresponding relevant program representation (e.g., abstract syntax tree (AST)). In the example of FIG. 3, a database of code repositories 305 is used to generate input programs 310 that are compiled with the compiler 315, where the input programs (P) 310 and their corresponding ASTs (e.g., program representations A) are stored in a database (D) 320. As described in connection with FIG. 2, the program representation generator 225 generates a program representation for non-compilable code. In the example of FIG. 3, AST is used as the program representation to be generated by the program representation generator 225. However, the methods and apparatus described herein may be applied to all representations used by compilers (e.g., CFG, DFG, loop-based dependencies, etc.).Although in the example of FIG. 3, the database assignments represent the use of an AST as the program representation of interest, any other type of program representation may be generated. The program representation generator 225 focuses on (1) compiling the database with assignments between input source code / programs and their corresponding relevant program representation, (2) storing the assignment between individual source code elements and their sub-representations in the program representation of interest, and (3) searching the database using the input code sections to obtain the program representation of interest. Compilation and storage are part of the phase before provisioning, while browsing is part of the actual provisioning phase. The goal of compilation is to build a database of programs written in a higher level language and corresponding program representations of interest. The database (D) 320 may contain, for example, assignments between the input program (P) and ASTs (A). Example: The database is the set of pairs of P, A, where P stands for an input program and A stands for the program representation (i.e., input {(P, A)}). A list of programs from open source and / or closed source sources may be compiled and compiled with a standard compiler (e.g., compiler 315), as shown in connection with FIG. 3. For example, standard compilers offer options for removing all intermediate representations.FIG. 4 illustrates example associations 400 between various program elements and their program representations using an abstract syntax tree (AST). In the example of FIG. 4, the storage of the association between individual source code elements (P) and their sub-trees (A) in the program AST is shown. FIG. 4 includes program elements 405 and their sub-trees in an AST 410, where the dotted lines indicate assignments. A source code element (P) represents various portions of a program (e.g., functions, loops, instructions, variables, etc.). This aspect is required because the actual input to an LLM is typically not a full program, but rather the input is in sections of a full program (e.g., a for-loop). A preferred approach to retrieving the mapping information is to use debugging information generated by the compiler in FIG. 3. Debugging information includes the mapping between positions in the input program and the corresponding program representations (e.g., dotted lines in FIG. 4 ). The mapping between elements of P and their sub-trees in A is stored in database D. In addition to the mapping between the actual strings for elements of P and their sub-trees in A, canonical versions of these elements are stored along with their sub-trees in A. For example, cannulated versions allow for a more comprehensive search when database D is searched using input code sections to obtain ASTs (e.g., in cases where the exact search is not successful).FIG. 5 illustrates an example provisioning phase 500 with an end-to-end scenario of a search over database D, including example code evaluator circuitry 502. For example, FIG. 5 shows an example of searching in database D 320 with an input code clip to obtain an AST. As shown in connection with FIG. 4, creating database D 320 concludes the phase prior to provisioning. During actual provisioning, code evaluator circuitry 502 uses database D 320 for search queries. For example, if an input code clip is provided to an LLM (e.g., from code editor 505), the LLM passes that clip to the code LLM with program representation generator 225 to generate ASTs as program representations. Code evaluator circuitry 502 uses generator 225 to search for the clip in D and, if found, returns its subtree following the mapping generated in connection with Figure 4. As described above, the actual input to an LLM is typically not a complete program, but rather is input in sections of a complete program (e.g., a for-loop 510). If exact clip matching fails, code evaluator circuitry 502 may subscribe to the clip by extracting additional details (e.g., variable names, constants, etc.). The returned subtree of an AST is then sent to compiler 230 to perform its analysis passes in the subtree. Although such sub-trees may not represent complete ASTs of a program, conservative analysis passes with compiler integrity guarantees may handle the analysis of such sub-trees. For example, for the input program shown in connection with FIG. 5, the output of compiler 230 may be: "The code may be parallelized if a and b are different arrays (without aliases), but it may not be parallelized if a and b have aliases." Since the code in connection with FIG. 5 is not complete, compiler 230 does not have enough information about a and b to suggest a specific result, but compilers are known to perform such conservative analyses.FIG. 6 shows example code 600 of a serial program 605 and a parallel version 610 of the serial program proposed by ChatGPT™. In the example of FIG. 6, serial program 605 and parallel version 610 were compiled using a standard compiler (e.g., GCC (GNU compiler collection), and the outputs were checked, showing that the output of parallel version 610 proposed by ChatGPT™ was incorrect while the output of serial program 605 was correct.FIG. 7 illustrates an example code output 705 related to the serial program 605 in FIG. 6, including an example output 710 associated with a parallel program of ChatGPT™ and an example output 715 of a serial program parallelized by automatic parallelization of the GCC compiler (GNU compiler collection). As a formal comparison based on program analyses, the automatic parallelization run of GCC was used to generate a parallel version of the serial program 605 where the output of the parallelized GCC version was found to be correct. Thus, the methods and apparatus described herein allow the combination of compiler-based methods with LLM to add program inference capabilities to code LLM.FIG. 8 is a block diagram of an example implementation of the code evaluator circuitry 502 of FIG. 5. the code evaluator circuitry 502 of FIG. 5 may be instantiated (e.g., an instance may be created, alive, materialized, implemented, etc.) by programmable circuitry such as a central processing unit (CPU) executing first instructions. Additionally or alternatively, the code evaluator circuitry 502 of FIG. 5 may be instantiated (e.g., an instance may be generated, alive, materialized, implemented, etc.) by (i) an application specific integrated circuit (ASIC), and / or (ii) a field programmable gate array (FPGA) structured in response to execution of second instructions and / or configured to perform operations corresponding to the first instructions. It is understood that a portion or the entirety of the circuit arrangement of FIG. 8 may thus be instantiated at the same or different times. For example, some or all of the circuitry of FIG. 8 may be instantiated in one or more threads executing concurrently on hardware and / or in series on hardware. Moreover, in some examples, a portion or all of the circuitry of FIG. 8 may be implemented by microprocessor circuitry executing instructions and / or FPGA circuitry performing operations to implement one or more virtual machines and / or containers.In the example of FIG. 8, code evaluator circuitry 502 in FIG. 5 includes example code representation identifier circuitry 810, example code allocation circuitry 815, example database generator circuitry 820, example code fetch circuitry 825, example search initiator circuitry 830, example status identifier circuitry 835, and / or example data storage 840. In the example of FIG. 8, code representation identifier circuitry 810, code allocation circuitry 815, database generator circuitry 820, code fetch circuitry 825, search initiator circuitry 830, status identifier circuitry 835, and / or data storage 840 are in communication with each other via an example bus 845.Code representation identifier circuitry 810 receives non-compilable code and identifies the type of compiler-based code representation to be generated as part of identifying a representation of the non-compilable code. For example, the specific program representation may vary depending on a programmer's question (e.g., the code is parallelizable, vectorizable, etc.). In code vectoring, code representation identifier circuitry 810 identifies the representation as a dataflow graph (DFG). In code parallelization, code representation identifier circuitry 810 identifies the representation as a loop-carried dependency representation. Thus, code representation identifier circuitry 810 identifies any type of representation suitable for a particular code representation task (e.g., abstract syntax tree (AST), control flow graph (CFG), data flow graph (DFG), etc.).Code assignment circuitry 815 learns an assignment relationship between individual source code elements and their representations. In some examples, code assignment circuitry 815 generates the code representation based on the type of code representation identified by code representation identifier circuitry 810 (e.g., AST, CFG, DFG, etc.). In the examples described herein, code allocation circuitry 815 compiles the database of associations between input source code / programs and their ASTs. In some examples, code allocation circuitry 815 uses debugging information to obtain the allocation(s). Debugging information includes the mapping between positions in the input program and the corresponding program representations shown in connection with FIG. 4. In some examples, code allocation circuitry 815 generates cannulated versions of program elements for use by search initiator circuitry 830 when database D is searched using input code sections retrieved by code retrieval circuitry 825.Database generator circuitry 820 generates a database with assignments between programs and corresponding relevant program representations (e.g., AST, CFG, DFG, etc.). Database generator circuitry 820 stores input programs (P) and their corresponding program representations (e.g., program representations A) in a database (D) as described in connection with FIG. 3. As such, the database contains the set of pairs of P, A, where P stands for an input program and A stands for the program representation (i.e., input {(P, A)}). In the examples described herein, database generator circuitry 820 stores the mapping between individual source code elements and their sub-trees in the program AST. In some examples, database generator circuitry 820 stores canonical versions of these elements along with their sub-trees in A.Code fetch circuitry 825 fetches input code slices. For example, the actual input to an LLM is typically not a complete program, but rather the input is performed in sections of a complete program (e.g., a for-loop). As such, code fetch circuitry 825 identifies the input code clip to enable generation of a corresponding program representation based on the input code clip. Searches for the patch in database D are started with search initiator circuitry 830.Search initiator circuitry 830 searches the database of assignments using input code clippings to obtain the input code clipping representations (e.g., ASTs). In some examples, search initiator circuitry 830 enters code sections into the database of assignments compiled with database generator circuitry 820. Search initiator circuitry 830 determines whether the input code clip can be identified from the database of assignments. In some examples, search initiator circuitry 830 uses a subscribed version of code elements and their representations when a first search does not result in an identification with the database of assignments. Once search initiator circuitry 830 identifies the code section in database D, search initiator circuitry 830 outputs the corresponding program representation (e.g., AST-based subtree) based on the assignments generated by code assignment circuitry 815.The state identifier circuitry 835 performs the evaluation passes, passes the identified code representation, and / or determines a code state and / or attribute (e.g., code may be vectored, parallelized, etc.). For example, the status identifier circuitry 835 performs the analysis on the AST-based sub-trees, as described in connection with FIG. 5. For example, the status identifier circuitry 835 makes a determination such as "The code may be parallelized if a and b are different arrays (without aliases), but it may not be parallelized if a and b have aliases." However, any other type of determination may be made, including as to whether the code may be vectorized and / or parallelized.Data storage 840 may be used to store all information associated with code representation identifier circuitry 810, code allocation circuitry 815, database generator circuitry 820, code fetch circuitry 825, search initiator circuitry 830, and / or status identifier circuitry 835. The example data storage 840 of the illustrated example in FIG. 8 may be implemented by any memory, storage device, and / or storage medium for storing data, such as flash memory, magnetic media, optical media, etc. Moreover, the data stored in the example data storage 840 may be in any data format, such as binary data, comma separated data, tab separated data, structured query language (SQL) structures, image data, etc.In some examples, the apparatus includes means for identifying a code representation. For example, the means for identifying a code representation may be implemented by the code representation identifier circuitry 810. In some examples, code representation identifier circuitry 810 may be instantiated by programmable circuitry such as the example programmable circuitry 1212 of FIG. 12. For example, code representation identifier circuitry 810 may be implemented by the example microprocessor 1300 of FIG. 13 executing machine executable instructions as implemented at least in block 915 of FIG. 9. In some examples, code representation identifier circuitry 810 may be instantiated by hardware logic circuitry implemented by an ASIC, XPU, or FPGA circuitry 1400 of FIG. 14 structured to perform operations corresponding to the machine readable instructions. Additionally or alternatively, code representation identifier circuitry 810 may be instantiated by any other combination of hardware, software, and / or firmware. For example, code representation identifier circuitry 810 may be implemented by at least one or more hardware circuits (e.g., processor circuitry, discrete and / or integrated analog and / or digital circuitry, an FPGA, an ASIC, an XPU, a comparator, an operational amplifier (op-amp), a logic circuit, etc.) structured to execute some or all machine readable instructions and / or perform some or all of the operations corresponding to the machine readable instructions without execution of software or firmware, but other structures are also suitable.In some examples, the apparatus includes means for allocating code. The means for allocating code may be implemented, for example, by code allocation circuitry 815. In some examples, code allocation circuitry 815 may be instantiated by programmable circuitry, such as programmable circuitry 1212 in FIG. 12. In some examples, code allocation circuitry 815 may be instantiated by hardware logic circuitry implemented by an ASIC, XPU, or FPGA circuitry 1400 of FIG. 14 structured to perform operations corresponding to the machine readable instructions. Additionally or alternatively, code allocation circuitry 815 may be instantiated by any other combination of hardware, software, and / or firmware. For example, code allocation circuitry 815 may be implemented by at least one or more hardware circuits (e.g., processor circuitry, discrete and / or integrated analog and / or digital circuitry, an FPGA, an ASIC, an XPU, a comparator, an operational amplifier (op-amp), logic circuitry, etc.) structured to execute some or all machine readable instructions and / or perform some or all of the operations corresponding to the machine readable instructions without execution of software or firmware, but other structures are also suitable.In some examples, the apparatus includes means for generating a database. For example, the means for generating a database may be implemented by the database generator circuitry 820. In some examples, database generator circuitry 820 may be instantiated by programmable circuitry, such as programmable circuitry 1212 in FIG. 12. In some examples, database generator circuitry 820 may be instantiated by hardware logic circuitry implemented by an ASIC, XPU, or FPGA circuitry 1400 of FIG. 14 structured to perform operations corresponding to the machine readable instructions. Additionally or alternatively, database generator circuitry 820 may be instantiated by any other combination of hardware, software, and / or firmware. For example, the database generator circuitry 820 may be implemented by at least one or more hardware circuits (e.g., processor circuitry, discrete and / or integrated analog and / or digital circuitry, an FPGA, an ASIC, an XPU, a comparator, an operational amplifier (op-amp), a logic circuit, etc.) structured to execute some or all machine readable instructions and / or perform some or all of the operations corresponding to the machine readable instructions without execution of software or firmware, but other structures are also suitable.In some examples, the apparatus includes means for retrieving code. The means for retrieving code may be implemented, for example, by the code retrieval circuitry 825. In some examples, code fetch circuitry 825 may be instantiated by programmable circuitry, such as programmable circuitry 1212 in FIG. 12. In some examples, code fetch circuitry 825 may be instantiated by hardware logic circuitry implemented by an ASIC, XPU, or FPGA circuitry 1400 of FIG. 14 structured to perform operations corresponding to the machine readable instructions. Additionally or alternatively, code fetch circuitry 825 may be instantiated by any other combination of hardware, software, and / or firmware. For example, code fetch circuitry 825 may be implemented by at least one or more hardware circuits (e.g., processor circuitry, discrete and / or integrated analog and / or digital circuitry, an FPGA, an ASIC, an XPU, a comparator, an operational amplifier (op-amp), a logic circuit, etc.) structured to execute some or all machine readable instructions and / or perform some or all of the operations corresponding to the machine readable instructions without execution of software or firmware, but other structures are also suitable.In some examples, the apparatus includes means for initiating a search. The means for initiating a search may be implemented, for example, by the search initiator circuitry 830. In some examples, search initiator circuitry 830 may be instantiated by programmable circuitry, such as programmable circuitry 1212 in FIG. 12. In some examples, search initiator circuitry 830 may be instantiated by hardware logic circuitry implemented by an ASIC, XPU, or FPGA circuitry 1400 of FIG. 14 structured to perform operations corresponding to the machine readable instructions. Additionally or alternatively, search initiator circuitry 830 may be instantiated by any other combination of hardware, software, and / or firmware. For example, the search initiator circuitry 830 may be implemented by at least one or more hardware circuits (e.g., processor circuitry, discrete and / or integrated analog and / or digital circuitry, an FPGA, an ASIC, an XPU, a comparator, an operational amplifier (op-amp), a logic circuit, etc.) structured to execute some or all machine readable instructions and / or perform some or all of the operations corresponding to the machine readable instructions without execution of software or firmware, but other structures are also suitable.For example, the means for identifying a status may be implemented by the status identifier circuitry 835. In some examples, the status identifier circuitry 835 may be instantiated by programmable circuitry, such as the programmable circuitry 1212 of FIG. 12. In some examples, the status identifier circuitry 835 may be instantiated by hardware logic circuitry implemented by an ASIC, XPU, or the FPGA circuitry 1400 of FIG. 14 structured to perform operations corresponding to the machine readable instructions. Additionally or alternatively, the status identifier circuitry 835 may be instantiated by any other combination of hardware, software, and / or firmware. For example, the status identifier circuitry 835 may be implemented by at least one or more hardware circuits (e.g., processor circuitry, discrete and / or integrated analog and / or digital circuitry, an FPGA, an ASIC, an XPU, a comparator, an operational amplifier (op-amp), a logic circuit, etc.) structured to execute some or all machine readable instructions and / or perform some or all of the operations corresponding to the machine readable instructions without execution of software or firmware, but other structures are also suitable.While an example manner of implementing the code evaluator circuitry 502 is illustrated in FIG. 8, one or more of the elements, processes, and / or devices illustrated in FIG. 8 may be combined, shared, rearranged, omitted, eliminated, and / or implemented in any other manner. Further, the example code representation identifier circuitry 810, the example code allocation circuitry 815, the example database generator circuitry 820, the example code fetch circuitry 825, the example search initiator circuitry 830, the example status identifier circuitry 835, and / or, more generally, the example code evaluator circuitry 502 of FIG. 8 may be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. For example, any of the example code representation identifier circuitry 810, the example code assignment circuitry 815, the example database generator circuitry 820, the example code fetch circuitry 825, the example search initiator circuitry 830, the example status identifier circuitry 835, and / or, more generally, the example code evaluator circuitry 502 of FIG. 8 may be modified by programmable circuitry in combination with machine readable instructions (e.g., firmware or software), processor circuitry, analog circuitry, digital circuitry, logic circuitry, programmable processors, programmable microcontrollers, graphics processors (GPU(s)), digital signal processors (DSP(s), ASIC(s)), The invention can therefore be implemented using programmable logic modules (PLD(s)) and / or field programmable logic modules (FPLD(s)) such as FPGAs. Moreover, the example code evaluator circuitry 502 of FIG. 8 may include one or more elements, processes, and / or devices in addition to or in place of those illustrated in FIG. 8, and / or may include more than one or all of the illustrated elements, processes, and devices.Flowcharts representative of example machine readable instructions executable by programmable circuitry to implement and / or instantiate code evaluator circuitry 502 of FIG. 8, and / or representative of example operations executable by programmable circuitry to implement and / or instantiate code evaluator circuitry 502 of FIG. 8, are shown in FIGS. 9-11. The machine readable instructions may be one or more executable programs or one or more portions of one or more executable programs for execution by programmable circuitry, such as programmable circuitry 1212 shown in example processor platform 1200 discussed below in connection with FIG. 12, and / or may be one or more functions or portions of functions to be performed by example programmable circuitry (e.g., an FPGA) discussed below in connection with FIGS. 13 and / or 14. In some examples, the machine readable instructions cause an operation, task, etc. in the real world to be automatically performed and / or performed. As used herein, "automated" means without human involvement.The program may be embodied in instructions (e.g., software and / or firmware) stored on one or more non-transitory computer readable and / or machine readable storage media, such as a cache memory, a magnetic storage device or disk (e.g., a floppy disk, a hard disk drive (HDD), etc.), an optical storage device or disk (e.g., a Blu-ray disk, a compact disk (CD), a digital versatile disk (DVD), etc.), a redundant array of independent disks (RAID), a register, a ROM, a solid state drive (SSD), an SSD memory, a non-volatile memory (e.g., an electrically erasable programmable read only memory (EEPROM), a flash memory, etc.), a volatile memory (e.g., random access memory (RAM) of any type, etc.), and / or any other storage device or storage disk. The instructions of the non-transitory, computer readable, and / or machine readable medium may be programmed and / or executed by programmable circuitry residing in one or more hardware devices, but the entire program and / or portions thereof could alternatively be executed and / or instantiated by one or more hardware devices that are not associated with the programmable circuitry and / or embodied in dedicated hardware. The machine readable instructions may be distributed among multiple hardware devices and / or executed by two or more hardware devices (e.g., a server and a client hardware device). For example, the client hardware device may be implemented by an endpoint client hardware device (e.g., a hardware device associated with a human and / or machine user) or an inter-client hardware device gateway (e.g., a radio access network (RAN)) that may facilitate communication between a server and an endpoint client hardware device. Similarly, the non-transitory computer readable storage medium may include one or more media. Although the example program is further described with reference to the flowcharts illustrated in FIGS. 9-11, many other methods of implementing the example code evaluator circuitry 502 of FIG. 8 may alternatively be used. For example, the order of execution of the blocks of the flowcharts may be changed, and / or some of the described blocks may be changed, removed, or combined. Additionally or alternatively, some or all of the blocks of the flowchart may be implemented by one or more hardware circuitry (e.g., processor circuitry, discrete and / or integrated analog and / or digital circuitry, an FPGA, an ASIC, a comparator, an operational amplifier (op-amp), or logic circuitry, etc.) structured to perform the corresponding operation without executing software or firmware. The programmable circuitry may be distributed to various network locations and / or locally reside on one or more hardware devices (e.g., a single core processor (e.g., a single core CPU), a multi-core processor (e.g., a multi-core CPU, an XPU, etc.)). The programmable circuitry may be, for example, a CPU and / or an FPGA located in the same package (e.g., in the same integrated circuit (IC) package or in two or more separate packages), one or more processors in a single machine, multiple processors distributed across multiple servers of a server chassis, multiple processors distributed across one or more server chassis, etc., and / or any combination thereof.The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine-readable instructions as described herein may be stored as data (e.g., computer-readable data, machine-readable data, one or more bits (e.g., one or more computer-readable bits, one or more machine-readable bits, etc.), a bitstream (e.g., a computer-readable bitstream, a machine-readable bitstream, etc.), or a data structure (e.g., as part(s) of instructions, code, representations of code, etc.) that may be used to generate, produce, and / or produce machine-executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices, hard drives, and / or computing devices (e.g., servers) located at the same or different locations of a network or collection of networks (e.g., in the cloud, edge devices, etc.). The machine readable instructions may require one or more of the following operations: installation, modification, adjustment, updating, combining, complementing, configuring, decryption, decompression, unpacking, distribution, reallocation, compilation, etc., to render them directly readable, interpretable, and / or executable by a computing device and / or other machine. For example, the machine-readable instructions may be stored in multiple portions that are individually compressed, encrypted, and / or stored on separate computing devices, where the portions, when decrypted, decompressed, and / or combined, form a set of computer-executable and / or machine-executable instructions that implement one or more functions and / or operations that together may form a program such as that described herein.In another example, the machine readable instructions may be stored in a state where they may be read by programmable circuitry, but require addition to a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc., to execute the machine readable instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., storing settings, input of data, recording network addresses, etc.) before the machine readable instructions and / or the one or more corresponding programs may be executed in whole or in part. Thus, machine-readable, computer-readable or machine-readable media as used herein may include instructions and / or program(s) regardless of the particular format or state of the machine-readable instructions and / or program(s).The machine readable instructions described herein may be represented by any previous, current, or future instruction language, scripting language, programming language, etc. For example, the machine readable instructions may be represented using any of the following languages: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc.As mentioned above, the example operations of FIGS. 3-4 may be implemented using executable instructions (e.g., computer readable and / or machine readable instructions) stored on one or more non-transitory computer readable and / or machine readable media. As used herein, the terms non-transitory computer readable medium, non-transitory computer readable storage medium, non-transitory machine readable medium, and / or non-transitory machine readable storage medium are expressly defined to include any type of computer readable storage device and / or storage disk and to exclude propagating signals and to exclude transmission media. Examples of such a non-transitory computer readable medium, a non-transitory computer readable storage medium, a non-transitory machine readable medium, and / or a non-transitory machine readable storage medium are optical storage devices, magnetic storage devices, an HDD, a flash memory, a read only memory (ROM), a CD, a DVD, a cache, any type of RAM, a register, and / or any other storage device or storage disk in which information is stored for any duration (e.g., for extended periods of time, permanently, for short periods of time, for temporarily buffering, and / or for buffering the information). As used herein, the terms "non-transitory computer readable storage medium" and "non-transitory computer readable storage medium" are defined to include any physical (mechanical, magnetic, and / or electrical) hardware for storing information over a period of time, but to exclude propagating signals and transmission media. Examples of non-transitory computer readable storage devices and / or machine readable storage devices include random access memory (RAM) of any type, read only memory (ROM) of any type, solid state memory, flash memory, optical disks, magnetic disks, disk drives, and / or redundant array of independent disks (RAID) systems. As used herein, the term "device" refers to a tangible structure such as mechanical and / or electrical equipment, hardware, and / or circuitry that may or may not be configured by computer readable instructions, machine readable instructions, etc. and / or manufactured to execute computer readable instructions, machine readable instructions, etc."Including" and "comprising" (and all forms and time forms thereof) are used herein as open terms. Thus, whenever a claim employs any form of "include" or "comprise" (e.g., comprises, includes, comprising, including, having, etc.) as a preamble or within claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. When the term "at least" is used as the transitional term in, for example, a preamble of a claim, it is open in the same manner as the terms "comprising" and "including" are open as used herein. The term "and / or," when used in a form such as A, B, and / or C, for example, refers to any combination or subset of A, B, C, such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, or (7) A with B, and with C. As used herein in the context of describing structures, components, objects, and / or things, the term "at least one of A and B" is intended to refer to implementations including any of: (1) at least one A, (2) at least one B or (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, objects, and / or things, the term "at least one of A or B" is intended to refer to implementations comprising any of: (1) at least one A, (2) at least one B or (3) at least one A and at least one B. As used herein in the context of describing the execution or execution of processes, instructions, acts, and / or activities, the term "at least one of A and B" is intended to refer to implementations comprising any of: (1) at least one A, (2) at least one B or (3) at least one A and at least one B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, acts, and / or activities, the term "at least one of A or B" is intended to refer to implementations comprising any of: (1) at least one A, (2) at least one B, or (3) at least one A and at least one B.As used herein, references in the singular (e.g., "a", "an", "first / r / s", "second / r / s", etc.) do not include a plurality. The term "a" object, as used herein, refers to one or more of that object. The terms "a", "one or more", and "at least one" are used interchangeably herein. Moreover, a plurality of means, elements, or actions, even if individually listed, may be performed, for example, by the same entity or object. Additionally, although individual features may be included in different examples or claims, these may possibly be combined, and inclusion in different examples or claims does not mean that a combination of features is not feasible and / or advantageous.FIG. 9 is a flow diagram illustrating example machine readable instructions and / or example operations 900 that may be executed, instantiated, and / or performed by programmable circuitry for implementing the example code evaluator circuitry 502 of FIG. 8. The machine readable instructions and / or operations 900 of FIG. 9 begin at block 910, where the code representation identifier circuitry 810 receives non-compilable code. The code representation identifier circuitry 810 identifies, at block 915, the type of compiler-based code representation to be generated. In some examples, code representation identifier circuitry 810 determines whether to perform the code representation in the form of an abstract syntax tree (AST), a control flow graph (CFG), and / or a dataflow graph (DFG). For example, an AST is used to represent the abstract syntactic structure of text (e.g., source code) written in formal language so that each node of the tree identifies a construct that appears in the text. Separately, CFGs represent a representation of all paths that may be traversed during execution of a program, and DFGs represent a representation of the flow of data through a program. The code representation identifier circuitry 810 determines whether training of a neural network is required to obtain code representations at block 918. If training has not been performed, the code allocation circuitry 815 performs training at block 920, as described in more detail in connection with FIG. 10. For example, code assignment circuitry 815 generates assignments between the input source code and the corresponding program representations (e.g., ASTs). Based on the code representation(s) and the input code clip, the search initiator circuitry 830 searches a database of assignments using the input code clips to obtain the code representation (e.g., ASTs) in block 930. For example, search initiator circuitry 830 identifies returned code representations as described in connection with FIG. 11. Once the returned code representations have been identified, the status identifier circuitry 835 performs evaluation passes and passes the code representations at block 935. For example, at block 940, the search initiator circuitry 830 performs scoring passes on the identified code representation and determines a code status and / or attribute of the code. For example, search initiator circuitry 830 determines whether the input code can be vectorized and / or parallelized.FIG. 10 is a flowchart representing example machine readable instructions and / or example operations 1000 that may be executed, instantiated, and / or performed by programmable circuitry to implement code evaluator circuitry 502 of FIG. 8 to perform training using identified code representation(s). The machine readable instructions and / or operations 1000 of FIG. 10 begin at block 1003 when the code allocation circuitry 815 accesses the code representation at a compiler. The code allocation circuitry 815 compiles a database of associations between the input source code and the corresponding program representations (e.g., ASTs) at block 1005. The database generator circuitry 820 stores, in block 1010, the generated associations between individual source code elements and representations thereof. The program representations may include, for example, AST-based sub-trees. In some examples, in block 1015, database generator circuitry 820 also stores canonical versions of the code elements and their representations. For example, code assignment circuitry 815 generates cannulated versions of program elements for use by search initiator circuitry 830 when database D is searched using input code sections as described in connection with FIG. 11.FIG. 11 is a flow diagram representing example machine readable instructions and / or example operations 1100 executable, instantiated, and / or executable by programmable circuitry to implement the code evaluator circuitry 502 of FIG. 8 for searching for database assignments using input code sections in accordance with the teachings disclosed herein. The machine readable instructions and / or operations 1100 of FIG. 11 begin at block 1105 when the search initiator circuitry 830 enters code sections into the compiled database of the assignments. If search initiator circuitry 830 identifies the input code portion in the database of assignments in block 1110, search initiator circuitry 830 identifies the returned code representation in block 1120. If search initiator circuitry 830 does not identify the input code clip in the assignments database, at block 1110 search initiator circuitry 830 cannonizes the code clip by abstracting additional details (e.g., variable names, constants, etc.) at block 1115. Thus, in block 1120, the search initiator circuitry 830 may search the database of assignments using the subscribed version(s) of the input code clip to identify a returned code representation (e.g., AST subtree).FIG. 12 is a block diagram of an example programmable circuitry platform 1200 structured to execute and / or instantiate the example machine readable instructions and / or operations of FIGS. 9-11 to implement the example code evaluator circuitry 502 of FIG. 8. The programmable circuitry platform 1200 may be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a mobile phone, a smart phone, a tablet such as an iPadTM), a personal digital assistant (PDA), an Internet device, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a game console, a personal video recorder, a set-top box, a headset (e.g., an augmented reality (AR) headset, VR (virtual reality) headset, etc.), or other wearable device, or any other type of computing device and / or electronic device.The programmable circuitry platform 1200 of the illustrated example includes programmable circuitry 1212. The programmable circuitry 1212 of the illustrated example is hardware. The programmable circuitry 1212 may be implemented, for example, by one or more integrated circuits, logic circuits, FPGAs, microprocessors, CPUs, GPUs, DSPs, and / or microcontrollers of any desired family or manufacturer. The programmable circuitry 1212 may be implemented by one or more semiconductor-based (e.g., silicon-based) devices. In this example, processor circuitry 1212 implements code representation identifier circuitry 810, code assignment circuitry 815, database generator circuitry 820, code fetch circuitry 825, search initiator circuitry 830, and status identifier circuitry 835.The programmable circuitry 1212 of the illustrated example includes local memory 1213 (e.g., cache, registers, etc.). The programmable circuitry 1212 of the illustrated example is in communication with a main memory including volatile memory 1214 and nonvolatile memory 1216 through a bus 1218. The volatile memory 1214 may be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RDRAM® (RAMBUS® dynamic random access memory), and / or any other type of RAM device. The non-volatile memory 1216 may be implemented by flash memory and / or any other desired type of storage device. Access to main memory 1214, 1216 of the illustrated example is controlled by a memory controller 1217. In some examples, the memory controller 1217 may be implemented by one or more integrated circuits, logic circuits, microcontrollers of any desired family or manufacturer, or any other type of circuitry to manage the flow of data to and from the main memory 1214, 1216.The programmable circuitry platform 1200 of the illustrated example also includes interface circuitry 1220. The interface circuitry 1220 may be implemented by hardware according to any type of interface standard, such as an Ethernet interface, a universal serial bus (USB) interface, a Bluetooth® interface, a near field communication (NFC) interface, a peripheral component interconnect (PCI) interface, and / or a peripheral component interconnect express (PCIe) interface.In the illustrated example, one or more input devices 1222 are connected to interface circuitry 1220. The one or more input devices 1222 enable a user (e.g., a human user, a machine-embodied user, etc.) to input data and / or commands to the programmable circuitry 1212. The one or more input devices 1222 may be implemented, for example, by an audio sensor, a microphone, a camera (still or video), a keyboard, a key, a mouse, a touch screen, a track pad, a track ball, an isopoint device, and / or a voice recognition system.One or more output devices 1224 are also connected to the interface circuitry 1220 of the illustrated example. The output devices 1224 may be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube (CRT) display, an in-place switching (IPS) display, a touch-sensitive screen, etc.), a tactile output device, a printer, and / or speaker. The interface circuitry 1220 of the illustrated example thus typically includes a graphics driver card, a graphics driver chip, and / or graphics driver processor circuitry, such as a GPU.The interface circuitry 1220 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and / or a network interface to enable data exchange with external machines (e.g., computing devices of any type) over a network 1226. The communication may be through, for example, an Ethernet connection, a digital DSL connection, a telephone line connection, a coaxial cable system, a satellite system, a wireless line-of-sight system, a cellular telephone system, an optical connection, etc.The programmable circuitry platform 1200 of the illustrated example also includes one or more mass storage devices 1228 for storing software and / or data. Examples of such mass storage devices 1228 include magnetic storage devices (e.g., floppy disks, drives, HDDs, etc.), optical storage devices (e.g., Blu-ray disks, CDs, DVDs, etc.), RAID systems, and / or solid state storage disks or devices such as flash memory devices and / or SSDs.Executable instructions 1232, which may be implemented by the machine readable instructions of FIGS. 9-11, may be stored in mass storage device 1228, volatile memory 1214, nonvolatile memory 1216, and / or on at least one nonvolatile computer readable storage medium such as a CD or DVD.FIG. 13 is a block diagram of an example implementation of the programmable circuitry 1212 of FIG. 12 In this example, the programmable circuitry 1212 of FIG. 12 is implemented by a microprocessor 1300. Microprocessor 1300 may be, for example, a general purpose microprocessor (e.g., general purpose microprocessor circuitry). The microprocessor 1300 executes some or all of the machine readable instructions of the flowcharts of FIGS. 9-11 to effectively instantiate the circuitry of FIG. 8 as logic circuits to perform the operations corresponding to these machine readable instructions. In some such examples, the circuitry of FIG. 8 is instantiated by the hardware circuits of the microprocessor 1300 in combination with the instructions. For example, the microprocessor 1300 may implement multi-core hardware circuitry, such as a CPU, a DSP, a GPU, an XPU, etc. Although it may include any number of example cores 1302 (e.g., 1 core), the microprocessor 1300 of this example is a multi-core semiconductor device including N cores. Cores 1302 of microprocessor 1300 may operate independently or may cooperate to execute machine readable instructions. For example, machine code corresponding to a firmware program, an embedded software program, or a software program may be executed by one of the cores 1302, or may be executed by multiple of the cores 1302 at the same or different times. In some examples, the machine code corresponding to the firmware program, the embedded software program, or the software program is broken into threads and executed in parallel by two or more of the cores 1302. The software program may correspond to a portion or all of the machine readable instructions and / or operations represented by the flowcharts of FIGS. 9-11.The cores 1302 may communicate via a first example bus 1304. In some examples, the first bus 1304 may implement a communication bus to effect communication associated with one or more of the cores 1302. For example, the first bus 1304 may implement an Inter-Integrated Circuit (I2C) bus and / or a Serial Peripheral Interface (SPI) bus and / or a PCI bus and / or a PCIe bus. Additionally or alternatively, the first bus 1304 may implement any other type of computing or electrical bus. Cores 1302 may receive data, instructions, and / or signals from one or more external devices through example interface circuitry 1306. The cores 1302 may output data, instructions, and / or signals to the one or more external devices through the interface circuitry 1306. Although the cores 1302 of this example include an example local memory 1320 (e.g., level 1 (L1) cache, which may be split into an L1 data cache and an L1 instruction cache), the microprocessor 1300 also includes an example shared memory 1310 that may be shared by the cores (e.g., level 2 (L2_cache)) to enable fast access to data and / or instructions. Data and / or instructions may be transferred (e.g., shared) from shared memory 1310 by writing to and / or reading. The local memory 1320 of each of the cores 1302 and the shared memory 1310 may be part of a hierarchy of devices that include multiple levels of cache memory and main memory (e.g., main memory 1214, 1216 of FIG. 12 ). Typically, higher levels of memory in the hierarchy have a lower access time and have a smaller storage capacity than lower levels of memory. Changes in the various levels of the cache hierarchy are managed (e.g., coordinated) by a cache coherency policy.Each core 1302 may be referred to as a CPU, DSP, GPU, etc., or any other type of hardware circuitry. Each core 1302 includes controller circuitry 1314, arithmetic and logic (sometimes referred to as an ALU) 1316, multiple registers 1318, the L1 cache 1320, and a second example bus 1322. Other structures may be present. For example, each core 1302 may include vector unit circuitry, single instruction multiple data (SIMD) unit circuitry, load / store unit (LSU) circuitry, branch / branch unit circuitry, floating point unit (FPU) circuitry, etc. The controller circuitry 1314 includes semiconductor-based circuits structured to control (e.g., coordinate) data movement within the corresponding core 1302. The AL circuitry 1316 includes semiconductor-based circuits structured to perform one or more mathematical and / or logical operations on the data within the corresponding core 1302. The AL circuitry 1316 of some examples performs integer operations. In other examples, AL circuitry 1316 also performs floating point operations. In still further examples, AL circuitry 1316 may include first AL circuitry that performs integer-based operations and second AL circuitry that performs floating point operations. In some examples, AL circuitry 1316 may be referred to as an arithmetic logic unit (ALU).The registers 1318 are semiconductor-based structures for storing data and / or instructions, such as results of one or more of the operations performed by the AL circuitry 1316 of the corresponding core 1302. The registers 1318 may include, for example, vector registers, SIMD registers, general purpose registers, flag registers, segment registers, machine specific registers, instruction pointer registers, control registers, debug registers, memory management registers, machine check registers, etc. The registers 1318 may be arranged in a bank as shown in FIG. 13. Alternatively, registers 1318 may be organized in any other arrangement, format, or structure, including distribution in core 1302 to reduce access time. The second bus 1322 may be implemented by at least one of an I2C bus, an SPI bus, a PCI bus, or a PCIe bus.Each core 1302 and / or, more generally, the microprocessor 1300 may include additional and / or alternative structures to those shown and described above. For example, one or more clock circuits, one or more power supplies, one or more power gates, one or more cache home agents (CHAs), one or more converged / common mesh stops (CMSs), one or more shifters (e.g., barrel shifter(s)), and / or other circuits may be present. The microprocessor 1300 is a semiconductor device manufactured to include many transistors connected together to implement the structures described above in one or more integrated circuits (ICs) included in one or more packages.The microprocessor 1300 may include and / or cooperate with one or more accelerators (e.g., an accelerator circuit, a hardware accelerator, etc.). In some examples, the accelerators are implemented by logic circuitry to perform certain tasks more quickly and / or efficiently than is possible with a general purpose processor. Examples of accelerators include ASICs and FPGAs, such as those discussed herein. A GPU, a DSP, and / or other programmable device may also be accelerators. Accelerators may be included in microprocessor 1300, in the same die package as microprocessor 1300, and / or in one or more packages separate from microprocessor 1300.FIG. 14 is a block diagram of another example implementation of the programmable circuitry of FIG. 12 In this example, the programmable circuitry 1212 is implemented by the FPGA circuitry 1400. For example, the FPGA circuitry 1400 may be implemented by an FPGA. For example, FPGA circuitry 1400 may be used to perform operations that could otherwise be performed by the example microprocessor 1300 of FIG. 13 executing corresponding machine readable instructions. However, once configured, FPGA circuitry 1400 instantiates the operations and / or functions corresponding to the machine readable instructions in hardware and, accordingly, may often execute the operations / functions faster than they could be performed by a general purpose microprocessor executing the corresponding software.More specifically, unlike the microprocessor 1300 of FIG. 13 described above (which is a general purpose device that can be programmed to execute some or all of the machine readable instructions represented by the flowcharts of FIGS. 9-11, but whose connections and logic circuits are fixed after manufacture), the FPGA circuitry 1400 of the example of FIG. 14 includes connections and logic circuitry that can be configured, structured, programmed, and / or connected in various ways after manufacture, for example, to instantiate some or all of the operations / functions corresponding to the machine readable instructions represented by the flowcharts of FIGS. 9-11. In particular, FPGA 1400 may be viewed as an array of logic gates, interconnects, and switches. The switches may be programmed to change the manner in which the logic gates are interconnected by the interconnects, thereby effectively forming one or more dedicated logic circuits (unless and as long as the FPGA circuitry 1400 is reprogrammed). The configured logic circuits enable the logic gates to cooperate in different ways to perform different operations on the data received by input circuitry. These operations may correspond to some or all of the instructions (e.g., software and / or firmware) represented by the flowcharts of FIGS. 9-11. Thus, FPGA circuitry 1400 may be configured and / or structured to effectively instantiate some or all of the operations / functions corresponding to the machine readable instructions of the flowcharts of FIGS. 9-11 as dedicated logic circuits to perform the operations / functions corresponding to these software instructions in a dedicated manner analogous to an ASIC. Therefore, FPGA circuitry 1400 may perform the operations / functions corresponding to some or all of the machine readable instructions of FIGS. 9-11 faster than the general purpose microprocessor may.In the example of FIG. 14, in response to being programmed (and / or reprogrammed one or more times), FPGA circuitry 1400 is configured and / or structured based on a binary file. In some examples, the binary may be compiled and / or created based on instructions in a hardware description language (HDL) such as Lucid, Very High Speed Integrated Circuits (VHSIC), Hardware Description Language (VHDL), or Verilog. For example, a user (e.g., a human user, a machine user, etc.) Write code or a program corresponding to one or more operations / functions in an HDL; the code / program may be translated into a low-level language as needed; and the code / program (e.g., the code / program in the low-level language) may be converted (e.g., by a compiler, a software application, etc.) to the binary file. In some examples, the FPGA circuitry 1400 of FIG. 14 may access and / or load the binary to cause the FPGA circuitry 1400 of FIG. 14 to be configured and / or structured to perform the one or more operations / functions. The binary file may be implemented, for example, by a bitstream (e.g., one or more computer readable bits, one or more machine readable bits, etc.), data (e.g., computer readable data, machine readable data, etc.), and / or machine readable instructions accessible to the FPGA circuitry 1400 of FIG. 14 to cause configuration and / or structuring of the FPGA circuitry 1400 of FIG. 14, or portions thereof.In some examples, the binary file is compiled, created, transformed, and / or otherwise output from a unified software platform used to program FPGAs. For example, the unified software platform may translate first instructions (e.g., code or program) corresponding to one or more operations / functions in a high-level language (e.g., C, C++, Python, etc.) into second instructions corresponding to the one or more operations / functions in an HDL. In some such examples, the binary file is compiled, created, and / or otherwise output by the unified software platform based on the second instructions. In some examples, the FPGA circuitry 1400 of FIG. 14 may access and / or load the binary file to cause the FPGA circuitry 1400 of FIG. 14 to be configured and / or structured to perform the one or more operations / functions. The binary file may be implemented, for example, by a bitstream (e.g., one or more computer readable bits, one or more machine readable bits, etc.), data (e.g., computer readable data, machine readable data, etc.), and / or machine readable instructions accessible to the FPGA circuitry 1400 of FIG. 14 to cause configuration and / or structuring of the FPGA circuitry 1400 of FIG. 14, or portions thereof.The FPGA circuitry 1400 of FIG. 14 includes example input / output (I / O) circuitry 1402 to receive and / or output data from and / or to the example configuration circuitry 1404 and / or external hardware 1406. Configuration circuitry 1404 may be implemented, for example, by interface circuitry that may receive a binary file that may be implemented by a bitstream, data, and / or machine readable instructions to configure FPGA circuitry 1400 or portions thereof. In some such examples, configuration circuitry 1404 may receive the binary from a user, a machine (e.g., hardware circuitry (e.g., programmable or dedicated circuitry) that may implement an artificial intelligence / machine learning (AI / ML) model to generate the binary), etc., and / or any one or more combinations thereof. In some examples, external hardware 1406 may be implemented by external hardware circuitry. The external hardware 1406 may be implemented by, for example, the microprocessor 1300 of FIG. 13.FPGA circuitry 1400 also includes an array of example logic gate circuitry 1408, multiple example configurable interconnects 1410, and example storage circuitry 1412. Logic gate circuitry 1408 and configurable circuitry 1410 are configurable to instantiate one or more operations / functions that may correspond to at least some of the machine readable instructions of FIGS. 9-11 and / or other desired operations. The logic gate circuitry 1408 shown in FIG. 14 is fabricated in blocks or groups. Each block includes semiconductor-based electrical structures that can be configured in logic circuits. In some examples, the electrical structures include logic gates (e.g., AND gates, OR gates, NOR gates, etc.) that provide basic logic circuit building blocks. Electrically controllable switches (e.g., transistors) are provided within each of the logic gate circuitry 1408 to enable configuration of the electrical structures and / or logic gates to form circuits for performing desired operations / functions. Logic gate circuitry 1408 may include other electrical structures, such as look-up tables (LUTs), registers (e.g., flip-flops or latches), multiplexers, etc.The configurable interconnects 1410 of the illustrated example are conductive paths, conductive traces, vias, or the like, which may include electrically controllable switches (e.g., transistors), the state of which may be changed by programming (e.g., using an HDL command language) to enable or disable one or more interconnects between one or more of the logic gate circuitry 1408 to program desired logic circuits.The storage circuitry 1412 of the illustrated example is structured to store the result or results of one or more of the operations performed by the respective logic gates. The storage circuitry 1412 can be implemented by registers or the like. In the illustrated example, the storage circuitry 1412 is distributed below the logic gate circuitry 1408 to facilitate access and increase execution speed.The example FPGA circuitry 1400 of FIG. 14 also includes example dedicated operation circuitry 1414. In this example, dedicated operation circuitry 1414 includes special purpose circuitry 1416 that can be invoked to implement frequently used functions to avoid the need to program these functions in practical use. Examples of such special purpose circuitry 1416 include memory (e.g., DRAM) control circuitry, PCIe control circuitry, clock circuitry, transceiver circuitry, memory, and multiplier-accumulator circuitry. Other types of special purpose circuitry may be present. In some examples, FPGA circuitry 1400 may also include example programmable general purpose circuitry 1418 such as example CPU 1420 and / or example DSP 1422. Other programmable universal circuitry 1418 may additionally or alternatively be present, such as a GPU, an XPU, etc., which may be programmed to perform other operations.Although FIGS. 13 and 14 illustrate two example implementations of the programmable circuitry 1212 of FIG. 12, many other approaches are contemplated. For example, FPGA circuitry may include an integrated CPU, such as one or more of the example CPUs 1420 of FIG. 14. Thus, the programmable circuitry 1212 of FIG. 12 may be additionally implemented by combining at least the example microprocessor 1300 of FIG. 13 and the example FPGA circuitry 1400 of FIG. 14. In some such hybrid examples, one or more cores 1402 of FIG. 14 may execute a first portion of the machine readable instructions represented by the flowchart or flowcharts of FIGS. 9-11 to perform a first operation(s) / function(s), wherein the FPGA circuitry 1400 of FIG. 14 may be configured and / or structured to perform second operations / functions corresponding to a second portion of the machine readable instructions represented by the flowchart or flowcharts of FIGS. 9-11 and / or an ASIC may be configured and / or structured to perform third operations / functions corresponding to a third portion of the machine readable instructions represented by the flowchart or flowcharts of FIGS. 9-11.It is understood that a portion or the entirety of the circuit arrangement of FIG. 8 may thus be instantiated at the same or different times. For example, same and / or different portions of the microprocessor 1300 of FIG. 13 may be programmed to execute portions of machine readable instructions at the same and / or different times. In some examples, one or more same and / or different portions of the FPGA circuitry 1400 of FIG. 14 may be configured and / or structured to perform operations / functions corresponding to one or more portions of machine readable instructions at the same and / or different times.In some examples, some or all of the circuitry of FIG. 8 may be instantiated in, for example, one or more threads executing simultaneously and / or in series. For example, microprocessor 1300 of FIG. 13 may execute machine readable instructions in one or more threads that execute simultaneously and / or in series. In some examples, the FPGA circuitry 1400 of FIG. 14 may be configured and / or structured to perform operations / functions simultaneously and / or sequentially. Moreover, in some examples, some or all of the circuitry of FIG. 8 may be implemented in one or more virtual machines and / or containers executing on microprocessor 1300 of FIG. 13.In some examples, programmable circuitry 1212 of FIG. 12 may be located in one or more housings. For example, microprocessor 1300 of FIG. 13 and FPGA circuitry 1400 of FIG. 14 may be located in one or more housings. In some examples, an XPU may be implemented by the programmable circuitry 1212 of FIG. 12, which may be located in one or more housings. For example, the XPU may include a CPU (e.g., microprocessor 1300 of FIG. 13, CPU 1420 of FIG. 14, etc.) in one package, a DSP (e.g., DSP 1422 of FIG. 14 ) in another package, a GPU in another package, and an FPGA (e.g., FPGA circuitry 1400 of FIG. 14 ) in yet another package.A block diagram illustrating an example software distribution platform 1505 for distributing software, such as the example machine readable instructions 1232 of FIG. 12, to other hardware devices (e.g., hardware devices owned by third party and / or operated by the owner and / or operator of the software distribution platform) is shown in FIG. 15. The example software distribution platform 1505 may be implemented by any computer server, data equipment, cloud service, etc., capable of storing and transmitting software to other computing devices. The third party may be clients of the entity that owns and / or operates the software distribution platform 1505. For example, the entity that owns and / or operates the software distribution platform 1505 may be a developer, vendor, and / or licenseer of software, such as the example machine readable instructions 1232 of FIG. 12. The third party may be consumers, users, retailers, OEMs, etc., that purchase and / or license the software for use and / or resale and / or for sub-licenses. In the illustrated example, the software distribution platform 1505 includes one or more servers and one or more storage devices. The storage devices store machine readable instructions 1232 that may correspond to the example machine readable instructions of FIGS. 9-11, as described above. The one or more servers of the example software distribution platform 1505 are in communication with an example network 1510, which may correspond to any one or more of the Internet and / or any of the example networks described above. In some examples, the one or more servers, in response to requests, transmit the software to a requesting party as part of a commercial transaction. Payment for the delivery, sale, and / or license of the software may be handled by the one or more servers of the software distribution platform and / or by a third party payment entity. The servers enable buyers and / or licensees to download the machine readable instructions 1232 from the software distribution platform 1505. For example, software that may correspond to the example machine readable instructions of FIGS. 9-11 may be downloaded to the example programmable circuitry platform 1200 that is to execute the machine readable instructions 1232 to implement the code evaluator circuitry 502. In some examples, one or more servers of the software distribution platform 1505 periodically offer, transmit, and / or force updates to the software (e.g., the example machine readable instructions 1232 of FIG. 12 ) to ensure that improvements, patches, updates, etc., are distributed and applied to the software at the end user devices. Although referred to above as software, the distributed "software" could alternatively be firmware.From the foregoing, it will be appreciated that example systems, methods, apparatus, and articles of manufacture have been disclosed that combine large code language models (code LLM) with compilers to add program inference capabilities to code LLM. Methods and apparatus disclosed herein may be provided as part of a software program or as a stand-alone software as-a-service (e.g., optimization as-a-service) model to support designers with complex problems. In the examples described herein, LLMs may solve complex programming problems and improve general programming efficiency. Disclosed systems, methods, apparatus, and articles of manufacture are accordingly directed to one or more improvements in the operation of a machine, such as a computer or other electronic and / or mechanical device.Disclosed herein are example methods, apparatus, systems, and articles of manufacture for combining large code language models (code LLMs) with compilers. Further examples and combinations thereof include the following:Example 1 includes an apparatus comprising interface circuitry, machine readable instructions, and programmable circuitry to instantiate or execute at least one of the machine readable instructions to receive input source code through a large code language model (code LLM), generate one or more code representations of the input source code, analyze the one or more code representations of the input source code; and compile one or more code representations of the input source code into one or more executable instructions on the computer.Example 2 includes the apparatus of example 1, wherein the programmable circuitry is to analyze the one or more code representations of the input source code by executing the machine readable instructions to generate a code representation map based on the input source code and the one or more code representations, access the input source code, and determine an attribute of the input source code based on at least one code representation identified based on the code representation map.Example 3 includes the apparatus of example 2, wherein the at least one code representation is an abstract syntax tree (AST), a control flow graph (CFG), or a data flow graph (DFG).Example 4 includes the apparatus of example 2, wherein the programmable circuitry is to store the code representation map, wherein the code representation map corresponds to a mapping between a single source code element and representations of the source code element.Example 5 includes the apparatus of example 4, wherein the programmable circuitry is to canonicalize the single source code element and the representation of the source code element.Example 6 includes the apparatus of example 5, wherein the source code element includes at least one function, loop, instruction, or variable.Example 7 includes the apparatus of example 1, wherein the input source code is at least one of a vectorizable code or a parallelizable code.Example 8 includes a method comprising receiving input source code through a large code language model (code LLM), generating one or more code representations of the input source code, analyzing one or more code representations of the input source code, and compiling one or more code representations of the input source code into one or more computer-executable instructions.Example 9 includes the method of example 8, further comprising generating a code representation based on the input source code and the code representations, accessing the input source code, and setting an attribute of the input source code based on at least one code representation identified using the code representation mapping.Example 10 includes the method of example 9, wherein the at least one code representation is an abstract syntax tree (AST), a control flow graph (CFG), or a data flow graph (DFG).Example 11 includes the method of example 9, further comprising storing the code representation map, wherein the code representation map corresponds to a mapping between a single source code element and representations of the source code element.Example 12 includes the method of example 11, further comprising kanonizing the single source code element and the representation of the source code element.Example 13 includes the method of example 12, wherein the source code element includes at least one function, loop, instruction, or variable.Example 14 includes the method of example 8, wherein the input source code is at least one of a vectorizable code or a parallelizable code.Example 15 includes a non-transitory machine readable storage medium including instructions that cause programmable circuitry to receive at least one input source code through a large code language model (code LLM), generate one or more code representations of the input source code, analyze one or more code representations of the input source code, and compile the one or more code representations of the input source code into one or more computer executable instructions.Example 16 includes the non-transitory machine readable storage medium of example 15, wherein the instructions are to cause the programmable circuitry to generate a code representation based on the input source code and the code representations, access the input source code, and set an attribute of the input source code based on at least one code representation identified using the code representation mapping.Example 17 includes the non-transitory machine readable storage medium of example 16, wherein the instructions are to cause the programmable circuitry to store the code representation map, wherein the code representation map corresponds to a mapping between a single source code element and representations of the source code element.Example 18 includes the non-transitory machine readable storage medium of example 17, wherein the instructions are to cause the programmable circuitry to kanonize the single source code element and the representation of the source code element.Example 19 includes the non-transitory machine readable storage medium of example 18, wherein the source code element includes at least one function, loop, instruction, or variable.Example 20 includes the non-transitory machine readable storage medium of example 15, wherein the input source code is at least one of a vectorizable code or a parallelizable code.The following claims are hereby incorporated by reference into this detailed description. Although certain example systems, methods, apparatus, and articles of manufacture have been disclosed herein, the scope of this patent is not limited thereto. Rather, this patent covers all systems, methods, apparatus and articles of manufacture that reasonably fall within the scope of the claims of this patent.

Claims

An apparatus comprising: interface circuitry; machine readable instructions; and programmable circuitry for executing and / or instantiating the machine readable instructions to: receive input source code through a large code language model (code LLM); generate one or more code representations of the input source code; analyze the one or more code representations of the input source code; and compile the one or more code representations of the input source code into one or more computer executable instructions.The apparatus of claim 1, wherein the programmable circuitry is to analyze the one or more code representations of the input source code by executing the machine readable instructions to: generate a code representation map based on the input source code and the one or more code representations; access the input source code; and determine an attribute of the input source code based on at least one code representation identified using the code representation map.The apparatus of claim 2, wherein the at least one code representation is an abstract syntax tree (AST), a control flow graph (CFG), or a data flow graph (DFG).The apparatus of any of claims 2 or 3, wherein the programmable circuitry is to store the code representation map, the code representation map corresponding to a mapping between a single source code element and representations of the source code element.The apparatus of claim 4, wherein the programmable circuitry is to canonicalize the single source code element and the representation of the source code element.The apparatus of claim 5, wherein the source code element includes at least one function, loop, instruction, or variable.The apparatus of any of claims 1 or 2, wherein the input source code is at least one of a vectorizable code or a parallelizable code.A method comprising: receiving, by a large code language model (code LLM), input source code; generating one or more code representations of the input source code; analyzing the one or more code representations of the input source code; and compiling the one or more code representations of the input source code into one or more computer-executable instructions.The method of claim 8, further including: generating a code representation map based on the input source code and the one or more code representations; accessing the input source code; and determining an attribute of the input source code based on at least one code representation identified using the code representation map.The method of claim 9, wherein the at least one code representation is an abstract syntax tree (AST), a control flow graph (CFG), or a data flow graph (DFG).The method of any of claims 9 or 10, further comprising storing the code representation map, wherein the code representation map corresponds to a mapping between a single source code element and representations of the source code element.The method of claim 11, further comprising kanonizing the single source code item and the representation of the source code item.The method of claim 12, wherein the source code element includes at least one function, loop, instruction, or variable.The method of any of claims 8 or 9, wherein the input source code is at least one of a vectorizable code or a parallelizable code.A machine-readable storage medium comprising instructions to cause programmable circuitry to at least: receive input source code through a large code language model (code LLM); generate one or more code representations of the input source code; analyze the one or more code representations of the input source code; and compile the one or more code representations of the input source code into one or more computer-executable instructions.The machine readable storage medium of claim 15, wherein the instructions cause the programmable circuitry to: generate a code representation map based on the input source code and one or more code representations; access the input source code; and determine an attribute of the input source code based on at least one code representation identified using the code representation map.The machine readable storage medium of claim 16, wherein the instructions cause the programmable circuitry to store the code representation map, wherein the code representation map corresponds to a mapping between a single source code element and representations of the source code element.The machine readable storage medium of claim 17, wherein the instructions are to cause the programmable circuitry to kanonize the single source code element and the representation of the source code element.The machine readable storage medium of claim 18, wherein the source code element includes at least one function, loop, instruction, or variable.The machine readable storage medium of any one of claims 15 or 16, wherein the input source code is at least one of a vectorizable code or a parallelizable code.

Images