APPARATUS, SYSTEM, AND METHOD FOR COMPILING CODE FOR A PROCESSOR

Abstract

For example, a compiler may be configured to identify a plurality of memory access operations in a loop based on source code to be compiled into target code to be executed by a target processor, where the plurality of memory access operations may include at least a first memory access operation and a second memory access operation to the same memory pointer. For example, the first memory access operation may have a first offset, and the second memory access operation may have a second offset that is different from the first offset. For example, the compiler may configure address generation unit (AGU) configuration code to configure the plurality of memory access operations by the same AGU. For example, the compiler may generate the target code based on the compilation of the source code.For example, the target code can be based on the AGU configuration code.

Description

CROSS-REFERENCE

[0001] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 415,310, entitled "APPARATUS, SYSTEM, AND METHOD OF VECTOR PROCESSING," filed October 12, 2022, the entire disclosure of which is incorporated herein by reference. BACKGROUND

[0002] A compiler can be configured to compile source code into target code that is configured for execution by a processor.

[0003] It is necessary to provide a technical solution to support efficient processing functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] For simplicity and clarity, the elements depicted in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be exaggerated relative to others to clarify the illustration. Furthermore, reference numbers may be repeated in the figures to indicate corresponding or analogous elements. The figures are listed below. Fig. 1 is a schematic block diagram representation of a system according to some example aspects. Fig. 2 is a schematic representation of a compiler according to some exemplary aspects. Fig. 3 is a schematic diagram of a vector processor according to some example aspects. Fig. 4 is a schematic representation of a memory access scheme for loading data from memory with respect to a memory pointer according to some example aspects. Fig. 5 is a schematic representation of a memory access scheme for loading data from memory with respect to a memory pointer, according to some example aspects. Fig. 6 is a schematic flowchart representation of a method of compiling code for a processor according to some example aspects. Fig. 7 is a schematic representation of a product according to some exemplary aspects. DETAILED DESCRIPTION

[0005] In the following detailed description, numerous specific details are included to provide a thorough understanding of some aspects. However, those skilled in the art will understand that some aspects may be practiced without these specific details. In other instances, well-known methods, procedures, components, units, and / or circuits have not been described in detail to avoid obscuring the discussion.

[0006] Some sections of the following detailed description are presented in the form of algorithms and symbolic representations of operations on data bits or binary digital signals in a computer memory. These algorithmic descriptions and representations may be the techniques used by those skilled in the data processing field to communicate the content of their work to others skilled in the art.

[0007] An algorithm is considered here and generally to be a self-consistent sequence of actions or operations that lead to a desired result. This includes physical manipulations of physical quantities. Usually, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has sometimes been found convenient, primarily for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be understood, however, that all these and similar expressions are to be associated with the corresponding physical quantities and are merely convenient labels for these quantities.

[0008] Terms such as "processing", "calculating", "determining", "setting", "analyzing", "testing" or the like may refer to the operation(s) and / or process(es) of a computer, computer platform, computer system, or other electronic computing device that manipulates and / or converts data represented as physical (e.g., electronic) quantities in the registers and / or memory of the computer into other data similarly represented as physical quantities in the registers and / or memory of the computer or other information storage medium that can store instructions for performing operations and / or processes.

[0009] The terms "plurality" and "a plurality," as used herein, include, for example, "several" or "two or more." For example, "a plurality of elements" includes two or more elements.

[0010] References to "an aspect," "an aspect," "an exemplary aspect," "various aspects," etc., indicate that the aspect(s) so described may include a particular feature, structure, or property, but not every aspect necessarily includes that particular feature, structure, or property. Furthermore, the repeated use of the phrase "in an aspect" does not necessarily refer to the same aspect, although it may.

[0011] As used herein, the use of the ordinal adjectives "first," "second," "third," etc., to describe a common object, unless otherwise noted, merely indicates that reference is made to different instances of like objects and is not intended to imply that the objects so described must be in any particular sequence, whether temporally, spatially, in order of precedence, or in any other way.

[0012] For example, some aspects may take the form of a completely hardware-related aspect, a completely software-related aspect, or an aspect that includes both hardware and software elements. Some aspects may be implemented in software, including, but not limited to, firmware, resident software, microcode, or the like.

[0013] Furthermore, some aspects may take the form of a computer program product accessible from a computer-usable or computer-readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For example, a computer-usable or computer-readable medium may be or include a device that can contain, store, communicate, transmit, or transport the program for use by or in connection with the instruction execution system, device, or apparatus.

[0014] In some exemplary aspects, the medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or device or apparatus) or transmission medium.

[0015] In some example aspects, a data processing system capable of storing and / or executing program code may include at least one processor coupled directly or indirectly to storage elements, for example, via a system bus. The storage elements may include, for example, local memory used during actual execution of the program code, mass storage, and cache memories that may provide temporary storage of at least a portion of the program code to reduce the number of times code is retrieved from mass storage during execution.

[0016] In some example aspects, input / output or I / O devices (including, but not limited to, keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or through intermediate I / O control devices. In some example aspects, network adapters may be coupled to the system to couple the computing system to other computing systems or remote printers or storage devices, for example, through intermediate private or public networks. In some example aspects, modems, cable modems, and Ethernet cards are demonstrative examples of types of network adapters. Other suitable components may also be used.

[0017] Some aspects may be used in connection with various devices and systems, such as a computing unit, a computer, a mobile computer, a non-mobile computer, a server computer, or the like.

[0018] As used herein, the term "circuitry" may refer to, be a part of, or include an application-specific integrated circuit (ASIC), an integrated circuit, an electronic circuit, a processor (shared, dedicated, or in a group), and / or memory (shared, dedicated, or in a group) executing one or more software or firmware programs, combinational logic circuitry, and / or other suitable hardware components that provide the described functionality. In certain aspects, some functions associated with the circuitry may be implemented by one or more software or firmware modules. In some aspects, the circuitry may include logic operable at least partially in hardware.

[0019] The term "logic" may, for example, refer to computational logic embedded in the circuitry of a computing device and / or computational logic stored in a memory of a computing device. For example, a processor of the computing device may access the logic to execute the computational logic to perform computational functions and / or operations. For example, the logic may be embedded in various types of memory and / or firmware, e.g., in silicon blocks of various chips and / or processors. Logic may be included in and / or implemented as part of various circuits, e.g., in processor circuitry, control circuitry, and / or the like. In one example, the logic may be embedded in volatile memory and / or non-volatile memory, including random access memory, read-only memory, programmable memory, magnetic memory, flash memory, persistent memory, and the like.Logic may be executed by one or more processors using memory, such as registers, read-only memory, buffers, and / or the like, coupled to the one or more processors, such as as required to execute the logic.

[0020] Referring to Fig. 1, which schematically illustrates a block diagram of a system 100 according to some example aspects.

[0021] As in Fig. 1, the system 100 may include a computing unit 102 according to some example aspects.

[0022] In certain example aspects, the device 102 may be implemented using suitable hardware components and / or software components, such as processors, controllers, memory devices, storage devices, input devices, output devices, communication devices, operating systems, applications, or the like.

[0023] In some example aspects, device 102 may include, for example, a computer, a mobile computing device, a non-mobile computing device, a laptop, a notebook, a tablet computer, a handheld computer, a personal computer (PC), or the like.

[0024] For example, in some example aspects, device 102 may include one or more processors 191, an input unit 192, an output unit 193, a memory unit 194, and / or a storage unit 195. Device 102 may optionally include other suitable hardware and / or software components. In some example aspects, some or all components of one or more devices 102 may be enclosed in a common housing or package and connected to one another or connected in one operation via one or more wired or wireless connections. In other aspects, components of one or more devices 102 may be distributed across multiple or separate devices.

[0025] In certain aspects, processor 191 may include, for example, a central processing unit (CPU), a digital signal processor (DSP), one or more processor cores, a single-core processor, a dual-core processor, a multi-core processor, a microprocessor, a host processor, a controller, a plurality of processors or controllers, a chip, a microchip, one or more circuits, a circuit assembly, a logic unit, an integrated circuit (IC), an application-specific integrated circuit (ASIC), or other suitable general-purpose or special-purpose processor or controller. Processor 191 may execute instructions, for example, from an operating system (OS) of a device 102 and / or from one or more suitable applications.

[0026] In some example aspects, input device 192 may include, for example, a keyboard, keypad, mouse, touchscreen, touchpad, trackball, stylus, microphone, or other suitable pointing or input device. Output device 193 may include, for example, a monitor, screen, touchscreen, flat panel display, light-emitting diode (LED) display, liquid crystal display (LCD) display, plasma display, one or more speakers or headphones, or other suitable output devices.

[0027] In some example aspects, memory unit 194 includes, for example, random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), flash memory, volatile memory, non-volatile memory, cache memory, a buffer, short-term storage, long-term storage, or other suitable storage units. Storage unit 195 may include, for example, a hard drive, a solid-state drive (SSD), or other suitable removable or non-removable storage units. Memory unit 194 and / or storage unit 195 may, for example, store data processed by device 102.

[0028] In some example aspects, device 102 may be configured to communicate with one or more other devices over at least one network 103, e.g., a wireless and / or wired network.

[0029] In some example aspects, the network 103 may include a wired network, a local area network (LAN), a wireless network, a wireless LAN (WLAN), a radio network, a cellular network, a WiFi network, an IR network, a Bluetooth (BT) network, and the like.

[0030] In some example aspects, device 102 may be configured to perform and / or execute one or more operations, modules, processes, methods, and / or the like, e.g., as described herein.

[0031] In some example aspects, the device 102 may include a compiler 160 that may be configured to generate target code 115, for example, based on source code 112, as described below.

[0032] In some exemplary aspects, the compiler 160 may be configured to translate the source code 112 into the target code 115, as described below.

[0033] In some example aspects, compiler 160 may include or be implemented as software, a software module, an application, a program, a subroutine, instructions, an instruction set, computational code, words, values, symbols, and / or the like.

[0034] In some exemplary respects, the source code 112 may include computer code written in a source language.

[0035] In some exemplary aspects, the source language may include a programming language. For example, the source language may include a high-level programming language, such as the C programming language, the C++ programming language, and / or the like.

[0036] In some exemplary aspects, the target code 115 may include computer code written in a target language.

[0037] In some exemplary respects, the target language may include a low-level language such as assembly language, object code, machine code, or the like.

[0038] In some example aspects, the target code 115 may include one or more object files that may, for example, create and / or form an executable program.

[0039] In some exemplary aspects, the executable program may be configured to run on a target computer. For example, the target computer may include particular computer hardware, a particular machine, and / or a particular operating system.

[0040] In some exemplary aspects, the executable program may be configured to execute on a processor 180, as described below.

[0041] In some example aspects, processor 180 may include a vector processor 180, e.g., as described below. In other aspects, processor 180 may include any other type of processor.

[0042] Some example aspects are described herein with respect to a compiler, e.g., compiler 160, configured to compile source code 112 into target code 115 configured to be executed by a vector processor 180, as described below. In other aspects, a compiler, e.g., compiler 160, is configured to compile source code 112 into target code 115 configured to be executed by any other type of processor 180.

[0043] In some exemplary aspects, processor 180 may be implemented as part of device 102.

[0044] In other respects, processor 180 may be implemented as part of any other device, e.g., separate from device 102.

[0045] In some example aspects, the vector processor 180 (also referred to as an "array processor") may include a processor that may be configured to process an entire vector into one instruction, e.g., as described below.

[0046] From other perspectives, the executable program may be configured to run on any other additional or alternative processor type.

[0047] Under certain circumstances, vector processor 180 may be designed to support high-performance image and / or vector processing. For example, vector processor 180 may be configured to process 1 / 2 / 3 / 4D arrays of fixed-point data and / or floating-point arrays very quickly and / or efficiently.

[0048] In some example aspects, vector processor 180 may be configured to process arbitrary data, e.g., structures with pointers to structures. For example, vector processor 180 may include a scalar processor to compute the non-vector data, e.g., assuming the non-vector data is minimal.

[0049] In certain example aspects, compiler 160 may be implemented as a local application executed by device 102. For example, memory unit 194 and / or storage unit 195 may store instructions leading to compiler 160, and / or processor 191 may be configured to execute the instructions leading to compiler 160 and / or perform one or more computations and / or processes of compiler 160, e.g., as described below.

[0050] In other aspects, the compiler 160 may include a remote application executed by any suitable computer system, e.g., a server 170.

[0051] In some example aspects, server 170 may include at least one of a remote server, a web-based server, a cloud server, and / or any other server.

[0052] In some example aspects, server 170 may include a suitable memory and / or storage device 174 on which instructions leading to compiler 160 are stored and a suitable processor 171 to execute the instructions, e.g., as described below.

[0053] In some exemplary respects, the compiler 160 may include a combination of a remote application and a local application.

[0054] In one example, compiler 160 may be downloaded and / or received by the user of device 102 from another computer system, e.g., a server 170, so that compiler 160 may be executed locally by users of device 102. For example, the instructions may be received and stored, e.g., temporarily in memory or a suitable short-term storage or buffer of device 102, e.g., before being executed by processor 191 of device 102.

[0055] In another example, compiler 160 may include a client module executed locally by device 102 and a server module executed by server 170. For example, the client module may include and / or be implemented as a local application, a web application, a website, a web client, e.g., a Hypertext Markup Language (HTML) web application, or the like.

[0056] For example, one or more first operations of compiler 160 may be performed locally, such as by device 102, and / or one or more second operations of compiler 160 may be performed remotely, such as by server 170.

[0057] In other aspects, compiler 160 may include or be implemented by any other suitable arrangement and / or scheme of computing units.

[0058] In some example aspects, the system 100 may include an interface 110, e.g., a user interface, to interface between a user of the device 102 and one or more elements of the system 100, e.g., the compiler 160.

[0059] In certain example aspects, the interface 110 may be implemented using any suitable hardware and / or software components, such as processors, controllers, memory devices, storage devices, input devices, output devices, communication devices, operating systems, and / or applications.

[0060] In some aspects, the interface 110 may be implemented as part of a suitable module, system, device, or component of the system 100.

[0061] From other perspectives, the interface 110 may be implemented as a separate element of the system 100.

[0062] In some example aspects, interface 110 may be implemented as part of device 102. For example, interface 110 may be connected to and / or included as part of device 102.

[0063] For example, interface 110 may be implemented as middleware and / or as part of any suitable application of device 102. For example, interface 110 may be implemented as part of compiler 160 and / or as part of an operating system of device 102.

[0064] In some exemplary aspects, interface 110 may be implemented as part of server 170. For example, interface 110 may be connected to and / or included as part of server 170.

[0065] In one example, interface 110 may include or be a part of a web-based application, a website, a web page, a plug-in, an ActiveX control, a rich content component, such as a Flash or Shockwave component, or the like.

[0066] In some example aspects, the interface 110 may, for example, be connected to and / or include a gateway (GW) 113 and / or an application programming interface (API) 114, for example, to communicate information and / or communications between elements of the system 100 and / or to one or more other, e.g., internal or external, parties, users, applications, and / or systems.

[0067] In some aspects, the interface 110 may include any suitable graphical user interface (GUI) 116 and / or any other suitable interface.

[0068] In some example aspects, the interface 110 may be configured to receive the source code 112, for example, from a user of the device 102, e.g., via the GUI 116 and / or the API 114.

[0069] In some example aspects, the interface 110 may be configured to transfer the source code 112 to, for example, the compiler 160 to generate the target code 115, for example, as described below.

[0070] It will now Fig. 2, which schematically illustrates a compiler 200 according to some exemplary aspects. For example, the compiler 160 ( Fig. 1) implement one or more elements of the compiler 200 and / or perform one or more operations and / or functionalities of the compiler 200.

[0071] From some exemplary points of view, as in Fig. 2, the compiler 200 may be configured to generate a target code 233, for example, by compiling a source code 212 in a source language.

[0072] From some exemplary points of view, as in Fig. 2, the compiler 200 may include a front end 210 configured to receive and parse the source code 212 in the source language.

[0073] In some exemplary aspects, the front end 210 may be configured to generate an intermediate code 213, for example, based on the source code 212.

[0074] In some exemplary respects, intermediate code 213 may include a degraded representation of source code 212.

[0075] In some example aspects, front-end 210 may be configured to perform, for example, lexical analysis, syntax analysis, semantic analysis, and / or other additional or alternative type of analysis of source code 212.

[0076] In some example aspects, the front-end 210 may be configured to identify errors and / or problems with a result of analyzing the source code 212. For example, the front-end 210 may be configured to generate error information, e.g., including error and / or warning messages, which may, for example, identify a location in the source code 212 where an error or problem is detected.

[0077] From some exemplary points of view, as in Fig. 2, compiler 200 may include a middle end 220 configured to receive and process intermediate code 213 and generate customized, e.g., optimized, intermediate code 223.

[0078] In some example aspects, the middle end 220 may be configured to perform one or more adjustments, e.g., optimizations, to the intermediate code 213 to generate, for example, the adjusted intermediate code 223.

[0079] In some example aspects, the middle end 220 may be configured to perform one or more optimizations on the intermediate code 213, for example, regardless of the type of target computer, to execute the target code 233.

[0080] In some exemplary respects, the middle end 220 may be implemented to support the use of the optimized intermediate code 223, for example, for different machine types.

[0081] In some example aspects, the middle end 220 may be configured to optimize the intermediate representation of the intermediate code 223, for example, to improve the performance and / or quality of the generated target code 233.

[0082] In some exemplary aspects, the one or more optimizations of the intermediate code 213 may include, for example, inline expansion, dead code elimination, constant transfer, loop conversion, parallelization, and / or the like.

[0083] From some exemplary points of view, as in Fig. 2, the compiler 200 may include a backend 230 configured to receive and process the customized intermediate code 213 and generate the target code 233 based on the customized intermediate code 213.

[0084] In some example aspects, the backend 230 may be configured to perform one or more operations and / or processes that may be specific to the target computer to execute the target code 233. For example, the backend 230 may be configured to process the optimized intermediate code 213 by applying analysis, transformation, and / or optimization operations to the customized intermediate code 213, which may be configured, for example, based on the target computer to execute the target code 233.

[0085] In some example aspects, the one or more analysis, conversion, and / or optimization operations applied to the adapted intermediate code 213 may include, for example, resource and storage decisions, e.g., register allocation, instruction scheduling, and / or the like.

[0086] In certain aspects, the target code 233 may include target-dependent assembly code that may be specific to the target computer and / or a target operating system of the target computer that is intended to execute the target code 233.

[0087] In certain respects, the target code 233 may include target-dependent assembly code for a processor, e.g., vector processor 180 ( Fig. 1).

[0088] In some exemplary aspects, compiler 200 may include a Vector Micro-Code Processor (VMP) compiler for Open Computing Language (OpenCL), e.g., as described below. In other aspects, compiler 200 may include or be implemented as part of any other vector processor compiler.

[0089] In some exemplary aspects, the VMP OpenCL compiler may include a Low Level Virtual Machine (LLVM)-based (LLVM-based) compiler that may be configured according to an LLVM-based compilation scheme, for example, to lower OpenCL C code to VMP accelerator assembly code suitable, for example, for execution by vector processor 180 ( Fig. 1).

[0090] In some exemplary aspects, compiler 200 may include one or more technologies that may be required to compile code into a format suitable for a VMP architecture, e.g., in addition to open source LLVM compiler passes.

[0091] In some exemplary aspects, FE 210 may be configured to parse and translate the OpenCL C code, e.g., through an Abstract Syntax Tree (AST), into, for example, an LLVM Intermediate Representation (IR).

[0092] In some exemplary aspects, compiler 200 may include a dedicated API, for example, to identify a correct pattern for compiler pattern matching suitable for, for example, the VMP. For example, the VMP may be configured as a Complex Instruction Set Computer (CISC) implementing a very complex instruction set architecture (ISA) that may be difficult to address from standard C code. According to this case, compiler pattern matching may not easily identify the correct pattern, and in this case, the compiler may require a dedicated API.

[0093] From some exemplary perspectives, FE 210 may implement one or more built-in vendor extensions that may, for example, target VMP-specific ISAs, in addition to the standard OpenCL integrations that may be optimized for a VMP machine.

[0094] In some exemplary respects, FE 210 may be configured to implement OpenCL structures and / or work item functions.

[0095] In some exemplary aspects, ME 220 may be configured to process LLVM IR code, which may, for example, be general and target-independent, although it may include one or more hooks for specific target architectures.

[0096] In some exemplary respects, ME 220 may perform one or more custom passes, for example, to support the VMP architecture as described below.

[0097] In some exemplary aspects, ME 220 may be configured to perform one or more CFG (Control Flow Graph) linearization analysis operations, as described below.

[0098] In some exemplary aspects, the CFG linearization analysis can be configured to linearize the code, for example, by converting if statements to selection patterns, if the VMP vector code does not support the standard control flow.

[0099] In an example, ME 220 can receive a specific code, e.g. as follows: If (x > 0) { A = A + 5;} else { B = B * 2;} According to this example, ME 220 can be configured to apply CFG linearization analysis to the given code, for example, as follows: tmpA = A + 5; tmpB = B * 2; mask = x > 0; A = Select mask, tmpA, A B = Select not mask, tmpB, B Example (1)

[0100] In some exemplary aspects, ME 220 may be configured to perform one or more auto-vectorization analysis operations, e.g., as described below.

[0101] In some exemplary aspects, the auto-vectorization analysis may be configured to vectorize a given code, e.g., automatically vectorize it to utilize the vector capabilities of the VMP.

[0102] In some exemplary aspects, ME 220 may be configured to perform auto-vectorization analysis, e.g., to vectorize code in scalar form. For example, some or all of the auto-vectorization analysis operations may not be performed, e.g., if the code is already provided in vectorized form.

[0103] Under certain exemplary aspects, e.g., in some use cases and / or scenarios, a compiler may not always be able to automatically vectorize code, e.g., due to data dependencies between loop iterations.

[0104] In one example, ME 220 can receive a specific code, e.g., as follows: char* a,b,c; for (int i=0; i < 2048; i++) { a[i]=b[i]+c[i];} According to this example, ME 220 can be configured to perform CFG auto-vectorization analysis by applying a first conversion, e.g., as follows: char* a,b,c; for (int i=0; i < 2048; i+=32) { a[i.i+31]=b[i...i+31]+c[i...i+31];} Example (2a)

[0105] For example, ME 220 may be configured to perform CFG auto-vectorization analysis by applying a second transformation, e.g., after the first transformation, e.g., as follows: char32* a,b,c; for (int i=0; i < 64; i++) { a[i]=b[i]+c[i];} Example (2b)

[0106] In some exemplary aspects, ME 220 may be configured to perform one or more Scratch Pad Memory Loop Access Analysis (SPMLAA) operations, such as described below.

[0107] From some exemplary perspectives, the SPMLAA may define processing blocks (PB), such as those that should later be outlined and compiled for VMP.

[0108] In some exemplary aspects, the processing blocks may include accelerated loops that may be executed by the vector unit of the VMP.

[0109] In some exemplary aspects, a PB, e.g., each PB, may include memory references. For example, some or all memory accesses may reference local memory banks.

[0110] In some exemplary aspects, the VMP may enable access to memory banks via AGUs, e.g., AGUs 320 as described below with reference to Fig. 3, and scatter-gather units (SG).

[0111] In some exemplary aspects, the AGUs can be preconfigured, e.g., before the execution of a loop. For example, the number of loop iterations can be calculated, e.g., before executing a processing block.

[0112] In some exemplary aspects, image references, e.g., some or all of the image references, may be created in this phase, and steps and offsets may be calculated, e.g., per dimension for each reference.

[0113] In some exemplary aspects, ME 220 may be configured to perform one or more AGU planner analysis operations, e.g., as described below.

[0114] In some exemplary aspects, the AGU scheduler analysis may include an iterator assignment that may cover image references, e.g., all image references, from the entire processing block.

[0115] In some exemplary respects, an iterator may cover a single reference or a group of references.

[0116] In certain exemplary aspects, one or more references to memory may be merged and / or the same access may be reused through shuffle instructions and / or values ​​read from previous iterations may be stored.

[0117] In certain exemplary aspects, other references to memory, such as those without a linear access pattern, may be processed using a scatter-gather (SG) unit, but this may result in a performance penalty because indexes and / or masks may need to be maintained.

[0118] In some exemplary aspects, a plan may be configured as an arrangement of iterators within a processing block. For example, a processing block may have multiple plans, e.g., theoretically.

[0119] From some example perspectives, the AGU planner analysis can be configured to create all possible plans for all PBs and select a combination, e.g., a best combination, from all valid combinations.

[0120] Under some exemplary aspects, the total number of iterators in a valid combination can be restricted, e.g., to not exceed the number of available AGUs on a VMP.

[0121] In some exemplary aspects, one or more parameters, e.g., including step size, width, and / or base, may be defined for an iterator, e.g., for each iterator as part of the AGU planner analysis. For example, min-max ranges may be defined for the iterators in a dimension, e.g., in each dimension, e.g., as part of the AGU planner analysis.

[0122] In some example aspects, the AGU scheduler analysis may be configured to track and evaluate a reference to memory, e.g., any reference to memory to an image, e.g., to understand its access pattern.

[0123] In an example according to Examples 2a / 2b, the image “a”, which is the base address, can be accessed with steps of 32 bytes for 64 iterations.

[0124] In some exemplary aspects, the LLVM may include a scalar evaluation analysis (SCEV) that can compute an access pattern, e.g., to understand each reference to images.

[0125] In some exemplary aspects, ME 220 can utilize masking capabilities of the AGUs, e.g., to avoid maintaining an induction variable that may have a performance penalty.

[0126] In some exemplary aspects, ME 220 may be configured to perform one or more rewrite analysis operations, e.g., as described below.

[0127] In some exemplary aspects, the rewrite analysis may be configured to transform the code of a processing block, e.g., while setting iterators and / or changing memory access instructions.

[0128] From some exemplary perspectives, setting the iterators, e.g., all iterators, in IR can be implemented in target-specific intrinsic functions. For example, setting the iterators can be in a pre-header of an outermost loop.

[0129] In some exemplary respects, the rewrite analysis may include loop perfection analysis, as described below.

[0130] From some exemplary perspectives, the code can be compiled with the goal that essentially all calculations should be performed within the innermost loop.

[0131] For example, loop perfection analysis can lift instructions, such as moving an operation that is performed after a final iteration of the loop into a loop.

[0132] For example, loop perfection analysis can lower instructions, such as moving an operation that is performed before a first iteration of the loop into a loop.

[0133] For example, loop perfection analysis can raise and / or lower instructions, e.g., such that essentially all instructions are moved from outer loops to the innermost loops.

[0134] For example, the loop perfection analysis can be configured to provide a technical solution to support VMP iterators, e.g., to work only with perfectly nested loops.

[0135] For example, loop perfection analysis may lead to a situation where there are no commands between the "for" statements that make up the loop, e.g., to support VMP iterators, which cannot emulate such cases.

[0136] In some exemplary aspects, the loop perfection analysis may be configured to summarize a nested loop into a single summarized loop.

[0137] In one example, ME 220 can receive a specific code, e.g., as follows: for (int i = 0; i < N; i++) { int sum = 0; for (int j = 0; j < M; j++) { sum += a[j + stride * i];} res[i] = sum;

[0138] According to this example, ME 220 can be configured to perform loop perfection analysis to combine the nested loop in the code into a single combined loop, for example, as follows: for (int k = 0; k < N * M; k++) { sum = (k % M == 0 ? 0 : sum); sum += a[k % M + stride * (k / M)]; res[k / M] = sum;} Example (3)

[0139] In some exemplary aspects, ME 220 may be configured to perform one or more vector loop contour analysis operations as described below.

[0140] In some exemplary aspects, the vector loop outline analysis may be configured to split code between a scalar subsystem and a vector subsystem, e.g., vector processing block 310 ( Fig. 3) and scalar processor 330 ( Fig. 3), as described below with reference to Fig. 3 described.

[0141] In some exemplary aspects, the VMP accelerator may include the scalar and / or vector subsystems, e.g., as described below. For example, each of the subsystems may have different compute units / processors. Accordingly, scalar code may be compiled on a scalar compiler, e.g., an SSC compiler, and / or accelerated vector code may be executed on the VMP vector processor.

[0142] In some exemplary perspectives, vector loop outline analysis can be configured to create a separate function for a loop body of the accelerated vector code. These functions can, for example, be marked for VMP and / or continue to the VMP backend, while the rest of the code can be compiled by the SSC compiler.

[0143] In certain exemplary aspects, one or more parts of a vector loop, such as the configuration of the vector unit and / or the initialization of vector registers, may be performed by a scalar unit. However, these parts may be performed at a later stage, such as by backpatching into the scalar code, since the scalar code may still be in LLVM IR prior to processing by the SSC compiler.

[0144] In some exemplary aspects, BE 230 may be configured to translate the LLVM IR into machine instructions. For example, BE 230 may not be target-agnostic and may be familiar with target-specific architecture and optimizations, e.g., compared to ME 220, which may be target-specific architecture agnostic.

[0145] In some exemplary aspects, BE 230 may be configured to perform one or more analyses that may be specific to a target machine, such as a VMP machine, to which the code is lowered, even though BE 230 may use the common LLVM.

[0146] In some example aspects, BE 230 may be configured to perform one or more operations of instruction descent analysis, e.g., as described below.

[0147] In some exemplary aspects, the instruction descent analysis may be configured to translate LLVM IR into directed instructions (Machine IR, MIR), for example, by translating the LLVM IR into a directed acyclic graph (DAG).

[0148] In some exemplary aspects, the DAG may undergo a legalization process of instructions, for example, based on the data types and / or VMP instructions that can be supported by a VMP HW.

[0149] In some example aspects, the instruction depression analysis may be configured to perform a pattern matching process, e.g., after the instruction legalization process, to, for example, lower a node, e.g., each node, in the DAG, e.g., into a VMP-specific machine instruction.

[0150] In some exemplary respects, the instruction descent analysis may be configured to generate the MIR, e.g., after the pattern matching process.

[0151] In certain exemplary aspects, the instruction lowering analysis may be configured to lower the instruction according to the machine application binary interface (ABI) and / or calling conventions.

[0152] In some exemplary aspects, BE 230 may be configured to perform one or more unit balancing analysis operations, e.g., as described below.

[0153] In some exemplary aspects, the unit balancing analysis may be configured to balance instructions between VMP compute units, e.g., data processing units 316 ( Fig. 3), as described below with reference to Fig. 3, be balanced.

[0154] From some exemplary perspectives, the unit balancing analysis may be familiar with some or all of the available arithmetic conversions and / or perform conversions according to an optimal algorithm.

[0155] In some example aspects, BE 230 may be configured to perform one or more modulo scheduler (pipelined) analysis operations, e.g., as described below.

[0156] In some example aspects, the pipeliner may be configured to schedule the instructions according to one or more constraints, such as data dependency, resource constraints, and / or other constraints, for example, using Swing Modulo Scheduling (SMS) heuristics and / or other additional and / or alternative heuristics.

[0157] In some exemplary aspects, the pipeliner may be configured to create a schedule of Very Long Instruction Word (VLIW) instructions, such as an initiation interval (II), that iterates the program, for example, during a steady state.

[0158] From some example perspectives, a performance metric, which may be based on a number of cycles that a typical loop can execute, may be measured, for example, as follows: (Size of input data in bytes) * II / (bytes consumed / generated per iteration)

[0159] Under some exemplary aspects, the pipeliner may try to minimize II, e.g., as much as possible, to improve performance.

[0160] In some example scenarios, the pipeliner may be configured to calculate a minimum II and create a schedule accordingly. For example, if the pipeliner fails to meet the schedule, it may attempt to increase the II and recreate the schedule, e.g., until a predefined II threshold is exceeded.

[0161] In some example aspects, BE 230 may be configured to perform one or more register mapping analysis operations, e.g., as described below.

[0162] In some exemplary aspects, the register allocation analysis may be configured to attempt to allocate a register in an efficient, e.g., optimal, manner.

[0163] In some exemplary aspects, the register mapping analysis may assign values ​​to bypass vector registers, general-purpose vector registers, and / or scalar registers.

[0164] In some example aspects, the values ​​may include private variables, constants, and / or values ​​that are rotated across iterations.

[0165] In some exemplary cases, register mapping analysis may implement an optimal heuristic that matches one or more VMP register file (regfile) constraints. For example, in some use cases, register mapping analysis may not use a standard LLVM register map.

[0166] Under certain exemplary circumstances, the register mapping analysis may fail in some cases, which may mean that the loop fails to compile. Accordingly, the register mapping analysis may implement a retry mechanism that returns to the modulo scheduler and attempts to reschedule the loop, e.g., with an increased initiation interval. For example, increasing the initiation interval may reduce register pressure and / or aid the compilation of the vector loop, e.g., in many cases.

[0167] In some example aspects, BE 230 may be configured to perform one or more SSC configuration analysis operations, e.g., as described below.

[0168] In some example aspects, the SSC configuration analysis may be configured to determine a configuration for running the kernel, such as the AGU configuration.

[0169] In some exemplary respects, the SSC configuration analysis may be performed at a late stage, for example, due to configurations calculated after legalization, register mapping analysis, and / or modulo scheduling analysis.

[0170] In some exemplary aspects, the SSC configuration analysis may include a zero-overhead loop (ZOL) mechanism in the vector loop. For example, the ZOL mechanism may configure a loop execution count based on a pattern of memory references in the loop, for example, to avoid executing instructions that check the loop exit condition on each iteration.

[0171] In some exemplary aspects, a VMP compilation flow may include one or more steps, e.g., some steps that can be called during the compilation flow in a test library (testlib), such as a wrapper script for compilation, execution, and / or program testing. These steps may, for example, be executed outside of the LLVM compiler.

[0172] In some exemplary aspects, a PCB Hardware Description Language (PHDL) simulator may be implemented to perform one or more roles of an assembler, encoder, and / or linker.

[0173] In some exemplary aspects, compiler 200 may be configured to provide a technical solution to support robustness, allowing the compilation of a wide range of loops with hardware constraints. For example, compiler 200 may be configured to support a technical solution that does not generate verification errors.

[0174] From some exemplary perspectives, compiler 200 may be configured to provide a technical solution that supports programmability, allowing a user to express code in various ways that can be correctly compiled for the VMP architecture.

[0175] In some exemplary aspects, compiler 200 may be configured to provide a technical solution to support an enhanced user experience, which may enable the user to debug and / or profile code. For example, the enhanced user experience may provide informative error messages, reporting tools, and / or a profiler.

[0176] In some exemplary aspects, compiler 200 may be configured to provide a technical solution to support improved performance, e.g., to optimize VMP assembly code and / or iterator accesses, which may result in faster execution. For example, improved performance may be achieved by high utilization of the compute units and leveraging their complex CISC.

[0177] It will now Fig. 3, which schematically illustrates a vector processor 300 according to some example aspects. For example, the vector processor 180 ( Fig. 1) implement one or more elements of the vector processor 300 and / or perform one or more operations and / or functionalities of the vector processor 300.

[0178] In some example aspects, the vector processor 300 may include a vector microcode processor (VMP).

[0179] In some example aspects, the vector processor 300 may include a WVM (Wide Vector Machine) that supports, for example, VLIW (Very Long Instruction Word) and / or SIMD (Single Instruction / Multiple Data) architectures.

[0180] In some example aspects, the vector processor 300 may be configured to provide a technical solution to support high performance for short integer types, which may be common in, for example, machine vision and / or deep learning algorithms.

[0181] In other aspects, the vector processor 300 may include any other type of vector processor and / or be configured to support other additional or alternative functionality.

[0182] From some exemplary points of view, as in Fig. 3, the vector processor 300 may include a vector processing block (vector processor) 310, a scalar processor 330, and a direct memory access (DMA) 340, as described below.

[0183] From some exemplary points of view, as in Fig. As illustrated in Figure 3, vector processing block 310 may be configured to process image data and / or vector data, e.g., efficiently. For example, vector processing block 310 may be configured to use vector calculation units, e.g., to accelerate calculations.

[0184] In some exemplary aspects, the scalar processor 330 may be configured to perform scalar calculations. For example, the scalar processor 330 may be used as "glue logic" for programs that include vector calculations. For example, some, e.g., even most, calculations of the programs may be performed by the vector processing block 310. However, several tasks, for example, some essential tasks, e.g., scalar calculations, may be performed by the scalar processor 330.

[0185] In some example aspects, the DMA 340 may be configured to connect to one or more memory elements in a chip that includes the vector processor 300.

[0186] In some exemplary aspects, the DMA 340 may be configured to read inputs from main memory and / or write outputs to main memory.

[0187] In some example aspects, the scalar processor 330 and the vector processing block 310 may use respective local memories to process data.

[0188] From some exemplary points of view, as in Fig. 3, the vector processor 300 may include a fetch and decode unit 350 that may be configured to control the scalar processor 330 and / or the vector processing block 310.

[0189] In some example aspects, operations of the scalar processor 330 and / or the vector processing block 310 may be triggered by instructions stored in a program memory 352.

[0190] In some exemplary aspects, the DMA 340 may be configured to transfer data in parallel with the execution of the program instructions in the memory 352, for example.

[0191] In some exemplary respects, the DMA 340 may be controlled by software, e.g., via configuration registers, rather than instructions, and may accordingly be considered a second "thread of execution" in the vector processor 300.

[0192] In some example aspects, the scalar processor 330, the vector processing block 310, and / or the DMA 340 may include one or more data processing units, such as a set of data processing units as described below.

[0193] In some example aspects, the data processing units may include hardware configured to perform calculations, such as an arithmetic logic unit (ALU).

[0194] In one example, a computing device may be configured to add numbers and / or store the numbers in a memory.

[0195] In some exemplary aspects, the data processing units may be controlled by instructions encoded, for example, in program memory 352 and / or configuration registers. For example, the configuration registers may be mapped as memory and written by the memory store instructions of scalar processor 330.

[0196] In some example aspects, the scalar processor 330, the vector processing block 310, and / or the DMA 340 may include a state configuration that includes a set of registers and memories, as described below.

[0197] From some exemplary points of view, as in Fig. 3, the vector processor block 310 may include a set of vector memories 312, which may be configured, for example, to store data to be processed by the vector processor block 310.

[0198] From some exemplary points of view, as in Fig. 3, the vector processor block 310 may include a set of vector registers 314, which may be configured, for example, for use in data processing by the vector processor block 310.

[0199] In some example aspects, the scalar processor 330, the vector processing block 310, and / or the DMA 340 may be coupled to a set of memory maps.

[0200] In some example aspects, a memory map may include a set of addresses accessible by a computing device that can load and / or store data from registers and memories.

[0201] From some points of view, as in Fig. 3, the vector processing block 310 may include a plurality of address generation units (AGUs) 320, which may include addresses accessible to them, e.g., in one or more memories 312.

[0202] From some exemplary points of view, as in Fig. 3, the vector processor block 310 may include a plurality of data processing units 316, for example, as described below.

[0203] In some example aspects, data processing units 316 may be configured to process instructions, e.g., to include multiple numbers at a time. In one example, an instruction may include 8 numbers. In another example, an instruction may include 4 numbers, 16 numbers, or any other number of numbers.

[0204] In some exemplary aspects, two or more computing units 316 may be used simultaneously. In one example, computing units 316 may process and execute a plurality of different instructions, e.g., three different instructions including, for example, eight numbers, during a single cycle.

[0205] In some example aspects, computing units 316 may be asymmetric. For example, first and second computing units 316 may support different instructions. For example, a first computing unit 316 may perform an addition and / or a second computing unit 316 may perform a multiplication. For example, both operations may be performed by one or more additional computing units 316.

[0206] In some example aspects, data processing units 316 may be configured to support arithmetic operations on many combinations of input and output data types.

[0207] In some example aspects, data processing units 316 may be configured to support one or more operations that may be less common. For example, processing units 316 may support operations that operate on a look-up table (LUT) of a vector processor 300 and / or any other operations.

[0208] In some example aspects, data processing units 316 may be configured to support efficient computation of nonlinear functions, histograms, and / or random data access, which may be useful, for example, for implementing algorithms such as image scaling, Hough transforms, and / or other algorithms.

[0209] For example, in some example aspects, vector memories 312 may include memory banks of 16K or other sizes that may be accessed in the same cycle.

[0210] In one example, a maximum memory access size may be 64 bits. According to this example, a peak throughput may be 256 bits, e.g., 64x4 = 256. For example, a high memory bandwidth may be implemented to utilize the computing capabilities of the data processing units 316.

[0211] In one example, two data processing units 316 can support 16 8-bit multiply-and-accumulate (MAC) operations per cycle. According to this example, the two data processing units 316 may not be useful, for example, if the input numbers are not fetched at this speed and / or there are not exactly 256 bits of input, e.g., 16 x 8 x 2 = 256.

[0212] In some example aspects, AGUs 320 may be configured to perform memory access operations, such as loading and storing data from / to vector memory 314.

[0213] In certain circumstances, AGUs 320 may be configured to calculate addresses of input and output data elements, for example, to process I / O and utilize data processing units 316, e.g., when raw bandwidth is insufficient.

[0214] In some example aspects, AGUs 320 may be configured to calculate the addresses of the input and / or output data elements, for example, based on configuration registers written by scalar processor 330, for example, before a block of vector instructions, e.g., a loop, is entered.

[0215] For example, AGUs 320 may be configured to write an image base pointer, width, height, and / or step to the configuration registers to, for example, iterate over an image.

[0216] In some example aspects, AGUs 320 may be configured to handle addressing, e.g., all addressing, to provide a technical solution where data processing units 316 do not have the burden of incrementing pointers or counters in a loop and / or the burden of checking for end-of-line conditions, e.g., to zero a counter in the loop.

[0217] From some exemplary points of view, as in Fig. As shown in Figure 3, AGUs 320 may include four AGUs, and accordingly, four memories 312 may be accessed in one cycle. From other perspectives, any other number of AGUs 32 may be implemented.

[0218] In some exemplary aspects, AGUs 320 may not be "tied" to memory banks 312. For example, an AGU 320, e.g., any AGU 320, may access a memory bank 312, e.g., any memory bank 312, as long as two or more AGUs 320 do not attempt to access the same memory bank 312 in the same cycle.

[0219] In some example aspects, vector registers 314 may be configured to support communication between data processing units 316 and AGUs 320.

[0220] In one example, the total number of vector registers 314 may be 28, which may be divided into multiple subsets, e.g., based on their function. For example, a first subset of the vector registers 314 may be used for input / output of, e.g., all compute units 316 and / or AGUs 320; and / or a second subset of the vector registers 314 may not be used for output of some operations, e.g., most operations, and may be used for one or more other operations, e.g., storing loop-invariant inputs.

[0221] In some example aspects, a compute unit 316, e.g., each compute unit 316, may include one or more registers to host an output of a most recently executed operation, which may, for example, be fed as inputs to other compute units 316. For example, these registers may "bypass" the vector registers 314 and operate faster than if these outputs were written to the first set of vector registers 314.

[0222] In certain exemplary aspects, the fetch and decode unit 350 may be configured to support low-overhead vector loops, such as very low-overhead vector loops (also referred to as "zero-overhead vector loops"). In such cases, for example, it may not be necessary to check an exit condition during the execution of the vector loop.

[0223] For example, an exit condition may be signaled by an AGU 320, for example, when the AGU 320 has completed iterating over a configured memory range.

[0224] For example, the fetch and decode unit 350 may exit the loop, for example, when the AGU 320 signals the termination condition.

[0225] For example, the scalar processor 330 may be used to configure the loop parameters, such as first and last instructions and / or the exit condition.

[0226] In one example, vector loops may be used, for example, in conjunction with high memory bandwidth and / or low-cost addressing to solve a control and data flow problem, for example, to provide a technical solution that enables the data processing units 316 to process data, e.g., without significant additional overhead.

[0227] In some aspects, scalar processor 330 may be configured to provide one or more functionalities that may be complementary to those of vector processing block 310. For example, a large portion, such as most, of the work in a vector program may be performed by data processing units 316. For example, scalar processor 330 may be used to "stitch together" the various blocks of vector code of the vector program.

[0228] In some aspects, the scalar processor 330 may be implemented separately from the vector processing block 310. In other aspects, the scalar processor 330 may be configured to share one or more components and / or functionality with the vector processing block 310.

[0229] In certain exemplary aspects, the scalar processor 330 may be configured to perform operations that are not suitable for execution in the vector processing block 310.

[0230] For example, scalar processor 330 may be used to execute 32-bit C programs. Scalar processor 330 may, for example, be configured to support 1-, 2-, and / or 4-byte C code data types and / or some or all of C code's arithmetic operators.

[0231] For example, the scalar processor 330 may be configured to provide a technical solution to perform operations that cannot be performed in the vector processing block 310, for example, without using a full CPU.

[0232] In some example aspects, the scalar processor 330 may include a scalar data memory 332, which may be, for example, 16K or other size and may be configured to store data, such as variables used by the scalar portions of a program.

[0233] For example, the scalar processor 330 may store local and / or global variables declared by portable C code that may be assigned to the scalar data store by a compiler, e.g., compiler 200 ( Fig. 2).

[0234] From some exemplary points of view, as in Fig. 3, the scalar processor 330 may include or be coupled to a set of vector registers 334 that may be used in a data processing process executed by the scalar processor 330.

[0235] In some example aspects, the scalar processor 330 may be coupled to a scalar memory map that may assist the scalar processor 330 in accessing substantially all states of the vector processor 300. For example, the scalar processor 330 may configure the vector units and / or the DMA channels via the scalar memory map.

[0236] In some exemplary aspects, the scalar processor 330 may not be permitted to access one or more control registers for blocks that may be used by external processors to execute and debug vector programs.

[0237] In some example aspects, DMA 340 may be configured to communicate with one or more other components of a chip implementing vector processor 300, for example, via main memory. For example, DMA 340 may be configured to transfer blocks of data, such as large, contiguous blocks of data, to support, for example, the scalar processor 330 and / or the vector processing block that may manipulate data stored in the local memories. For example, a vector program may read data from the chip's main memory using DMA 340.

[0238] In some example aspects, DMA 340 may be configured to communicate with other elements of the chip, for example, via a plurality of DMA channels, e.g., 8 DMA channels or any other number of DMA channels. For example, a DMA channel, e.g., any DMA channel, may be capable of transferring a rectangular patch from the local memories to the chip's main memory, or vice versa. In other aspects, the DMA channel may transfer any other type of data block between the local memories and the chip's main memory.

[0239] From certain exemplary perspectives, a rectangular patch can be defined by a base pointer, a width, a height, and a step size.

[0240] For example, at maximum throughput, 8 bytes can be transferred per cycle, but overhead may be incurred for each patch and / or for each row in a patch.

[0241] In some exemplary aspects, DMA 340 may be configured to transfer data in parallel with computations, e.g., across multiple DMA channels, as long as executing instructions do not access any local memory involved in the transfer.

[0242] For example, because all channels access the same memory bus, using multiple channels to perform a transfer may not save I / O cycles compared to, for example, using a single channel. However, the multiple DMA channels can be used to schedule multiple transfers and execute them in parallel with computations. This can be advantageous compared to, for example, a single channel, where a second transfer may not be scheduled before the first is complete.

[0243] In some exemplary aspects, DMA 340 can be linked to a memory mapper that can assist the DMA channels in accessing vector memory and / or the scalar data. For example, access to the vector memory can be performed in parallel with computations. For example, parallel access to the scalar data is generally not permitted because the scalar processor 330 can be incorporated into almost any meaningful program and is likely to access its local variables while the transfer is being performed, which could result in a memory conflict with the active DMA channel.

[0244] In some exemplary aspects, DMA 340 may be configured to provide a technical solution to support the parallelization of I / O and computations. For example, a program performing computations may not need to wait for I / O, e.g., if those computations can be performed quickly by vector processing block 310.

[0245] In some example aspects, an external processor, e.g., a CPU, may be configured to initiate execution of a program on vector processor 300. For example, vector processor 300 may remain idle until program execution is initiated.

[0246] In some example aspects, the external processor may be configured to debug the program, e.g., executing a single step at a time, stopping when the program reaches breakpoints, and / or checking the contents of registers and memory in which the program variables are stored.

[0247] In some example aspects, external memory mapping may be implemented to assist the external processor in controlling the vector processor 300 and / or debugging the program, for example, by writing to control registers of the vector processor 300.

[0248] In some exemplary aspects, external memory mapping may be implemented by a superset of scalar memory mapping. This implementation may, for example, make all registers and memory defined by the architecture of vector processor 300 accessible to a debugger backend running on the external processor.

[0249] In some example aspects, the vector processor 300 may trigger an interrupt signal, for example, when the vector processor 300 terminates a program.

[0250] In some exemplary aspects, the interrupt signal may be used, for example, to implement a driver that manages a queue of programs scheduled for execution by the vector processor 300 and / or to start a new program, e.g., by the external processor, for example, upon completion of a previously executed program.

[0251] Referring to Fig. 1, in some example aspects, compiler 160 may be configured to generate target code 115 based on one or more loops, which may be based on source code 112, for example, as described below.

[0252] In certain exemplary respects, one or more loops may be nested in a loop nest, as described below.

[0253] In some exemplary aspects, a loop nest may include at least one outer and one inner loop, as described below.

[0254] In certain example aspects, the loop nest may include an outer loop, e.g., an outermost loop, an inner loop, e.g., an innermost loop, and one or more nested loops (also referred to as "intermediate nesting loops" or "intermediate loops") that may be nested between the outer loop and the inner loop, e.g., as described below.

[0255] In certain exemplary aspects, the loop nest may include a plurality of loops nested in a plurality of nest levels, as described below.

[0256] In one example, the plurality of loops may include a first loop, e.g., an outer loop, for example, in a first nesting level, and a second loop, e.g., an inner loop, for example, in a second nesting level.

[0257] In one example, the plurality of loops may include one or more intermediate loops, for example, in one or more intermediate nesting levels, for example, between the first nesting level and the second nesting level.

[0258] In one example, the plurality of loops may include three loops at three nesting levels. For example, the three loops may include a first loop, e.g., an outermost loop, at a first nesting level, a second loop, e.g., an intermediate loop, at a second nesting level, and a third loop, e.g., an innermost loop, at a third nesting level. For example, the second loop may be nested within the first loop, and the third loop may be nested within the second loop.

[0259] In some example aspects, the one or more loops based on source code 112, for example, may include a plurality of memory access operations.

[0260] In some example aspects, the memory access operations may include load operations and / or store operations. In other aspects, the memory access operations may include any other suitable type of memory access operations.

[0261] In some example aspects, compiler 160 may configure one or more AGUs to perform the memory access operations, e.g., as described below.

[0262] In some exemplary aspects, e.g., in some use cases, implementations, and / or scenarios, the memory access operations may require a certain number of AGUs, while an available number of AGUs of a target processor, e.g., a vector processor, may be limited.

[0263] In one example, the loops may include code, such as OpenCL program code and / or other code, that may include many loads and / or stores, while the vector processor may have only a relatively small number of available AGUs.

[0264] In some exemplary aspects, it may be necessary to provide a technical solution to handle a large number of memory access operations, for example in situations where the number of memory access operations exceeds the number of available AGUs, as described below.

[0265] In some exemplary aspects, such as in some use cases, implementations, and / or scenarios, a plurality of memory access operations may be performed with respect to the same memory pointer and different offsets.

[0266] For example, an implementation that uses a different AGU for each memory access operation with a different offset may result in a relatively high number of AGUs required, e.g., to process the large number of memory access operations. For example, the number of available AGUs may be limited, e.g., less than the required number of AGUs.

[0267] For example, in some exemplary aspects, compiler 160 may be configured to compile source code 112 of an executing program to be executed on a target processor, such as a vector processor 180, that includes a limited number of AGUs. For example, the vector processor may include four AGUs or any other number of AGUs.

[0268] For example, based on source code 112, compiler 160 may identify a loop nest that includes five memory access operations, such as the following: Example (4)

[0269] Example 4 shows that the loop nest can include an outer loop (y-loop) along a dimension (Y-dimension) based on a variable height and an inner loop (x-loop) along a dimension (X-dimension) based on a variable width.

[0270] Example 4 shows that the loop nest can include a store out[index] and a load inp2[index], which may require two AGUs.

[0271] Example 4 shows that the loop nest can include three loads to the same memory pointer, denoted as inp1, e.g., with different offsets.

[0272] Example 4 shows that the loop nest can include a first load, e.g., inp1[index], to the memory pointer inp1 with a first offset, e.g., index; a second load, e.g., inp1[index+width], to the memory pointer inp1 with a second offset, e.g., index+width; and a third load, e.g., inp1[index+2*width], to the memory pointer inp1 with a third offset, e.g., index+2*width.

[0273] It will now Fig. 4, which schematically illustrates a memory access scheme 400 for loading data from a memory with respect to a memory pointer, according to some example aspects.

[0274] In one example, memory access scheme 400 may illustrate memory accesses with respect to the same memory pointer, e.g., memory pointer inp1, according to the loop nest of Example 4.

[0275] As in Fig. As shown in Figure 4, the three load operations of Example 4, e.g., inp1[index], inp1[index+width], and inp1[index+2*width], can load data with different respective offsets, e.g., the offsets index, index+width, and index+2*width.

[0276] As in Fig. 4, the three loads of Example 4 can load the data with the different offsets with respect to the same memory pointer inp1, for example, in the same Y dimension, for example, with the same difference in the Y dimension, for example, with offsets 0, 1 and 2 (*width).

[0277] For example, an implementation that requires the use of a different AGU for each memory access with a different offset may require a total of 5 AGUs to process the memory access operations of Example 4. For example, a first AGU may be used to process the store operation out[index], a second AGU may be used to process the load operation inp2[index], and three additional AGUs may be used to process the three respective load operations with respect to the memory pointer inp1, e.g., the operations inp1[index], inp1[index+width], and inp1[index+2*width]. According to this example, a target processor may not be able to process the memory access operations of Example 4, e.g., if the number of available AGUs of the target processor is less than 5.

[0278] Referring to Fig. 1, compiler 160 may be configured, in some example aspects, to generate target code 115, which may be configured, for example, to use AGUs of a target processor, e.g., vector processor 180, according to an AGU configuration scheme, e.g., as described below.

[0279] In some example aspects, the AGU configuration scheme may be configured to provide a technical solution to support the configuration of the same AGU, for example, to perform a plurality of memory access operations to the same memory pointer, for example, with different offsets, as described below.

[0280] In some exemplary aspects, the AGU configuration scheme may be configured to provide a technical solution to support the implementation of multiple data accesses, for example, using a reduced number of AGUs, for example, in zero-overhead loops and / or any other type of loops, as described below.

[0281] In some example aspects, the AGU configuration scheme may be configured to utilize at least one additional dimension of an AGU, for example, to process a plurality of memory access operations, as described below.

[0282] In some example aspects, the AGU configuration scheme may be configured to use a time-shifting scheme, for example, to process a plurality of memory access operations, as described below.

[0283] In some example aspects, the time-shifting scheme may be configured to provide a technical solution for storing a history of loads, for example, to process the plurality of memory access operations, as described below.

[0284] In some example aspects, the AGU configuration scheme may be configured to utilize the additional AGU dimension and / or the time shifting scheme, for example, to provide a technical solution that supports hopping across different memory access operations, e.g., load and / or store operations, as described below.

[0285] In some exemplary aspects, the AGU configuration scheme may be configured to swap between two loop dimensions, e.g., when determined to be necessary, such as when using the time-shifting scheme as described below.

[0286] In some exemplary aspects, the AGU configuration scheme may be configured to provide a technical solution to support a configuration, e.g., even an arbitrary configuration, of memory accesses to the same memory pointer with different offsets, as described below.

[0287] In some example aspects, the AGU configuration scheme may be configured to provide a technical solution to support a configuration, e.g., even an arbitrary configuration, of load and / or store operations where the offsets of the memory accesses to the same memory pointer may change in up to 2 dimensions, e.g., as described below.

[0288] From other perspectives, the AGU configuration scheme may be configured to support a configuration of memory access operations with offset changes in more than two dimensions, e.g., if supported by the AGU.

[0289] In some example aspects, compiler 160 may be configured to identify a plurality of memory access operations in a loop, for example, based on source code 112 to be compiled into target code 115 to be executed by a target processor 180, as described below.

[0290] In some example aspects, compiler 160 may be configured to generate target code 115 configured, for example, for execution by a target vector processor, such as vector processor 180, as described below.

[0291] In some example aspects, compiler 160 may be configured to generate target code 115 configured, for example, for execution by a Very Long Instruction Word (VLIW) Single Instruction / Multiple Data (SIMD) target processor, e.g., processor 180.

[0292] In other respects, the compiler 160 may be configured to generate the target code 115 configured, for example, for execution by another suitable processor type.

[0293] In some example aspects, the compiler 160 may be configured to generate the target code 115, for example, based on the source code 112 that includes Open Computing Language (OpenCL) code.

[0294] In other aspects, the compiler 160 may be configured to generate the target code 115 based on, for example, the source code 112 including another suitable type of code.

[0295] In some example aspects, the compiler 160 may be configured to compile the source code 112 into the target code 115, for example, according to a Low Level Virtual Machine (LLVM)-based (LLVM-based) compilation scheme.

[0296] In other aspects, the compiler 160 may be configured to compile the source code 112 into the target code 115 according to any other suitable compilation scheme.

[0297] In some example aspects, the compiler 160 may be configured to identify the plurality of memory access operations in the loop in the source code 112, e.g., in the event that the loop is enclosed in the source code 112.

[0298] In some example aspects, the compiler 160 may be configured to identify the plurality of memory access operations in the loop in the code, e.g., middle-end code or any other code that can be compiled from the source code 112.

[0299] In some example aspects, the plurality of memory access operations may include a plurality of load operations, e.g., as described below. In other aspects, the plurality of memory access operations may include any other type of memory access operations.

[0300] In some example aspects, the plurality of memory access operations may include at least a first memory access operation and a second memory access operation to the same memory pointer, as described below.

[0301] In some example aspects, the first memory access operation may include a first offset, as described below.

[0302] In some example aspects, the second memory access operation may have a second offset that is different from the first offset, for example, as described below.

[0303] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code to configure the plurality of memory access operations by the same AGU, as described below.

[0304] In some example aspects, the compiler 160 may be configured to generate the target code 115 based, for example, on compiling the source code 112, as described below.

[0305] In some example aspects, the compiler 160 may be configured to generate the target code 115 based on, for example, the AGU configuration code, as described below.

[0306] In some exemplary respects, the target code 115 may include some or all of the AGU configuration code.

[0307] In other aspects, the target code 115 may be generated, for example, based on further processing and / or compiling the AGU configuration code.

[0308] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code to configure the plurality of memory access operations, for example, based on a dimension of the loop, as described below.

[0309] In some example aspects, the first offset may include a first integer multiple of the dimension of the loop, e.g., as described below.

[0310] In some example aspects, the second offset may include a second integer multiple of the dimension of the loop, e.g., as described below.

[0311] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code to configure the plurality of memory access operations, for example, based on a difference between the first offset and the second offset, for example, as described below.

[0312] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code to configure the plurality of memory accesses based on the difference between the first offset and the second offset, for example, based on a determination that the difference between the first offset and the second offset is independent of a dimension of the loop, as described below.

[0313] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to configure a first dimension of the AGU, for example, based on the dimension of the loop, as described below.

[0314] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to configure the first dimension of the AGU based on the dimension of the loop, for example, based on a determination that the difference between the first offset and the second offset is based on an integer multiple of the dimension of the loop, and that the difference between the first offset and the second offset is based on a dimension-independent value that may be independent of the dimension of the loop, for example, as described below.

[0315] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code to configure a second dimension of the AGU, for example, based on the independent value, as described below.

[0316] In some example aspects, the plurality of memory access operations may include a third memory access operation to the same memory pointer, as described below.

[0317] In some example aspects, the third memory access operation may have a third offset that is different from the first offset and the second offset, as described below.

[0318] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to configure the plurality of memory accesses by the same AGU, for example, based on the third offset, as described below.

[0319] In some example aspects, the loop may include a first loop, e.g., as described below.

[0320] In some exemplary aspects, the first loop may be nested within a second loop, e.g., as described below.

[0321] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code, for example, based on the second loop, e.g., as described below.

[0322] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code, for example, to include first dimension code to configure a first dimension of the AGU, for example, based on the first loop, as described below.

[0323] In some example aspects, compiler 160 may be configured to configure the AGU configuration code, for example, to include second dimension code to configure a second dimension of the AGU, for example, based on the plurality of memory accesses, for example, as described below.

[0324] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code, for example, to include third dimension code to configure a third dimension of the AGU, for example, based on the second loop as described below.

[0325] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code, for example, to include a loop swap instruction that may be configured to instruct a loop swap between a dimension of the AGU corresponding to the first loop and a dimension of the AGU corresponding to the second loop, as described below.

[0326] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to include a loop swap instruction, for example, based on a determination that the difference between the first offset and the second offset is based on a dimension of the second loop, as described below.

[0327] In some example aspects, the AGU configuration code may include code to configure the same AGU, for example, according to an additional dimension configuration scheme as described below.

[0328] In some exemplary aspects, compiler 160 may be configured to configure the AGU configuration code to include code to configure the same AGU, for example, according to the additional dimension configuration scheme as described below.

[0329] In some example aspects, the additional dimension configuration scheme may be configured to configure an additional dimension of the AGU, for example, based on the plurality of memory access operations, as described below.

[0330] For example, in some example aspects, the AGU configuration code may include the first dimension code to configure a first dimension of the AGU, for example, based on the loop as described below.

[0331] In some example aspects, the AGU configuration code may include second dimension code to configure an additional dimension of the AGU, e.g., a second dimension of the AGU, for example, based on the plurality of memory accesses, e.g., as described below.

[0332] For example, the first dimension code may configure a plurality of first dimensions of the AGU, e.g., including an x-dimension and / or a y-dimension, e.g., based on the loop; and / or the second dimension code may configure a second, e.g., additional, dimension of the AGU, e.g., a z-dimension, e.g., based on the plurality of memory access operations, e.g., as described below.

[0333] In some example aspects, compiler 160 may be configured to configure the first dimension code to set a count parameter of the first dimension of the AGU, for example, based on a count parameter of the loop, as described below.

[0334] In some example aspects, compiler 160 may be configured to configure the first dimension code to set a step parameter of the first dimension of the AGU, for example, based on a step parameter of the loop, as described below.

[0335] In some example aspects, compiler 160 may be configured to configure the second dimension code to determine a count parameter of the second dimension of the AGU, for example, based on a total number of memory accesses in the plurality of memory accesses, as described below.

[0336] In some example aspects, compiler 160 may be configured to configure the second dimension code to set a step parameter of the second dimension of the AGU, for example, based on the difference between the first offset and the second offset, as described below.

[0337] In some exemplary aspects, the compiler 160 may be configured to generate loop code, for example, based on the loop as described below.

[0338] In some example aspects, compiler 160 may be configured to generate target code 115, for example, based on the loop code as described below.

[0339] In some example aspects, the loop code may include a plurality of memory access instructions to be executed, for example, by the same AGU, as described below.

[0340] In some example aspects, the plurality of memory access instructions may each correspond to the plurality of memory access operations as described below.

[0341] In some example aspects, the plurality of memory access operations may include a third memory access operation to the same memory pointer, as described below.

[0342] In some example aspects, the third memory access operation may have a third offset that is different from the first and second offsets, for example, as described below.

[0343] In some example aspects, compiler 160 may be configured to generate the loop code including first, second, and third memory access instructions executed by the same AGU, for example, based on the first, second, and third memory access instructions, respectively, as described below.

[0344] For example, in some example aspects, the target code 115 may be based on the loop code that includes the first, second, and third memory access instructions executed by the same AGU, as described below.

[0345] In some example aspects, compiler 160 may be configured to, for example, detect that a first difference between the first offset and the second offset is equal to a second difference between the second offset and the third offset, as described below.

[0346] In some example aspects, compiler 160 may be configured to configure the second dimension of the AGU, for example, based on the second difference, for example, based on a determination that the first difference is equal to the second difference, as described below.

[0347] In some example aspects, the loop may include a first loop, such as an inner loop, as described below.

[0348] In some example aspects, the first loop may be nested within a second loop, e.g., an outer loop, as described below.

[0349] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code to include third dimension code to configure a third dimension of the AGU, for example, based on the second loop as described below.

[0350] In some example aspects, compiler 160 may be configured to selectively configure the AGU configuration code based on the plurality of memory accesses, for example, based on one or more conditions as described below.

[0351] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code based on the plurality of memory accesses, for example, based on a determination that a number of dimensions of the first loop is less than a number of dimensions supported by the same AGU, as described below.

[0352] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code based on the plurality of memory accesses, for example, based on a determination that the plurality of memory accesses have no boundaries and no passes, as described below.

[0353] In some example aspects, compiler 160 may be configured to configure the AGU configuration code based on the plurality of memory accesses, for example, based on a determination that the differences between consecutive offsets of the plurality of memory accesses are the same, as described below.

[0354] In some example aspects, compiler 160 may be configured to configure the AGU configuration code based on the plurality of memory accesses, for example, based on a determination that the number of dimensions of the first loop is less than a number of dimensions supported by the same AGU, that the plurality of memory accesses have no boundaries and no passes, and / or that the differences between consecutive offsets of the plurality of memory accesses are the same, e.g., as described below.

[0355] In other aspects, the compiler 160 may be configured to configure the AGU configuration code based on the plurality of memory access operations, for example, based on any other additional and / or alternative conditions and / or criteria.

[0356] In some example aspects, the AGU configuration code may include code to configure the same AGU, for example, according to a time-shifting scheme, as described below.

[0357] In some exemplary aspects, compiler 160 may be configured such that the AGU configuration code includes code to configure the same AGU, for example, according to the time-shifting scheme as described below.

[0358] In some example aspects, the time-shifting scheme may be configured to implement the plurality of memory accesses, for example, as a plurality of time-shifted memory accesses of the same AGU, for example, during a plurality of respective loop iterations, as described below.

[0359] In some exemplary aspects, the compiler 160 may be configured to configure the AGU configuration code to include a loop swap instruction for a dimension of the AGU corresponding to the loop, as described below.

[0360] In some example aspects, the loop swap instruction may be configured to instruct a loop swap, for example, between the dimension of the AGU corresponding to the loop and another dimension of the AGU corresponding to an outer loop, as described below.

[0361] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code to include the loop swap instruction for the dimension of the AGU corresponding to the loop, for example, based on a determination that a difference between the first offset and the second offset is based, for example, on a dimension of another loop, for example, the outer loop enclosing the loop including the plurality of memory accesses, for example, as described below,

[0362] In some example aspects, compiler 160 may be configured to configure the loop swap instruction to cause a loop swap between the dimension of the AGU corresponding to the loop and another dimension of the AGU corresponding to the other loop, e.g., the outer loop, e.g., as described below.

[0363] In some example aspects, compiler 160 may be configured to selectively use the loop swap instruction based on one or more conditions, e.g., as described below.

[0364] In some example aspects, compiler 160 may be configured to selectively use the loop swap instruction, for example, based on a determination that the plurality of memory accesses are not in the inner loop, for example, as described below.

[0365] In some example aspects, compiler 160 may be configured to selectively use the loop swap instruction, for example, based on a determination of whether or not differences between offsets of the plurality of memory accesses are based on a dimension of an inner loop, as described below.

[0366] In some example aspects, compiler 160 may be configured to use the loop swap instruction, for example, based on a determination that the differences between the offsets of the plurality of memory accesses are based on a dimension of another loop, e.g., an outer loop.

[0367] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code, e.g., according to the time-shifting scheme, to, for example, specify a same count parameter for all AGUs to perform memory access operations during the loop, as described below.

[0368] In some example aspects, the same count parameter may be based on, for example, a count parameter of the loop, a maximum offset of the plurality of memory accesses, and / or a minimum offset of the plurality of memory accesses, as described below.

[0369] From other perspectives, the same counting parameter may be configured based on any other additional or alternative parameter and / or criterion.

[0370] In some exemplary aspects, compiler 160 may be configured to configure the AGU configuration code, e.g., according to the time-shifting scheme, to set, for example, the same counting parameter, denoted as Count, as follows: Count=AlignUpTo((MaxXOffset−MinXOffset)+Count(Loop), VF) / VF where MaxXOffset denotes the maximum offset of the plurality of memory access operations, where MinXOffst denotes the minimum offset of the plurality of memory access operations, where VF denotes a vectorization factor, where Count(Loop) denotes the counting parameter of the loop, and where the operation AlignUpTo(a,b) a can align to an integer multiple of b.

[0371] In some example aspects, the compiler 160 may be configured to generate loop code based on the loop and pre-header code to be executed before a header of the loop code, e.g., as described below.

[0372] In some example aspects, the compiler 160 may be configured to generate the pre-header code, for example, when generating the AGU configuration code according to the time-shifting scheme, e.g., as described below.

[0373] For example, the pre-header code for all AGU-based implementations of arbitrary loops can be generated in the loop, for example, to set AGU parameters, for example, when generating the AGU configuration code according to the time-shifting scheme, as described below.

[0374] In some example aspects, the target code 115 may be based on the loop code and / or the pre-header code, as described below.

[0375] In some exemplary aspects, the pre-header code may include a plurality of AGU load instructions executed by the same AGU, as described below.

[0376] For example, in some example aspects, a number of AGU load instructions in the plurality of AGU load instructions may be based on a number of memory accesses in the plurality of memory accesses, as described below.

[0377] For example, in some example aspects, the number of AGU load instructions in the plurality of AGU load instructions may be equal to the number of memory accesses in the plurality of memory accesses, as described below.

[0378] From other perspectives, any other suitable number of AGU load instructions may be used.

[0379] In some example aspects, compiler 160 may be configured to include loop code that includes a plurality of store instructions that may be configured to store results of a corresponding plurality of AGU loading iterations by the same AGU, e.g., as described below.

[0380] In some example aspects, a number of the plurality of memory instructions may be based, for example, on the number of memory accesses in the plurality of memory accesses, as described below.

[0381] For example, in some example aspects, the number of the plurality of memory instructions may be equal to the number of memory accesses in the plurality of memory accesses, as described below.

[0382] From other points of view, any other suitable number of memory instructions may be used.

[0383] In some example aspects, compiler 160 may be configured to generate the plurality of store instructions, which may be configured to cause target processor 180 to store a plurality of load results of the plurality of AGU load instructions in pre-header code, for example, in a first-in-order iteration of the plurality of AGU load iterations, as described below.

[0384] In some example aspects, compiler 160 may be configured to selectively configure the AGU configuration code to include code to configure the same AGU according to the time shifting scheme, for example, based on one or more conditions as described below.

[0385] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to include code to configure the same AGU according to the time-shifting scheme, for example, based on a determination that the plurality of memory access operations include only load operations, as described below.

[0386] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to include code to configure the same AGU according to the time-shifting scheme, for example, based on a determination that differences between consecutive offsets of the plurality of memory accesses are independent of the dimension of the loop, as described below.

[0387] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to include code to configure the same AGU according to the time-shifting scheme, for example, based on a determination that the plurality of memory accesses have no boundaries and / or no passes, as described below.

[0388] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to include code to configure the same AGU according to the time-shifting scheme, for example, based on a determination that the plurality of memory accesses are not masked, as described below.

[0389] In some example aspects, the compiler 160 may be configured to configure the AGU configuration code to include code to configure the same AGU according to the time-shifting scheme, for example, based on a determination that the loop does not include side effects, as described below.

[0390] In some example aspects, compiler 160 may be configured to configure the AGU configuration code to include code to configure the same AGU according to the time-shifting scheme, for example, based on a determination that the plurality of memory accesses include only loads, that the differences between consecutive offsets of the plurality of memory accesses are independent of the dimension of the loop, that the plurality of memory accesses have no boundaries and no passes, that the plurality of memory accesses are not masked, and / or that the loop does not include any side effects, e.g., as described below.

[0391] In other aspects, the compiler 160 may be configured to configure the AGU configuration code to include code to configure the same AGU according to the time shifting scheme, for example, based on any other additional and / or alternative condition and / or criteria.

[0392] In some exemplary aspects, compiler 160 may be configured to compile a loop nest based on source code 112, e.g., the loop of Example 4, for example, according to an AGU configuration scheme as described below.

[0393] In some example aspects, the compiler 160 may be configured to generate AGU configuration code of the loop, e.g., the loop of Example 4, to provide, for example, a technical solution to support the memory access operations of Example 4, e.g., with a reduced number of AGUs, as described below.

[0394] In some example aspects, the compiler 160 may be configured to compile the source code 112 according to, for example, an additional dimension configuration scheme as described below.

[0395] In some example aspects, the compiler 160 may be configured to determine whether to compile the source code 112 according to the additional dimension configuration scheme, for example, based on one or more predefined conditions, as described below.

[0396] In some example aspects, the one or more predefined conditions may include a first condition that may be based, for example, on a number of dimensions of the loop nest.

[0397] In some example aspects, compiler 160 may be configured to determine whether the loop nest based on the source code 112 can be compiled according to the configuration scheme with additional dimensions, for example, based on a condition related to a number of dimensions of the loop nest and a number of supported dimensions that can be supported by an AGU, e.g., any AGU, of the target processor, e.g., vector processor, to execute the target code 115, e.g., as described below.

[0398] In some example aspects, the compiler 160 may be configured to determine that the loop nest based on the source code 112 may be compiled according to the additional dimension configuration scheme, for example, based on a determination that the number of dimensions of the loop nest is less than the number of supported dimensions of the target processor 180 to execute the target code 115, as described below.

[0399] In one example, an AGU of a processor, e.g., a vector processor, may support four dimensions. According to this example, compiler 160 may be configured to determine whether the loop nest can be compiled based on source code 112 according to the additional dimension configuration scheme, for example, based on a determination of whether the number of dimensions of the loop nest is less than 4, e.g., #LoopDimensions <= 3.

[0400] In some example aspects, one or more of the predefined conditions may include a second condition, which may be based, for example, on differences between offsets of memory accesses to the same memory pointer, as described below.

[0401] In some example aspects, the compiler 160 may be configured to determine whether the loop nest based on the source code 112 can be compiled according to the configuration scheme with additional dimensions, for example, based on a determination of whether or not all differences between offsets of any two consecutive memory accesses to the same pointer are equal, as described below.

[0402] In one example, two consecutive memory accesses may include operations that are consecutive with respect to offsets, for example, when the memory accesses are sorted by their offsets.

[0403] In some example aspects, compiler 160 may be configured to determine that the loop nest may be compiled based on source code 112 according to the additional dimension configuration scheme, for example, based on a determination that the differences between the offsets of consecutive memory accesses, e.g., every two consecutive memory accesses, are the same.

[0404] In some example aspects, one or more of the predefined conditions may include a third condition, which may be based, for example, on limits of memory accesses to the same memory pointer.

[0405] In some example aspects, the compiler 160 may be configured to determine that the loop nest based on the source code 112 may be compiled according to the configuration scheme with additional dimension, for example, based on a determination that all bounds, e.g., with any pass, are the same for all memory accesses to the same memory pointer, e.g., as described below.

[0406] In some example aspects, some or all of the conditions may be implemented to determine whether the additional dimension configuration scheme can be applied to the loop nest, and / or other additional conditions, rules, and / or criteria may be implemented to determine whether the additional dimension configuration scheme can be applied to the loop nest.

[0407] From some exemplary perspectives, compiler 160 can identify the three loads for the same memory pointer inp1 with the different offsets, e.g., the loads inp1[index], inp1[index + width], and inp1[index + 2 * width], based on the loop nest of Example 4.

[0408] In some exemplary aspects, compiler 160 may be configured to check whether the three loads into the same memory pointer have the same steps, e.g., in all loops of the loop nest of Example 4. For example, compiler 160 may check whether all three loads inp1[index], inp1[index + width], and inp1[index + 2 * width] have the same steps in the inner loop X, e.g., Step(X-Loop) = VectorSize, and in the outer loop Y, e.g., Step(Y-Loop) = width.

[0409] In some exemplary aspects, compiler 160 may be configured to detect that the offsets of the three loads inp1[index], inp1[index + width], and inp1[index + 2 * width] are different in the Y dimension. For example, compiler 160 may be configured to detect that the load inp1[index] has an offset of 0 (*width) in the Y dimension, the load inp1[index + width] has an offset of 1 (*width) in the Y dimension, and the load inp1[index + 2 * width] has an offset of 2 (*width) in the Y dimension.

[0410] In some exemplary aspects, the compiler 160 may be configured to use a non-swapped looping scheme to compile the loop nest of Example 4 in which the outer loop Y remains the outermost loop and the inner loop X remains the innermost loop, as described below.

[0411] In some example aspects, compiler 160 may be configured to use the non-swapped loop scheme, for example, based on a selection to compile the loop nest of Example 4 according to the additional dimension configuration scheme, as described below.

[0412] In some exemplary aspects, the compiler 160 may be configured to check whether the predefined conditions for implementing the additional dimension configuration scheme are met with respect to the loop nest of Example 4, as described below.

[0413] In some exemplary aspects, the compiler 160 may be configured to check whether the number of dimensions of the loop nest of Example 4 is less than four, e.g., the number of AGU dimensions supported by the AGU.

[0414] In some exemplary respects, the compiler 160 may be configured to check whether the differences between the offsets of the three loads are the same.

[0415] In some exemplary aspects, the compiler 160 may be configured to check that the plurality of memory access operations have no boundaries and no passes, that is, that all boundaries of the three load operations are the same.

[0416] In some exemplary aspects, compiler 160 may determine that the predefined conditions regarding the loop nest of Example 4 are met, for example, by determining that the number of dimensions of the loop, e.g., two loops, satisfies the condition for the number of dimensions, e.g., #Ioop-dimensions = 2 <= 3.

[0417] In some exemplary respects, compiler 160 may determine that the predefined conditions are met with respect to the loop nest of Example 4, for example, by determining that the differences between the offsets are all equal to 1 (*width), e.g., differences between the offsets (1 - 0 = 2 - 1 = 1).

[0418] In some exemplary aspects, compiler 160 may determine that the predefined conditions are met with respect to the loop nest of Example 4, for example, by determining that there are no boundaries or passes in the plurality of memory accesses of the loop nest.

[0419] In some example aspects, the compiler 160 may be configured to compile the source code 112 according to, for example, the additional dimension configuration scheme, for example, based on determining that all preconditions for the additional dimension configuration scheme are met.

[0420] In some exemplary aspects, the compiler 160 may be configured to specify AGU configuration code for the AGU, for example, according to the additional dimension configuration scheme as described below.

[0421] In some example aspects, compiler 160 may be configured to determine a count parameter of the additional dimension, for example, based on the total number of memory accesses.

[0422] For example, Compiler 160 can recognize that the loop nest of Example 4 includes the three loads inp1[index], inp1[index + width], and inp1[index + 2 * width]. Accordingly, Compiler 160 can set the count parameter for the extra dimension to three, e.g., Count(Extra-dim) = #AccesseslnTheGroup = 3.

[0423] In some exemplary aspects, compiler 160 may be configured to determine a step parameter of the additional dimension of the AGU, for example, based on the difference between the offsets.

[0424] For example, compiler 160 may detect that the difference between consecutive offsets of the three loads is equal to 1 (*width), as described above. Accordingly, compiler 160 may set the step parameter of the extra dimension of the AGU to 1 * width, e.g., Step(Extra-dim) = DifferenceBetween2ClosestOffsets * Stride = 1 * width.

[0425] In some exemplary aspects, the compiler 160 may be configured to generate AGU configuration code and loop code for the loop nest of Example 4, for example, according to the additional dimension configuration scheme, e.g.wie folgt: AGU-Konfigurationscode: agu1 = allocate_agu("load' / ; set_base(agu1, inp1); set_y_minmax(agu1, 0, (height - 2) * width); set_y_count_stride(agu1, height - 2, width); set_x_minmax(agu1, 0, width); VectorizationFactor = 32; Xcount = AlignUpTo(width, VectorizationFactor) / VectorizationFactor; VectorSize = VectorizationFactor * 1; set_x_count_stride(agu1, Xcount, VectorSize); set_z_count_stride(agu1, 3, width); agu2 = allocate_agu("load' / ; set_base(agu2, inp2); set_y_minmax(agu2, 0, (height - 2) * width); set_y_count_stride(agu2, height - 2, width); set_x_minmax(agu2, 0, width); set_x_count stride(agu2, Xcount, VectorSize); agu_out = allocate_agu("store"); set_base(agu_out, out); set_y_minmax(agu_out, 0, (height - 2) * width); set_y_count_stride(agu_out, height - 2, width); set x minmax(agu_out, 0, width); set_x_count_stride(agu_out, Xcount, VectorSize); Schleife: %val0 = agu1.load(); agu1.bump(); %val1 = agu1.load(); agu1.bump(); %val2 = agu1.load(); agu1.bump(); %val_inp2 = agu2.load(); agu2.bump(); %temp = mul %val0, %val1; %temp1 = add %temp, val2; %result = sub %temp1, %val_inp2; agu_out.store(%result); agu_out.bump(); br(Loop);. Example (5)

[0426] In some example aspects, as shown in Example 5, the AGU configuration code for agu1 may include an AGU configuration code for an additional dimension, e.g., dimension z.

[0427] In some example aspects, as illustrated in Example 5, the additional dimension z may be configured, for example, in addition to the dimension x, which may be configured based on the X-loop, and the dimension y, which may be configured based on the Y-loop.

[0428] In some example aspects, the AGU configuration code for agu1 may include AGU configuration code, e.g., set_z_count_stride(agu1, 3, width) to, for example, set the count parameter for dimension z to three, e.g., "3".

[0429] From some example perspectives, the AGU configuration code for agu1 may include AGU configuration code, e.g., set_z_count_stride(agu1, 3, width), to set the stride parameter (stride) for dimension z to 1*width, e.g., width.

[0430] From some exemplary perspectives, as shown in Example 5, the loop code may include three load instructions for the same pointer, e.g., agu1, which may correspond to the three loads, e.g., as follows: %val0 = agu1.load(); agu1.bump(); %vall = agu1.load(); agu1.bump(); %val2 = agu1.load(); agu1.bump();

[0431] For example, the instruction %val0 = agu1.load(); agu1.bump() can be configured to store in register %val0 a value loaded by agu1 in a first iteration over dimension z, e.g., corresponding to the load operation inp1[index].

[0432] For example, the instruction %val1 = agu1.load(); agu1.bump() can be configured to store in register %val1 a value loaded by agu1 in a second iteration over dimension z, e.g., corresponding to the load inp1[index + width].

[0433] For example, the instruction %val2 = agu1.load(); agu1.bump() can be configured to store in register %val2 a value loaded from agu1 in a third iteration over dimension z, e.g., corresponding to the load inp1[index + 2 * width].

[0434] In some example aspects, compiler 160 may be configured to compile source code 112 according to, for example, a time-shifting scheme, as described below.

[0435] In some example aspects, the compiler 160 may be configured to determine whether to compile the source code 112 according to the time-shifting scheme, for example, based on one or more predefined conditions, as described below.

[0436] In some example aspects, the one or more predefined conditions may include a first condition that may require that the time-shifting scheme may be applied, for example, only with respect to load operations, e.g., not for store operations.

[0437] In some example aspects, the one or more predefined conditions may include a second condition that may require that a dimension encompassing the loads to be compiled according to the time-shifting scheme ("the time-shifted dimension") should be or may become a dimension of an innermost loop of the loop nest.

[0438] In some exemplary aspects, the time-shifting scheme may, for example, include a loop swap instruction where possible, for example, in case the time-shifted dimension is not already the dimension of the innermost loop of the loop nest.

[0439] In some example aspects, one or more predefined conditions may include a third condition, which may be based, for example, on differences between offsets of memory accesses to the same memory pointer, as described below.

[0440] In some example aspects, the compiler 160 may be configured to determine whether the loop nest based on the source code 112 can be compiled according to the time-shifting scheme, for example, based on a determination of whether differences between offsets of any two, e.g., consecutive and / or non-consecutive, memory accesses to the same pointer are constant, e.g., known at compile time and / or do not change during execution time.

[0441] In some example aspects, the compiler 160 may be configured to determine that the loop nest based on the source code 112 may be compiled according to the time-shifting scheme, for example, based on a determination that the differences between the memory access offsets are constant, e.g., known at compile time.

[0442] In some example aspects, one or more of the predefined conditions may include a fourth condition, which may be based, for example, on the boundaries of memory accesses to the same pointer.

[0443] In some example aspects, the compiler 160 may be configured to determine that the loop nest based on the source code 112 can be compiled according to the time-shifting scheme, for example, based on a determination that all constraints (bounds), e.g., with any pass, can match the same pointer for all memory accesses, as described below.

[0444] In some exemplary aspects, one or more predefined conditions may include a fifth condition relating to side effects of the loop nest.

[0445] For example, compiler 160 may be configured to determine that the time-shifting scheme may be applied to the loop nest, for example, based on a determination that the loop nest does not include one or more particular side effects, for example, only if the loop nest does not include one or more particular side effects.

[0446] In some example aspects, one or more predefined conditions may include a sixth condition related to masking the loads in the loop nest.

[0447] For example, compiler 160 may be configured to determine that the time-shifting scheme can be applied to the loop nest, for example, based on a determination that the loads in the loop nest are not masked, that is, only if the loads in the loop nest are not masked.

[0448] In some example aspects, some or all of the conditions may be implemented to determine whether or not the time-shifting scheme may be applied to the loop nest, and / or any other additional conditions, rules, and / or criteria may be implemented to determine whether the time-shifting scheme may be applied to the loop nest.

[0449] From some exemplary perspectives, compiler 160 can identify the three loads for the same memory pointer inp1 with the different offsets, e.g., the loads inp1[index], inp1[index + width], and inp1[index + 2 * width], based on the loop nest of Example 4.

[0450] From some exemplary perspectives, compiler 160 may be configured to check whether the three loads into the same memory pointer have the same steps in all loops of the loop nest of Example 4. For example, compiler 160 may check whether all three loads inp1[index], inp1[index + width], and inp1[index + 2 * width] have the same steps in the inner loop X, e.g., Step(X-Loop) = VectorSize, and in the outer loop Y, e.g., Step(Y-Loop) = width.

[0451] In some exemplary aspects, compiler 160 may be configured to detect that the offsets of the three loads inp1[index], inp1[index + width], and inp1[index + 2 * width] are different in the Y dimension. For example, load inp1[index] has an offset of 0 (*width) in the Y dimension, load inp1[index + width] has an offset of 1 (*width) in the Y dimension, and load inp1[index + 2 * width] has an offset of 2 (*width) in the Y dimension.

[0452] In some exemplary aspects, the compiler 160 may be configured to check whether the predefined conditions for implementing the time-shifting scheme are met with respect to the loop nest of Example 4.

[0453] In some exemplary respects, compiler 160 may be configured to check whether all three memory access operations of Example 4 are load operations.

[0454] From some exemplary perspectives, compiler 160 may be configured to check whether the differences between the offsets of the three loads of Example 4 are constant.

[0455] From some exemplary perspectives, compiler 160 may be configured to check whether the boundaries of the three loads of Example 4 are equal.

[0456] From some exemplary perspectives, compiler 160 may be configured to check that the loop nest of Example 4 does not include any side effects.

[0457] From some exemplary perspectives, compiler 160 may be configured to check that the three loads of Example 4 are not masked.

[0458] In some example aspects, compiler 160 may be configured to compile source code 112 according to the time-shifting scheme, for example, based on determining that all preconditions for the time-shifting scheme are met.

[0459] In some exemplary respects, compiler 160 may be configured to determine whether loop swapping is required and / or possible for the loop nest.

[0460] In some exemplary respects, compiler 160 may determine that the loop swap is required, for example, based on a determination that the time shift is to be performed on the Y dimension, which is not originally a dimension of the innermost loop.

[0461] Under some exemplary aspects, compiler 160 may determine that loop swapping is possible, for example, based on a determination that the loop nest encloses a perfect loop nest and there are no side effects in the loop nest.

[0462] In some example aspects, compiler 160 may be configured to set AGU configuration code for the plurality of AGUs of the target processor, e.g., processor 180, to set, for example, an AGU configuration, e.g., a vertical time shifting (“ShortColumn”) configuration, which may indicate that the time shifting scheme is to be implemented, e.g., as described below.

[0463] In some example aspects, compiler 160 may be configured to specify a same count parameter, denoted as Count(Dim), in the time-shifted dimension, e.g., the Y dimension, for the entire plurality of AGUs, as described below.

[0464] In some exemplary aspects, compiler 160 may be configured to set the same counting parameter for the deferred dimension, for example, based on a counting parameter of the deferred dimension loop, e.g., the Y dimension, a maximum offset of the three loads to the same memory pointer, and a minimum offset of the three loads, e.g., as follows: Count(Ydim)=(MaxYOffset−MinYOffset)+Count(LoopYDim) where MaxYOffset denotes a maximum offset in the time-shifted dimension, e.g., the Y dimension, across all three loads covered by the AGU, and where MinYOffst denotes a minimum offset in the time-shifted dimension, e.g., the Y dimension, across all loads covered by the AGU.

[0465] In some exemplary aspects, compiler 160 may be configured to set a loop swap instruction, e.g., set_y_innerloop(AGU), to indicate a loop swap for the Y dimension, e.g., for all AGUs of target processor 180, e.g., if the loop swap is required.

[0466] In some example aspects, the compiler 160 may be configured to generate loop code based on the loop and pre-header code to be executed before a header of the loop code, e.g., as described below.

[0467] In some exemplary aspects, compiler 160 may be configured to configure the loop code, e.g., to load only one value within the loop through the same AGU, which is used to implement multiple loads. For example, the loop code may include only one load, as described below.

[0468] In some exemplary aspects, compiler 160 may be configured such that pre-header code for loading initial values ​​is generated by the same AGU, e.g., prior to loop execution. For example, the pre-header code may include a plurality of AGU load instructions executed by the same AGU, e.g., prior to loop execution, as described below.

[0469] In some exemplary aspects, the compiler 160 may be configured to remember and / or retain other values ​​from previous AGU load iterations in the loop, for example, storing them in registers, as described below.

[0470] In some example aspects, a first-in-order iteration of the loop may use values ​​loaded by the pre-header code, such as the initial values, as described below.

[0471] In some exemplary aspects, the compiler 160 may be configured to configure the pre-header code and the loop code for the time-shifting scheme, for example, based on the loads to be performed by the same AGU, for example, as follows: • Add MaxTS loads / bumps to the pre-header of the loop: %p_i = agu.load(); agu.bump(); (0 <= I < MaxTS) • Add the Phi chain of length MaxTS to the loop: %q_i = phi(%p_i: Preheader, %q_(i+1): Loop) (0 <= i < MaxTS) • Add a load and a bump in the loop after the Phi chain: %q_MaxTS = agu.load(); agu.bump(); • Use %q_i (0 <= i <= MaxTS) in the loop, where MaxTS denotes a number of iterations for which results are stored and loaded within the loop, for example, to use the results later. For example, the value of MaxTS can be based on a number of iterations to be performed between a load corresponding to a minimum offset and a load corresponding to a maximum offset of the loads to be performed by the same AGU.

[0472] For example, the value of MaxTS for a value used in a current iteration can indicate how many iterations ago it was loaded from the buffer, e.g., by a load instruction. For example, the value of MaxTS can take the maximum value across all such values. For example, the code %val = phi(%a: label1, %b: label2), e.g., %q_i = phi(%p_i: Preheader, %q_(i+1): Loop) can represent a conditional instruction (also called a "conditional assignment instruction"), where %val receives the value %a, e.g., when the instruction from the code below label1 has been reached, or the value %b, e.g., when the instruction from the code below label2 has been reached.

[0473] From some exemplary perspectives, compiler 160 may be configured to generate AGU configuration code, pre-header code, and loop code for the loop nest of Example 4 according to the time-shifting scheme, e.g.wie folgt: AGU-Konfigurationscode: agu1 = allocate_agu("load"); set_base(agu1, inp1); set_y_minmax(agu1, 0, (height - 2) * width); set_y_count_stride(agu1, height, width); set_y_innerloop(agu1); / / Loop interchange set_x_minmax(agu1, 0, width); VectorizationFactor = 32; VectorSize = VectorizationFactor * 1; xCount = AlignUpTo(width, VectorizationFactor) / VectorizationFactor; set_x_count_stride(agu1, xCount, VectorSize); agu2 = allocate_agu("load"); set_base(agu2, inp2); set_y_minmax(agu2, 0, (height - 2) * width); set_y_count_stride(agu2, height, width); set_y_innerloop(agu2); / / Loop interchange set_x_minmax(agu2, 0, width); set_x_count_stride(agu2, xCount, VectorSize); agu_out = allocate_agu("store"); set_base(agu_out, out); set_y_minmax(agu_out, 0, (height - 2) * width); set_y_count_stride(agu_out, height, width); set_y_innerloop(agu_out); / / Loop interchange set_x_minmax(agu_out, 0, width); set_x_count_stride(agu_out, xCount, VectorSize); Pre-header: %p0 = agu1.load(); agu1.bump(); %p1 = agu1.load(); agu1.bump(); Loop: %q0 = phi(%p0: Pre-header, %q1: Loop); %q1 = phi(%p1: Pre-header, %q2: Loop); %q2 = agu1.load(); agu1.bump(); %val_inp2 = agu2.load(); agu2.bump(); %temp = mul %q0, q1; %temp1 = add temp, %q2; %result = sub %temp1, %val_inp2; agu_out.store(%result); agu_out.bump(); br(Loop);. Example (6)

[0474] In some exemplary aspects, as shown in Example 6, the AGU configuration code may include the loop swap instruction for the Y dimension, for example, for all AGUs.

[0475] For example, as shown in Example 6, the AGU configuration code may include the loop swap command set_y_innerloop(agu1) for agu1, the loop swap command set_y_innerloop(agu2) for agu2, and set_y_innerloop(agu_out) for agu_out.

[0476] In some exemplary aspects, as illustrated in Example 6, the AGU configuration code may include the same counting parameter in the Y dimension for all of a plurality of AGUs.

[0477] For example, as shown in Example 6, the AGU configuration code may include the set_y_count_stride(agu1, height, width) command for agu1, the set_y_count_stride(agu2, height, width) command for agu2, and the set_y_count_stride(agu_out, height, width) command for agu_out.

[0478] For example, as shown in Example 6, the same counting parameter in the Y dimension can be determined based on the counting parameter of the Y loop, the maximum offset of the three loads, and the minimum offset of the three loads, for example, as follows: Count(yDim)=(MaxYOffset−MinYOffset)+Count(LoopYDim)= =(2−0)+(height−2)=height

[0479] For example, in some exemplary aspects, a number of pre-header AGU load instructions may be based on a value of MaxTS, e.g., MaxTS=2.

[0480] For example, as shown in Example 6, the pre-header code may include two pre-header AGU load instructions, e.g., %p0 = agu1.load(); agu1.bump(); and %p1 = agu1.load(); agu1.bump(), executed by the same agu1.

[0481] From some exemplary perspectives, as shown in Example 6, the two pre-header AGU load instructions, e.g., %p0 = agu1.load(); agu1.bump(); and %p1 = agu1.load(); agu1.bump(), can be used to load initial values ​​for the AGU load iterations.

[0482] In some exemplary aspects, as illustrated in Example 6, the loop code may include two conditional assignment instructions, e.g., %q0 = phi(%p0: Preheader, %q1: Loop); %q1 = phi(%p1: Pre-header, %q2: Loop), to assign (store) to a register, for example, the results of the AGU loading iterations by the same agu1, based, for example, on the phi operation.

[0483] In some exemplary aspects, as illustrated in Example 6, the loop code may include a single allocation (store) instruction, e.g., %q2 = agu1.load(); agu1.bump(), to load the results of a current AGU load iteration through the same agu1 and assign them to a register (store them).

[0484] For example, according to the code of Example 6, the pre-header instruction %p0 = agu1.load(); agu1.bump() can be configured to assign (store) a first value to register %p0, which is loaded from agu1, e.g., corresponding to the load inp 1[index].

[0485] For example, according to the code of Example 6, the pre-header instruction %p1 = agu1.load(); agu1.bump() can be configured to assign (store) a second value loaded from agu1 to register %p1, e.g., corresponding to the load inp1[index + width].

[0486] For example, according to the code of Example 6, the loop instruction %q0 = phi(%p0: Pre-header, %q1: Loop) can be configured to assign (store) the first value loaded from agu1 to register %q0, e.g., corresponding to the load inp1[index], for example, in a first-in-order iteration of the loop; or the value from register %q1, e.g., corresponding to the load inp1[index], for example, in a non-first-in-order iteration of the loop, e.g., inp1[index+width] relative to a previous iteration.

[0487] For example, according to the code of Example 6, the loop instruction %q1 = phi(%p1: Pre-header, %q2: Loop) can be configured to assign (store) to register %q1 the second value loaded from agu1, e.g., corresponding to the load inp1[index + width], for example, in a first-in-order iteration of the loop; or the value from register %q2, e.g., corresponding to the load inp1[index + width], for example, in a non-first-in-order iteration of the loop, e.g., inp1[index+2*width] relative to a previous iteration.

[0488] For example, according to the code of Example 6, the loop instruction %q2 = agu1.load(); agu1.bump() can be configured to assign (store) a value to register %q2 that is loaded from agu1 in the current loop, e.g., corresponding to the load inp1[index + 2*width].

[0489] In some exemplary aspects, compiler 160 may be configured to compile source code 112 of another executing program to be executed on a vector processor including a plurality of AGUs, e.g., as described below. For example, the vector processor may include four AGUs.

[0490] For example, based on the source code 112, the compiler 160 may identify a loop nest that includes five memory access operations, e.g., as follows: for(int y = 0; y < height - 2; y++) { for(int x = 0; x < width - 3; x++) { int index = y * width + x; out1[index] = inp1[index] + inp1[index + 2 * width + 3]; out2[index] = inp2[index];}} Example (7)

[0491] Example 7 shows that the loop nest can include an outer loop (y-loop) along a dimension (Y-dimension) based on a variable height and an inner loop (x-loop) along a dimension (X-dimension) based on a variable width.

[0492] Example 7 shows that the loop nest can include two loads for the same memory pointer, denoted as inp1, with different two-dimensional (2D) offsets, e.g., offsets that differ in two dimensions.

[0493] For example, the loop nest may include a first load, e.g., inp1[index], to the memory pointer inp1 with a first 2D offset, e.g., index, which may have an offset of 0 in the Y dimension and an offset of 0 in the X dimension.

[0494] For example, the loop nest may include a second load, e.g., inp1[index + 2 * width + 3], to the memory pointer inp1 with a second 2D offset, e.g., index + 2 * width + 3, which may have an offset of 2 (* width) in the Y dimension and an offset of 3 in the X dimension.

[0495] It will now Fig. 5, which schematically illustrates a memory access scheme 500 for loading data from a memory with respect to a memory pointer, according to some example aspects.

[0496] In one example, the memory access scheme 500 may illustrate memory accesses with respect to the same memory pointer, denoted by inp1, for example, according to the loads of inp 1[index] and inp 1 [index + 2 * width + 3] of Example 7.

[0497] As in Fig. As shown in Figure 5, the two loads of inp1[index] and inp1[index + 2 * width + 3] of Example 7 can load data with different 2D offsets with respect to the same memory inp1.

[0498] As in Fig. As shown in Figure 5, the first load, e.g., inp1[indexl, may have an offset of 0 in the Y dimension and an offset of 0 in the X dimension.

[0499] As in Fig. As shown in Figure 5, the second load, e.g., inp1[index + 2 * width + 3], may have an offset of 2 (* width) in the Y dimension and an offset of 3 in the X dimension.

[0500] For example, an implementation that requires the use of a different AGU for each memory access with a different offset may require a total of 5 AGUs to process the memory access operations of Example 7. For example, a first AGU may be used to process the store operation out1[index], a second AGU may be used to process the store operation out2[index], a third AGU may be used to process the load operation inp2[index], and two additional AGUs may be used to process the two loads with respect to the memory pointer inp1, e.g., inp1[index] and inp1[index + 2 * width + 3]. According to this example, a processor may not be able to process the memory access operations of Example 7, for example, if the number of available AGUs of the processor is less than 5.

[0501] Referring to Fig. 1, compiler 160 may, in some exemplary aspects, be configured to configure the loop nest of Example 7, for example, according to a combination of the extra dimension configuration scheme and the time-shifting scheme, as described below.

[0502] In some exemplary aspects, the additional dimension configuration scheme can be used, for example, to configure the loop nest based on the offset in the Y dimension, e.g., 2 * width, as described below.

[0503] In some exemplary aspects, the time-shifting scheme can be used, for example, to configure the loop nest based on the offset in the X dimension, e.g., +3, as described below.

[0504] From some exemplary perspectives, compiler 160 may identify the two loads into the same memory pointer inp1 with the different 2D offsets, e.g., loads inp1[index] and inp1[index + 2*width + 3], for example, based on the loop nest of Example 7.

[0505] From some exemplary perspectives, compiler 160 may be configured to check whether the two loads into the same memory pointer have the same steps in all loops of the loop nest of Example 7.

[0506] For example, compiler 160 can check whether every two loads inp1[index] and inp1[index + 2*width + 3] in the inner loop X, e.g., Step(X-Loop) = VectorSize, and in the outer loop Y, e.g., Step(Y-Loop) = width, have the same steps.

[0507] In some exemplary respects, compiler 160 may be configured to recognize that the offsets of the operations inp1[index] and inp1[index + 2*width + 3] are different in the Y dimension and in the X dimension.

[0508] For example, the load inp1[index] may have an offset of 0 (*width) in the Y dimension and an offset of 0 in the X dimension; and the load inp1[index + 2*width + 3] may have an offset of 2 (*width) in the Y dimension and an offset of 3 in the X dimension.

[0509] In some exemplary aspects, the compiler 160 may be configured to check whether the predefined conditions for the time-shifting scheme are met with respect to the X dimension of the loop nest of Example 7.

[0510] In some exemplary respects, compiler 160 may determine that the predefined conditions for the time-shifting scheme with respect to the X dimension of the loop nest of Example 7 are satisfied.

[0511] For example, compiler 160 may determine that both memory accesses are loads; that the differences between the offsets of all loads are constant, e.g., 3; that all boundaries of the two loads are the same; that the loop nest does not include any side effects; and / or that the two loads are not masked.

[0512] In some exemplary aspects, the compiler 160 may be configured to check whether the predefined conditions for the additional dimension configuration scheme are met with respect to the Y dimension of the loop nest of Example 7.

[0513] In some exemplary aspects, compiler 160 may determine that the predefined conditions for the additional dimension configuration scheme with respect to the Y dimension of the loop nest of Example 7 are satisfied.

[0514] For example, compiler 160 may determine that the number of dimensions of the loop, e.g., two dimensions, satisfies the condition on the number of dimensions, e.g., #loop-dimensions = 2 <= 3; that the differences between the offsets are all equal, e.g., because there are only two loads; and / or that there are no boundaries or passes.

[0515] In some example aspects, compiler 160 may be configured to specify AGU configuration code for the plurality of AGUs of the target processor, for example, to specify an AGU configuration, such as a vertical / horizontal shifting (“NarrowRectangle”) configuration, for example, to indicate that a combination of a horizontal time-shifting scheme and a vertical additional dimension configuration scheme may be implemented, for example, as described below.

[0516] In some exemplary aspects, the compiler 160 may be configured to specify AGU configuration code for the AGU, for example, according to the additional dimension configuration scheme as described below.

[0517] In some exemplary aspects, compiler 160 may be configured to set an access count parameter, denoted by C, according to the additional dimension, for example, based on the total number of memory accesses to which the additional dimension configuration scheme is to be applied.

[0518] For example, compiler 160 can recognize that the loop nest of Example 7 includes the two loads inp1[index] and inp1[index + 2 * width + 3]. Accordingly, compiler 160 can set the count parameter C to two, e.g., C = Count(Extra-dim) = #AccesseslnTheGroup = 2.

[0519] In some exemplary aspects, compiler 160 may be configured to determine an additional dimension step parameter of the AGU, for example, based on the difference between consecutive offsets of the memory accesses to which the additional dimension configuration scheme is to be applied.

[0520] For example, compiler 160 may detect that the difference between the two "consecutive" offsets of the two loads is equal to 2 (*width), as described above. Accordingly, compiler 160 may set the step parameter of the AGU's extra dimension to 2*width, e.g., Step(Extra-dim) = DifferenceBetween2ClosestOffsets * Stride = 2 * width.

[0521] In some exemplary aspects, compiler 160 may be configured to determine the AGU configuration code for the plurality of AGUs, for example, according to the time-shifting scheme as described below.

[0522] In some example aspects, compiler 160 may be configured to set a same count parameter, denoted as Count(xDim), in a deferred dimension, e.g., the X dimension, for all AGUs, e.g., as described below.

[0523] In some exemplary aspects, compiler 160 may be configured to set the same count parameter for the deferred dimension, for example, based on a count parameter of the deferred dimension loop, a maximum offset of loads to the same memory pointer, and a minimum offset of loads, for example, as follows: Count(xDim)=AlignUpTo((MaxXOffset−MinXOffset)+Count(LoopXDim), VF) / VF where MaxXOffset denotes a maximum offset of memory access operations in the time-shifted dimension, e.g., the X dimension, across all load operations covered by the AGUs, where MinXOffst denotes a minimum offset of the memory access operations in the time-shifted dimension, e.g., the X dimension, across all load operations covered by the AGUs, where VF denotes a vectorization factor (VectorizationFactor), and where the operation AlignUpTo(a,b) can be configured to align a to an integer multiple of b.

[0524] For example, the VF can be similar to the VectorSize parameter. For example, the VF can specify how many elements each vector contains. For example, an element can be a char, short (two bytes), int, or similar.

[0525] For example, the VF can be based on a product of the number of elements and the element size (bytes), e.g., VectorSize = Number of Elements * Element Size (bytes) = VF * Element Size. For example, if the element size is 1, the VF can be the same as the VectorSize.

[0526] For example, the operation alignup(a,b) might involve aligning a value of a to the nearest integer multiple of b. For example, the operation alignup(17,5) might result in a value of 20, e.g., a lowest integer greater than or equal to 17 and an integer multiple of 5. For example, the operation AlignUpTo((MaxXOffset - MinXOffset) + Count(LoopXDim), VF) / VF might be used to ensure that division by VF results in an integer value, for example, to ensure that the count value Count(xDim) is an integer.

[0527] In some exemplary aspects, compiler 160 may be configured to generate loop code, for example, based on the loop nest of Example 7, and pre-header code that executes before the header of the loop code.

[0528] In some exemplary aspects, compiler 160 may be configured to configure the loop code to load only current values, e.g., C current values, within the loop, for example, based on the total number of memory accesses by the same AGU used to implement multiple loads. For example, the loop code may include only two loads, as described below.

[0529] In some exemplary aspects, the compiler 160 may be configured to generate the pre-header code for loading initial values ​​through the same AGU used to implement the plurality of loads, e.g., prior to loop execution.

[0530] For example, the pre-header code may include a plurality of AGU load instructions, for example, executed by the same AGU used to implement the plurality of loads, for example, prior to execution of the loop, as described below.

[0531] In some exemplary aspects, compiler 160 may be configured to remember and / or retain other values ​​from previous AGU load iterations in the loop, e.g., assign (store) them to registers, as described below.

[0532] In some example aspects, a first-in-order iteration of the loop may use values ​​loaded by the pre-header code, such as the initial values, as described below.

[0533] In some exemplary aspects, the compiler 160 may be configured to shuffle between the initial values ​​and the current values, e.g., in a first-in-order iteration of the loop, and to shuffle adjacent values ​​of two consecutive iterations, e.g., when needed, e.g., for all other iterations.

[0534] In some exemplary aspects, the compiler 160 may be configured to configure the pre-header code and the loop code for the time-shifting scheme, for example, based on the loads to be performed by the same AGU, for example, as follows: Add MaxTS * C loads / bumps to the loop's pre-header: %p_i = agu.load(); agu.bump(); (0 <= i < MaxTS * C) Add the Phi chain with length MaxTS * C to the loop: %q_i = phi(%p_i: Pre-header, %q_(i+C): Loop) (0 <= i < MaxTS * C) Add C loads / bumps in the loop after the Phi chain: %q_i = agu.load(); agu.bump(); (MaxTS * C <= i < (MaxTS + 1) * C) Use shuffle(%q_i, %q_(i+C), Elements) (0 <= i < MaxTS * C) in the loop. Where MaxTS*C denotes a product of the number of iterations for which results are stored and loaded within the loop, multiplied by the number of loads in each iteration, for example, to use the results later. The code shuffle(%q_i, %q_(i+C), Elements), e.g., %val1 = shuffle(%q1, %q3, [3, 4, 5, ..., 33, 34]), can be configured to shuffle between adjacent results of the AGU loading iterations.

[0535] For example, the value of MaxTS*C for a value used in a current iteration can indicate how many iterations ago it was loaded from the buffer, e.g., by a load instruction. For example, the value of MaxTS*C can use the maximum value across all such values.

[0536] In some exemplary aspects, compiler 160 may be configured to generate AGU configuration code, pre-header code, and loop code for the loop nest of Example 7, for example, according to the vertical-horizontal relocation scheme, e.g., as follows: AGU configuration code: agu1 = allocate_agu("load"); set_base(agu1, inp1); set_y_minmax(agu1, 0, (height - 2) * width); set_y_count_stride(agu1, height - 2, width); set_x_minmax(agu1, 0, width); VF = VectorizationFactor = 32; VectorSize = VF * 1; XCount = AlignUpTo((width - 3) + 3, VF) / VF; set_x_count_stride(agu1, XCount, VectorSize); set_z_count_stride(agu1, 2, 2 * width) agu2 = allocate_agu("load"); set_base(agu2, inp2); set_y_minmax(agu2, 0, (height - 2) * width); set_y_count_stride(agu2, height - 2, width); set_x_minmax(agu2, 0, width); set_x_count_stride(agu2, XCount, VectorSize); agu_out1 = allocate_agu("store"); set_base(agu_out1, out1); set_y_minmax(agu_out1, 0, (height - 2) * width);set_y_count_stride(agu_out1, height - 2, width); set_x_minmax(agu_out1, 0, width); set_x_count_stride(agu_out1, XCount, VectorSize); agu_out2 = allocate_agu("store"); set_base(agu_out2, out2); set_y_minmax(agu_0out2, 0, (height - 2) * width); set_y_count_stride(agu_out2, height - 2, width); se_x_minmax(agu_out2, 0, width); set_x_count_stride(agu_out2, XCount, VectorSize); Pre-Header: %p0 = agu1.load(); agu1.bump(); %p1 = agu1.load(); agu1.bump(); Grinding: %q0 = phi(%p0: Preheader, %q2: Loop); %q1 = phi(%p1: Preheader, %q3: Loop); %q2 = agu1.load(); agu1.bump(); %q3 = agu1.load(); agu1.bump(); %val_inp2 = agu2.load(); agu2.bump(); %val0 = %q0; / / treats the 32-item vectors %q1, %q3 as if they were a vector with 64 items, and creates a new 32-item vector / / using the items 3, 4, 5, ..., 33, 34. 1% shuffle(1, %q, %q, %q). [3, 4, 5, ..., 33, 34]) %result = add %val0, %val1; agu_out1.store(%result); agu_out1.bump(); agu_out2.store(%val_inp2);agu_out2.bump(); br(Loop); Example (8)

[0537] In some exemplary aspects, as illustrated in Example 8, the AGU configuration code for agu1 may include the AGU configuration code for an additional dimension, e.g., dimension z.

[0538] In some example aspects, as illustrated in Example 8, the additional dimension, e.g., dimension z, may be configured, for example, in addition to dimension x, which may be configured based on the X-loop, and dimension y, which may be configured based on the Y-loop.

[0539] In some exemplary aspects, the AGU configuration code for agu1 may include AGU configuration code, for example, to set the count parameter and the step parameter (step) for the additional dimension z, e.g., according to the vertical configuration with additional dimension for dimension y.

[0540] For example, as shown in Example 8, the AGU configuration code for agu1 may include the AGU configuration code set_z_count_stride(agu1, 2, 2*width) to set, for example, the count parameter for dimension z to 2 and the stride parameter (stride) for dimension z to 2*width.

[0541] In some exemplary aspects, compiler 160 may be configured to configure the AGU configuration code to set the same counting parameter in the X dimension for all AGUs, e.g., according to the horizontal time shift for the X dimension.

[0542] For example, as shown in Example 8, the AGU configuration code can include commands to set the same counting parameter in the X dimension for all AGUs. For example, the AGU configuration code can include the command set_x_count_stride(agu1, XCount, width) for agu1, the command set_x_count_stride(agu2, XCount, width) for agu2, and the command set_x_count_stride(agu_out, XCount, width) for agu_out.

[0543] Example 8 shows that the same counting parameter in the X dimension can be determined, for example, based on the counting parameter of the x-loop; the maximum offset of all loads, e.g., two loads covered by the AGU; the minimum offset of the two loads; and the vectorization factor, e.g., as follows: XCount=Count(XDim)=AlignUpTo((MaxXOffset−MinXOffset)+Count(LoopXDim), VF) / VF=AlignUpTo((width−3)+3, VF) / VF

[0544] In some exemplary aspects, as illustrated in Example 8, the pre-header code MaxTS*C=2 may include AGU load instructions executed by the same agu1, for example, according to the horizontal time shift for the X dimension.

[0545] For example, the two pre-header AGU load commands, e.g., %p0 = agu1.load(); agu1.bump(); and %p1 = agu1.load(); agu1.bump(), can be used to load the agu1 initial values ​​for the AGU load iterations.

[0546] In some exemplary aspects, as shown in Example 8, the loop code may include two conditional assignment instructions, e.g., %q0 = phi(%p0: Preheader, %q2: Loop); %q1 = phi(%p1: Pre-header, %q3: Loop), for example, to assign (store) the results of the AGU loading iterations by the same agu1 to a register.

[0547] From some exemplary perspectives, as shown in Example 8, the two conditional assignment commands, e.g., %q0 = phi(%p0: Pre-header, %q2: Loop); %q1 = phi(%p1: Pre-header, %q3: Loop), can be based on the operation phi, for example.

[0548] In some exemplary aspects, as shown in Example 8, the loop code may include two assignment instructions, e.g., %q2 = agu1.load(); agu1.bump(,), and %q3 = agu1.load(); agu1.bump(,), for example, to load the results of a current loop iteration through the same agu1 and assign them to a register (store them).

[0549] For example, the instruction %q2 = agu1.load(); agu1.bump(,) can be configured to assign (store) to register %q2 a value loaded from agu1 in a first iteration over dimension z, e.g., corresponding to the load inp 1[index].

[0550] For example, the instruction %q3 = agu1.load(); agu1.bump() can be configured to assign (store) to register %q3 a value loaded from agu1 in a second iteration over dimension z, e.g., corresponding to the load operation inp1[index + 2 * width + 3].

[0551] For example, according to the code of Example 8, the pre-header instruction %p0 = agu1.load(); agu1.bump() may be configured to assign (store) to register %p0 a first value loaded from agu1, e.g., according to the load inp1[index], for example, according to the horizontal time offset for the X dimension.

[0552] For example, according to the code of Example 8, the pre-header instruction %p1 = agu1.load(); agu1.bump() may be configured to assign (store) a second value loaded from agu1 to register %p1, e.g., according to the load inp1[index +2*width], for example, according to the horizontal time shift for the X dimension.

[0553] For example, according to the code of Example 8, the loop instruction %q0 = phi(%p0: Pre-header, %q2: Loop) can be configured to assign (store) the first value loaded from agu1 to register %q0, e.g., corresponding to the load inp1[index], for example, in a first-in-order iteration of the loop; or the value from register %q2, e.g., corresponding to the load inp1[index], for example, in a non-first-in-order iteration of the loop.

[0554] For example, according to the code of Example 8, the loop instruction %q1 = phi(%p1: Pre-header, %q3: Loop) can be configured to assign (store) the second value loaded from agu1 to register %q1, e.g., corresponding to the load inp1[index + 2*width + 3], for example, in a first-in-order iteration of the loop; or the value from register %q3, e.g., corresponding to the load inp1[index + 2*width], for example, in a non-first-in-order iteration of the loop.

[0555] In some exemplary aspects, as shown in Example 8, the loop code may include a shuffle instruction, e.g. %val1 = shuffle(%q1, %q3, [3, 4, 5, ..., 33, 34]), to shuffle the results of previous AGU load iterations and the current AGU load iteration, for example, with respect to the load inp1[index +2*width + 3].

[0556] In an example, the size of register %q1 and the size of register %q3 may be 32 elements.

[0557] For example, the register %q1 can contain a first vector in the third line of the scheme of Fig. 5, e.g., cover blocks 0-4 of the third line, for example, in the case that VectorSize = VF = 4. For example, the register %q3 can represent a second vector in the third line of the scheme of Fig. 5, e.g. cover blocks 4 to 8 of the third row.

[0558] For example, the load operation inp1[index +2*width+3] may be a combination of an end section of the register %q1, e.g., corresponding to block 4 in the third line of the scheme of Fig. 5, and an initial section of the register %q3, e.g., corresponding to blocks 5 to 7 in the third line of the scheme of Fig. 5. Accordingly, the merge operation can be configured to concatenate vectors from two registers, e.g., register %q1 and register %q3, into a 64-element vector, and use a required 32-element portion from the 64-element vector, e.g., corresponding to the load operation inp1[index +2*width+3].

[0559] It will now Fig. 6, which schematically illustrates a method of compiling code for a processor. For example, one or more acts of the method of Fig. 6 from a system, e.g. System 100 ( Fig. 1); a device, e.g. device 102 ( Fig. 1); a server, e.g. Server 170 ( Fig. 1); and / or a compiler, e.g. Compiler 160 ( Fig. 1) and / or Compiler 200 ( Fig. 2) are carried out.

[0560] In some example aspects, as indicated in block 602, the method may include identifying a plurality of memory access operations in a loop based on source code to be compiled into target code to be executed by a target processor. For example, the plurality of memory access operations may include at least a first memory access operation and a second memory access operation to the same memory pointer. For example, the first memory access operation may have a first offset, and the second memory access operation may have a second offset that is different from, for example, the first offset. For example, compiler 160 ( Fig. 1) be configured to identify the plurality of memory access operations in the loop, for example, based on the source code 112 ( Fig. 1), as described above.

[0561] In some exemplary aspects, as indicated in block 604, the method may include configuring AGU configuration code to configure the plurality of memory access operations by the same AGU. For example, compiler 160 ( Fig. 1) be configured to configure the AGU configuration code so that the plurality of memory access operations are configured by the same AGU, e.g., as described above.

[0562] In some exemplary aspects, as indicated in block 606, the method may include generating the target code based on compiling the source code. The target code may be based, for example, on the AGU configuration code. For example, compiler 160 ( Fig. 1) be configured to receive destination code 115 ( Fig. 1) is generated based on the AGU configuration code, for example based on compiling the source code 112 ( Fig. 1), as described above.

[0563] It will now Fig. 7, which schematically illustrates a product of manufacture 700 according to some example aspects. Product 700 may include one or more tangible computer-readable ("machine-readable") non-transitory storage media 702 that may contain computer-executable instructions, e.g., implemented by logic 704, that, when executed by at least one computer processor, enables the at least one computer processor to perform one or more operations on device 102 ( Fig. 1), the server 170 ( Fig. 1) and / or the compiler 160 ( Fig. 1) to implement the device 102 ( Fig. 1), the server 170 ( Fig. 1) and / or the compiler 160 ( Fig. 1) to cause one or more operations and / or functionalities to be carried out, triggered and / or implemented, and / or to carry out one or more operations and / or functionalities that are intended to be carried out with reference to the Fig. 1 to 6, and / or to execute, initiate, and / or implement one or more of the operations described herein. The terms "non-transitory machine-readable medium" and "computer-readable non-transitory storage medium" may be construed to include all computer-readable media, with the sole exception of a transient transmitted signal.

[0564] In some example aspects, the product 700 and / or the machine-readable storage medium 702 may include one or more types of computer-readable storage media capable of storing data, including volatile memory, non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. For example, machine-readable storage media 702 may include RAM, DRAM, double data rate DRAM (DDR-DRAM), SDRAM, static RAM (SRAM), ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., NOR or NAND flash memory), content-addressable memory (CAM), polymer memory, phase-change memory, ferroelectric memory, silicon oxide-nitride-oxide-silicon (SONOS) memory, a disk, a hard disk, and the like.The computer-readable storage medium may include any suitable medium related to the downloading or transmission of a computer program from a remote computer to a requesting computer, carried by data signals embodied in a carrier wave or other propagation medium over a communications link, such as a modem, radio, or network connection.

[0565] In some example aspects, logic 704 may include instructions, data, and / or code that, when executed by a machine, may cause the machine to perform a method, process, and / or operations as described herein. For example, the machine may include any suitable processing platform, computing platform, computing unit, processing unit, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware, software, firmware, and the like.

[0566] In some example aspects, logic 704 may include or be implemented as software, a software module, an application, a program, a subroutine, instructions, an instruction set, arithmetic code, words, values, symbols, and the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The instructions may be implemented according to a predefined computer language, style, or syntax to instruct a processor to perform a particular function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language, machine code, and the like. EXAMPLES

[0567] The following examples refer to further aspects.

[0568] Example 1 includes a product comprising one or more tangible computer-readable non-transitory storage media comprising computer-executable instructions that, when executed by at least one processor, enable the at least one processor to cause a compiler to identify a plurality of memory access operations in a loop based on source code to be compiled into target code to be executed by a target processor, wherein the plurality of memory access operations comprises at least a first memory access operation and a second memory access operation to the same memory pointer, the first memory access operation having a first offset, the second memory access operation having a second offset that is different from the first offset;Configure address generation unit (AGU) configuration code to configure the plurality of memory access operations by the same AGU; generate the target code based on compiling the source code, the target code being based on the AGU configuration code;

[0569] Example 2 includes the subject matter of claim 1 and optionally, wherein the instructions, when executed, cause the compiler to configure the AGU configuration code to configure the plurality of memory access operations based on a dimension of the loop, wherein the first offset comprises a first integer multiple of the dimension of the loop and the second offset comprises a second integer multiple of the dimension of the loop.

[0570] Example 3 includes the subject matter of claim 1 or 2, and optionally, wherein the instructions, when executed, cause the compiler, based on a determination that a difference between the first offset and the second offset is independent of a dimension of the loop, to configure the AGU configuration code to configure the plurality of memory access operations based on the difference between the first offset and the second offset.

[0571] Example 4 includes the subject matter of any one of claims 1 to 3, and optionally, wherein the instructions, when executed, cause the compiler to configure the AGU configuration code to configure a first dimension of the AGU based on the dimension of the loop and to configure a second dimension of the AGU based on the independent value, based on a determination that a difference between the first offset and the second offset is based on an integer multiple of a dimension of the loop and on a dimension-independent value that is independent of the dimension of the loop.

[0572] Example 5 includes the subject matter of any one of claims 1 to 4, and optionally, wherein the plurality of memory accesses comprises a third memory access to the same memory pointer, the third memory access having a third offset that is different from the first offset and the second offset, wherein the AGU configuration code is to configure the plurality of memory accesses by the same AGU based on the third offset.

[0573] Example 6 includes the subject matter of any one of claims 1 to 5, and optionally, wherein the loop comprises a first loop, the first loop nested within a second loop, the instructions, when executed, causing the compiler to configure the AGU configuration code based on the second loop.

[0574] Example 7 includes the subject matter of claim 6, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code comprising first dimension code to configure a first dimension of the AGU based on the first loop, second dimension code to configure a second dimension of the AGU based on the plurality of memory accesses, and third dimension code to configure a third dimension of the AGU based on the second loop.

[0575] Example 8 includes the subject matter of claim 6, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, based on a determination that a difference between the first offset and the second offset is based on a dimension of the second loop, comprising a loop swap instruction to instruct a loop swap between a dimension of the AGU corresponding to the first loop and a dimension of the AGU corresponding to the second loop.

[0576] Example 9 includes the subject matter of any one of claims 1 to 8, and optionally, wherein the AGU configuration code comprises a first dimension code to configure a first dimension of the AGU based on the loop and a second dimension code to configure a second dimension of the AGU based on the plurality of memory accesses.

[0577] Example 10 includes the subject matter of claim 9, and optionally, wherein the first dimension code is configured to set a count parameter of the first dimension of the AGU based on a count parameter of the loop and set a step parameter of the first dimension of the AGU based on a step parameter of the loop, and wherein the second dimension code is configured to set a count parameter of the second dimension of the AGU based on a total number of memory accesses in the plurality of memory accesses, and set a step parameter of the second dimension of the AGU based on a difference between the first offset and the second offset.

[0578] Example 11 includes the subject matter of claim 9 or 10, and optionally, wherein the instructions, when executed, cause the compiler to generate loop code based on the loop, the target code being based on the loop code, the loop code comprising a plurality of memory access instructions to be executed by the same AGU, the plurality of memory access instructions each corresponding to the plurality of memory access operations.

[0579] Example 12 includes the subject matter of any one of claims 9 to 11, and optionally, wherein the plurality of memory accesses comprises a third memory access to the same memory pointer, the third memory access having a third offset that is different from the first offset and the second offset, wherein the instructions, when executed, cause the compiler to generate loop code comprising first, second, and third memory access instructions executed by the same AGU based on the first, second, and third memory access instructions, respectively, wherein the target code is based on the loop code.

[0580] Example 13 includes the subject matter of claim 12, and optionally, wherein the instructions, when executed, cause the compiler, based on a determination that a first difference between the first offset and the second offset is equal to a second difference between the second offset and the third offset, to configure the second dimension of the AGU based on the second difference.

[0581] Example 14 includes the subject matter of any of claims 9 to 13, and optionally, wherein the loop comprises a first loop, the first loop nested within a second loop, the AGU configuration code comprising a third dimension code to configure a third dimension of the AGU based on the second loop.

[0582] Example 15 includes the subject matter of any of claims 9 to 14, and optionally, wherein the instructions, when executed, cause the compiler to configure the second dimension of the AGU based on the plurality of memory accesses based on a determination that a number of dimensions of the first loop is less than a number of dimensions supported by the same AGU.

[0583] Example 16 includes the subject matter of any of claims 9 to 15, and optionally, wherein the instructions, when executed, cause the compiler to configure the second dimension of the AGU based on the plurality of memory accesses based on a determination that the plurality of memory accesses have no boundaries and no passes.

[0584] Example 17 includes the subject matter of any of claims 9 to 16, and optionally, wherein the instructions, when executed, cause the compiler to configure the second dimension of the AGU based on the plurality of memory accesses based on a determination that differences between consecutive offsets of the plurality of memory accesses are equal.

[0585] Example 18 includes the subject matter of any one of claims 9 to 17, and optionally wherein the instructions, when executed, cause the compiler to configure the second dimension of the AGU based on the plurality of memory accesses based on a determination that a number of dimensions of the first loop is less than a number of dimensions supported by the same AGU, that the plurality of memory accesses have no boundaries and no passes, and that differences between consecutive offsets of the plurality of memory accesses are the same.

[0586] Example 19 includes the subject matter of any one of claims 1 to 18, and optionally, wherein the AGU configuration code comprises code to configure the same AGU according to a time-shifting scheme, the time-shifting scheme configured to implement the plurality of memory accesses as a plurality of time-shifted memory accesses of the same AGU during a plurality of respective loop iterations.

[0587] Example 20 includes the subject matter of claim 19, and optionally, wherein the AGU configuration code comprises a loop swap command for a dimension of the AGU corresponding to the loop, the loop swap command configured to command a loop swap between the dimension of the AGU corresponding to the loop and another dimension of the AGU corresponding to an outer loop.

[0588] Example 21 includes the subject matter of claim 19, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code comprising a loop swap instruction for a dimension of the AGU corresponding to the loop based on a determination that a difference between the first offset and the second offset is based on a dimension of another loop that includes the loop, the loop swap instruction configured to instruct a loop swap between the dimension of the AGU corresponding to the loop and another dimension of the AGU corresponding to the other loop.

[0589] Example 22 includes the subject matter of any of claims 19 to 21, and optionally, wherein the AGU configuration code is configured to set a same count parameter for all AGUs to perform memory accesses during the loop, the same count parameter being based on a count parameter of the loop, a maximum offset of the plurality of memory accesses, and a minimum offset of the plurality of memory accesses.

[0590] Example 23 includes the subject matter of claim 22, and optionally, wherein the AGU configuration code shall set the same counting parameter, denoted as Count, as follows: Count=AlignUpTo((MaxXOffset−MinXOffset)+Count(Loop), VF) / VF where MaxXOffset denotes the maximum offset of the plurality of memory access operations, where MinXOffst denotes the minimum offset of the plurality of memory access operations, where VF denotes a vectorization factor, where Count(Loop) denotes the counting parameter of the loop, and where the operation AlignUpTo(a,b) consists in aligning a to an integer multiple of b.

[0591] Example 24 includes the subject matter of any one of claims 19 to 23, and optionally, wherein the instructions, when executed, cause the compiler to generate loop code based on the loop, and pre-header code to be executed before a header of the loop code, wherein the target code is based on the loop code and the pre-header code, wherein the pre-header code comprises a plurality of AGU load instructions to be executed by the same AGU, wherein a number of AGU load instructions in the plurality of AGU load instructions is based on a number of memory accesses in the plurality of memory accesses.

[0592] Example 25 includes the subject matter of claim 24, and optionally, wherein the loop code comprises a plurality of store instructions to store results of a respective plurality of AGU load iterations by the same AGU, wherein a number of the plurality of store instructions is based on the number of memory accesses in the plurality of memory accesses.

[0593] Example 26 includes the subject matter of claim 25, and optionally, wherein the plurality of store instructions are configured to cause the target processor to store a plurality of load results of the plurality of AGU load instructions in the pre-header code in a first-in-order iteration of the plurality of AGU load iterations.

[0594] Example 27 includes the subject matter of any of claims 19 to 26, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code to configure the same AGU according to the time-shifting scheme, based on a determination that the plurality of memory access operations include only load operations.

[0595] Example 28 includes the subject matter of any of claims 19 to 27, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code to configure the same AGU according to the time-shifting scheme, based on a determination that differences between consecutive offsets of the plurality of memory accesses are independent of a dimension of the loop.

[0596] Example 29 includes the subject matter of any of claims 19 to 28, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code to configure the same AGU according to the time-shifting scheme, based on a determination that the plurality of memory accesses have no boundaries and no passes.

[0597] Example 30 includes the subject matter of any of claims 19 to 29, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code to configure the same AGU according to the time-shifting scheme, based on a determination that the plurality of memory accesses are not masked.

[0598] Example 31 includes the subject matter of any of claims 19 to 30, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code to configure the same AGU according to the time-shifting scheme, based on a determination that the loop does not include side effects.

[0599] Example 32 includes the subject matter of any one of claims 19 to 31, and optionally, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, comprising code to configure the same AGU according to the time-shifting scheme, based on a determination that the plurality of memory accesses comprise only loads, that differences between consecutive offsets of the plurality of memory accesses are independent of a dimension of the loop, that the plurality of memory accesses have no boundaries and no passes, that the plurality of memory accesses are not masked, and that the loop does not comprise any side effects.

[0600] Example 33 includes the subject matter of any of claims 1 to 32, and optionally, wherein the plurality of memory access operations comprises a plurality of load operations.

[0601] Example 34 includes the subject matter of any of claims 1 to 33, and optionally, wherein the source code comprises Open Computing Language (OpenCL) code.

[0602] Example 35 includes the subject matter of any of claims 1 to 34, and optionally, wherein the computer-executable instructions, when executed, cause the compiler to compile the source code into the target code according to a Low Level Virtual Machine (LLVM)-based (LLVM-based) compilation scheme.

[0603] Example 36 includes the subject matter of any of claims 1 to 35, and optionally, wherein the target code is configured for execution by a VLIW (Very Long Instruction Word, Single Instruction / Multiple Data) SIMD target processor.

[0604] Example 37 includes the subject matter of any of claims 1 to 36, and optionally, wherein the target code is configured for execution by a target vector processor.

[0605] Example 38 includes a compiler configured to perform any of the described operations of any of Examples 1 through 37.

[0606] Example 39 includes a computing device configured to perform any of the described operations of any of Examples 1 to 37.

[0607] Example 40 includes a computer system comprising at least one memory for storing instructions and at least one processor for retrieving instructions from the memory and executing the instructions to cause the computer system to perform any of the described operations of any of Examples 1 to 37.

[0608] Example 41 includes a computer system comprising a compiler for generating target code according to any of the described operations of any of Examples 1 to 37 and a processor for executing the target code.

[0609] Example 42 includes an apparatus comprising means for performing any of the described operations of any of Examples 1 to 37.

[0610] Example 43 includes a device comprising: a memory interface; and processing circuitry configured to perform any of the described operations of any of Examples 1 to 37.

[0611] Example 44 includes a method comprising any of the described operations of any of Examples 1 to 37.

[0612] Functions, operations, components, and / or features described herein with reference to one or more aspects may be combined with or used in combination with one or more other functions, operations, components, and / or features described herein with reference to one or more other aspects, or vice versa.

[0613] While certain features have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover all modifications and changes that remain within the true spirit of the disclosure. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US 63 / 415,310

[0001]

Claims

[1] A product comprising one or more tangible computer-readable non-transitory storage media comprising computer-executable instructions that, when executed by at least one processor, enable the at least one processor to cause a compiler to: identify a plurality of memory access operations in a loop based on source code to be compiled into target code to be executed by a target processor, the plurality of memory access operations comprising at least a first memory access operation and a second memory access operation to the same memory pointer, the first memory access operation having a first offset, the second memory access operation having a second offset that is different from the first offset; configure the address generation unit (AGU) configuration code to configure the plurality of memory access operations by the same AGU; and to generate the target code based on compiling the source code, where the target code is based on the AGU configuration code. [2] The product of claim 1, wherein the instructions, when executed, cause the compiler to configure the AGU configuration code to configure the plurality of memory access operations based on a dimension of the loop, wherein the first offset comprises a first integer multiple of the dimension of the loop and the second offset comprises a second integer multiple of the dimension of the loop. [3] The product of claim 1, wherein the instructions, when executed, cause the compiler, based on a determination that a difference between the first offset and the second offset is independent of a dimension of the loop, to configure the AGU configuration code to configure the plurality of memory access operations based on the difference between the first offset and the second offset. [4] The product of claim 1, wherein the instructions, when executed, cause the compiler to configure the AGU configuration code to configure a first dimension of the AGU based on the dimension of the loop and to configure a second dimension of the AGU based on the independent value based on a determination that a difference between the first offset and the second offset is based on an integer multiple of a dimension of the loop and on a dimension-independent value that is independent of the dimension of the loop. [5] The product of claim 1, wherein the plurality of memory accesses comprises a third memory access to the same memory pointer, the third memory access having a third offset that is different from the first offset and the second offset, the AGU configuration code to configure the plurality of memory accesses by the same AGU based on the third offset. [6] The product of claim 1, wherein the loop comprises a first loop, the first loop nested within a second loop, the instructions, when executed, causing the compiler to configure the AGU configuration code based on the second loop. [7] The product of claim 6, wherein the instructions, when executed, cause the compiler to configure AGU configuration code comprising first dimension code for configuring a first dimension of the AGU based on the first loop, second dimension code for configuring a second dimension of the AGU based on the plurality of memory accesses, and third dimension code for configuring a third dimension of the AGU based on the second loop. [8] The product of claim 6, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, based on a determination that a difference between the first offset and the second offset is based on a dimension of the second loop, comprising a loop swap instruction to instruct a loop swap between a dimension of the AGU corresponding to the first loop and a dimension of the AGU corresponding to the second loop. [9] The product of claim 1, wherein the AGU configuration code comprises a first dimension code to configure a first dimension of the AGU based on the loop and a second dimension code to configure a second dimension of the AGU based on the plurality of memory accesses. [10] The product of claim 9, wherein the first dimension code is configured to set a count parameter of the first dimension of the AGU based on a count parameter of the loop and to set a step parameter of the first dimension of the AGU based on a step parameter of the loop, and wherein the second dimension code is configured to set a count parameter of the second dimension of the AGU based on a total number of memory accesses in the plurality of memory accesses, and to set a step parameter of the second dimension of the AGU based on a difference between the first offset and the second offset. [11] The product of claim 9, wherein the instructions, when executed, cause the compiler to generate loop code based on the loop, the target code being based on the loop code, the loop code comprising a plurality of memory access instructions to be executed by the same AGU, the plurality of memory access instructions each corresponding to the plurality of memory access operations. [12] The product of claim 9, wherein the plurality of memory accesses comprises a third memory access to the same memory pointer, the third memory access having a third offset different from the first offset and the second offset, the instructions, when executed, causing the compiler to generate loop code comprising first, second, and third memory access instructions to be executed by the same AGU based on the first, second, and third memory access instructions, respectively, the target code being based on the loop code. [13] The product of claim 9, wherein the loop comprises a first loop, the first loop nested within a second loop, the AGU configuration code comprising a third dimension code to configure a third dimension of the AGU based on the second loop. [14] The product of claim 9, wherein the instructions, when executed, cause the compiler to configure the second dimension of the AGU based on the plurality of memory accesses based on a determination that a number of dimensions of the first loop is less than a number of dimensions supported by the same AGU. [15] The product of claim 9, wherein the instructions, when executed, cause the compiler to configure the second dimension of the AGU based on the plurality of memory accesses based on a determination that the plurality of memory accesses have no boundaries and no passes. [16] The product of claim 9, wherein the instructions, when executed, cause the compiler to configure the second dimension of the AGU based on the plurality of memory accesses based on a determination that differences between consecutive offsets of the plurality of memory accesses are equal. [17] The product of claim 9, wherein the instructions, when executed, cause the compiler to configure the second dimension of the AGU based on the plurality of memory accesses based on a determination that a number of dimensions of the first loop is less than a number of dimensions supported by the same AGU, that the plurality of memory accesses have no boundaries and no passes, and that differences between consecutive offsets of the plurality of memory accesses are the same. [18] The product of any one of claims 1 to 17, wherein the AGU configuration code comprises code to configure the same AGU according to a time-shifting scheme, the time-shifting scheme configured to implement the plurality of memory accesses as a plurality of time-shifted memory accesses of the same AGU during a plurality of respective loop iterations. [19] The product of claim 18, wherein the AGU configuration code comprises a loop swap command for a dimension of the AGU corresponding to the loop, the loop swap command configured to instruct a loop swap between the dimension of the AGU corresponding to the loop and another dimension of the AGU corresponding to an outer loop. [20] The product of claim 18, wherein the instructions, when executed, cause the compiler to configure AGU configuration code comprising a loop swap instruction for a dimension of the AGU corresponding to the loop based on a determination that a difference between the first offset and the second offset is based on a dimension of another loop comprising the loop, the loop swap instruction configured to instruct a loop swap between the dimension of the AGU corresponding to the loop and another dimension of the AGU corresponding to the other loop. [21] The product of claim 18, wherein the AGU configuration code is configured to set a same count parameter for all AGUs to perform memory access operations during the loop, the same count parameter being based on a count parameter of the loop, a maximum offset of the plurality of memory access operations, and a minimum offset of the plurality of memory access operations. [22] The product of claim 21, wherein the AGU configuration code is to set the same counting parameter, designated Count, as follows: Count=AlignUpTo((MaxXOffset−MinXOffset)+Count(Loop), VF) / VF where MaxXOffset denotes the maximum offset of the plurality of memory access operations, where MinXOffst denotes the minimum offset of the plurality of memory access operations, where VF denotes a vectorization factor, where Count(Loop) denotes the counting parameter of the loop, and where the operation AlignUpTo(a,b) consists in aligning a to an integer multiple of b. [23] The product of claim 18, wherein the instructions, when executed, cause the compiler to generate loop code based on the loop and pre-header code to be executed before a header of the loop code, the target code being based on the loop code and the pre-header code, the pre-header code comprising a plurality of AGU load instructions to be executed by the same AGU, a number of AGU load instructions in the plurality of AGU load instructions being based on a number of memory accesses in the plurality of memory accesses. [24] The product of claim 23, wherein the loop code comprises a plurality of store instructions for storing results of a respective plurality of AGU loading iterations by the same AGU, wherein a number of the plurality of store instructions is based on the number of memory accesses in the plurality of memory accesses. [25] The product of claim 24, wherein the plurality of storage instructions are configured to cause the target processor to store a plurality of load results of the plurality of AGU load instructions in the pre-header code in a first-in-order iteration of the plurality of AGU load iterations. [26] The product of claim 18, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code for configuring the same AGU according to the time-shifting scheme, based on a determination that the plurality of memory access operations comprise only load operations. [27] The product of claim 18, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code for configuring the same AGU according to the time-shifting scheme, based on a determination that differences between consecutive offsets of the plurality of memory accesses are independent of a dimension of the loop. [28] The product of claim 18, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code for configuring the same AGU according to the time-shifting scheme, based on a determination that the plurality of memory accesses have no boundaries and no passes. [29] The product of claim 18, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code for configuring the same AGU according to the time-shifting scheme, based on a determination that the plurality of memory accesses are not masked. [30] The product of claim 18, wherein the instructions, when executed, cause the compiler to configure AGU configuration code, including code for configuring the same AGU according to the time-shifting scheme, based on a determination that the loop does not include side effects. [31] The product of any one of claims 1 to 17, wherein the plurality of memory access operations comprises a plurality of load operations. [32] The product of any of claims 1 to 17, wherein the source code comprises Open Computing Language (OpenCL) code. [33] The product of any of claims 1 to 17, wherein the computer-executable instructions, when executed, cause the compiler to compile the source code into the target code according to a Low Level Virtual Machine (LLVM)-based (LLVM-based) compilation scheme. [34] The product of any one of claims 1 to 17, wherein the target code is configured for execution by a Very Long Instruction Word Single Instruction / Multiple Data (VLIW) SIMD target processor. [35] The product of any of claims 1 to 17, wherein the target code is configured for execution by a target vector processor. [36] Computer system comprising: at least one memory for storing instructions; and at least one processor for retrieving the instructions from memory and executing the instructions to cause the computer system to: identify a plurality of memory access operations in a loop based on source code to be compiled into target code to be executed by a target processor, the plurality of memory access operations comprising at least a first memory access operation and a second memory access operation to the same memory pointer, the first memory access operation having a first offset, the second memory access operation having a second offset that is different from the first offset; configure the address generation unit (AGU) configuration code to configure the plurality of memory access operations by the same AGU; and to generate the target code based on compiling the source code, where the target code is based on the AGU configuration code. [37] A computer system according to claim 36, comprising the target processor for executing the target code. [38] Method comprising: Identifying a plurality of memory access operations in a loop based on source code to be compiled into target code to be executed by a target processor, the plurality of memory access operations comprising at least a first memory access operation and a second memory access operation to the same memory pointer, the first memory access operation having a first offset, the second memory access operation having a second offset that is different from the first offset; Configuring an address generation unit (AGU) configuration code to configure the plurality of memory access operations by the same AGU; and Generating the target code based on the compilation of the source code, where the target code is based on the AGU configuration code. [39] The method of claim 38, wherein the AGU configuration code comprises a first dimension code to configure a first dimension of the AGU based on the loop and a second dimension code to configure a second dimension of the AGU based on the plurality of memory accesses.

Images