Widening vector load instruction

Abstract

A widening vector load instruction specifies at least one address operand and two or more vector destination registers, e.g. Z1 and Z2, each for specifying a vector operand having a given vector lengt

Description

The present technique relates to the field of data processing. Processing circuitry may support a vector processing architecture where vector instructions can trigger vector operations to be performed on vector operands comprising 5 multiple data elements. Performing vector operations using vector instructions can enable the instruction fetch and decoding overhead of a given operation to be performed on each of a set of data elements to be reduced compared to a scalar implementation processing each data element individually using a separate scalar instruction. At least some examples provide an apparatus according to claim 1. 10 At least some examples provide computer-readable code according to claim 16. At least some examples provide a method according to claim 17. At least some examples provide a computer program according to claim 18. At least some examples provide a storage medium storing the computer-readable code or the computer program mentioned above. The storage medium may be a non-transitory 15 storage medium. Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which: Figure 1 illustrates an example of a processing system supporting vector processing; Figure 2 illustrates an example of vector registers having a vector length indicated by a vector length parameter; Figure 3 illustrates a first example of instruction decoding circuitry and issue circuitry, in this case provided within a processor such as a Central Processing Unit (CPU); Figure 4 illustrates an example of use of a co-processor to process an offloaded subset of operations from a stream of operations to be performed by a main processor; Figure 5 illustrates functionality of a de-interleaving variant of a widening vector load instruction; Figure 6 illustrates functionality of a non-de-interleaving variant of a widening vector load instruction; Figure 7 illustrates a method of data processing; Figure 8 illustrates a method of processing a widening vector load instruction; Figure 9 illustrates a method of processing a de-interleaving variant of the widening vector load instruction; Figure 10 illustrates a method of processing a non-de-interleaving variant of the widening vector load instruction; and Figure 11 illustrates a simulation example. An apparatus comprises instruction decoding circuitry to decode instructions, and issue circuitry to issue, in response to decoding of a given instruction by the instruction decoding circuitry, at least one micro-operation to control processing circuitry to perform a processing operation corresponding to the given instruction. Design of the instruction set supported by the instruction decoding circuitry can be a relatively complex task, because there may be a limited encoding space available in comparison with the wide range of operations which could theoretically be supported, and so to support a particular instruction, there would need to be a justification for providing it. The design choices and compromises made in which operations are supported and how those instructions are encoded can affect the performance and power consumption of the processing circuitry. Other factors to consider can be the practicality of implementing circuitry that executes the instruction, and the flexibility the architected instructions provide for supporting different micro-architectural design choices of circuit implementation. Therefore, merely because a given operation is theoretically possible, this does not automatically mean that its inclusion as a specific instruction would be desirable. Instruction set architecture designers are generally extremely cautious about adding new instructions to the instruction set, as once an instruction is included, it is extremely difficult to remove it as it would need to continue to be supported to allow legacy software using the instruction to continue to function. If an instruction is introduced which turns out to be problematic to implement in circuit hardware or which causes there to be insufficient encoding space to represent another more desirable operation, the consequences of that poorly thought out addition to the instruction set would be felt for a long time. Hence, care is taken when considering additions to the instruction set. In the examples below, the instruction decoding circuitry supports a widening vector load instruction which specifies at least one address operand and a plurality of vector destination registers each for specifying a vector operand having a given vector length. In response to decoding of the widening vector load instruction, the instruction decoding circuitry controls the issue circuitry to issue at least one micro-operation to control the processing circuitry to: • load at least one vector of data elements from a location in a memory system corresponding to a target memory address determined based on the at least one address operand; • widen the data elements of the loaded at least one vector from a first data element size to a second data element size larger than the first data element size; and • write the widened data elements having the second data element size to the plurality of vector destination registers as a plurality of respective vector operands. Hence, the widening vector load instruction causes both loading of the vector of data elements and widening to the second data element size to be performed in response to a single instruction, and also can populate more than one destination register of the given vector length with widened data elements from the loaded at least one vector. This instruction can be helpful for workloads which process a data structure where the storage format of data elements stored in memory is compressed compared to the processing format in which the data elements are subject to processing operations at the processing circuitry. For example, the expansion to the second data element size can be useful for enabling higher precision to be retained during intermediate steps of subsequent vector processing operations performed on the loaded widened data elements, while the denser storage format can sacrifice precision to reduce memory storage overhead for a given number of data elements. An example of a type of workload for which this is useful is an image processing workload where it can be very common for pixel data to be stored with a smaller data element size in memory, so as to require expansion to a wider data element size when loading the data for applying image processing kernels such as filtering, resizing or rotation. Vector processing architectures can be attractive for this type of workload as they can apply a repetitive operation to multiple data elements in response to a single instruction. However, the inventor has recognised that existing vector instruction sets can be inefficient for handling this type of workload. The widening vector load instruction described in this application can be more efficient than alternative instructions because, as the load and widening are both performed in response to a single architectural instruction and the destination register of the load instruction is written with the widened data elements, there is no need to consume additional architectural registers (registers represented by one of the limited set of architectural register identifiers that can be encoded in the instruction encoding) for holding one or more temporary non-widened loaded vectors between the load and the widening operation (in contrast, such architectural registers would be consumed if a load instruction and widening instruction were executed as separate architectural instructions with the widening instruction being a register-to-register instruction rather than a memory-to-register instruction). Therefore, the widening vector load instruction can help to reduce register pressure, which will tend to improve performance because code runs out of spare architectural registers less often, reducing the need to spill register data to memory when it could otherwise have been kept within the register file corresponding to architectural vector registers. Also, providing a single instruction to represent the architectural intent to perform both the load and the widening operation can enable more flexible micro-architectural designs for the processing circuitry. For example, this instruction permits the flexibility to implement a load-permute-writeback pipeline which passes the result of the load direct to a permute unit to rearrange the loaded data elements for implementing the widening, without needing an intervening register file write / read between the load and permute. In contrast, if architecturally the load and widening operations were implemented as separate instructions which do not express the architectural intent that the widening operation follows the load, an intervening register write / read would typically be needed. Also, by providing an instruction which can populate two or more destination vector registers with widened data elements based on narrower data elements loaded from memory, this preserves the memory throughput (number of memory-based data elements processed per load instruction) that would be achieved for an equivalent non-widening vector load instruction acting on the data in memory. In contrast, an alternative widening load instruction which writes widened data elements to a single vector destination register of the given vector length would have a reduced memory throughput compared to an equivalent non-widening vector load instruction. By maintaining memory throughput, this avoids the need to increase the number of vector load instructions per vectorised loop iteration to maintain a given level of memory throughput per loop iteration. Executing a greater number of load instructions per processed amount of memory data would incur a greater cost in terms of memory control bandwidth (e.g. increase the number of memory translation lookups, load / store unit slots consumed etc., which can restrict bandwidth available for other operations and hence limit performance). This cost can be reduced for a given amount of memory throughput by using the widening vector load instruction described above. Therefore, the widening vector load instruction which writes to multiple destination vector registers can provide a number of advantages for supporting workloads which require data elements to be processed with a larger data element size than their storage format in memory, and so the extra encoding space consumed by providing this type of instruction in the instruction set can be justified. The widening vector load instruction could be mapped to one or more micro-operations by the instruction decoding circuitry, with the particular number of micro-operations depending on the practical implementation by a particular micro-architecture. For example, some examples may support a single combined micro-operation which can control the processing circuitry to perform both the load and the widening operations. This could be helpful for micro-architectures which support a combined load / permute pipeline which acts as a single functional unit. Other examples may map the widening vector load instruction to separate micro-operations: one or more load micro-operations (which could themselves be split into an address computation micro-operation and a memory access micro-operation, for example), and one or more permute micro-operations to perform the widening operation. This split micro-operation approach could work better for implementations which have a load / store unit and a permute unit as separate functional units. With the split micro-operation approach, a temporary physical register could be used to hold the loaded vector of data elements as an intermediate result before the permute unit applies the widening to the loaded vector of data elements, but nevertheless this does not increase register pressure as discussed above, because the temporary physical register would not be mapped to any architectural register and so does not affect the speed with which the software runs out of architectural registers to use for different variables. Hence, it will be appreciated that there can be a wide range of ways of supporting the widening vector load instruction at a micro-architectural level. The instruction gives flexibility for a wide variety of design choice in this respect. The widening vector load instruction specifies two or more vector destination registers. The vector destination registers could be identified explicitly by two or more destination register fields in the encoding of the widening vector load instruction. Alternatively, the instruction may explicitly identify a first destination register of the two or more destination registers in a register field of the instruction encoding, and one or more other destination registers of the two or more vector destination registers may implicitly be identified as the vector destination registers whose architectural register identifiers are at predetermined offsets relative to the architectural register identifier of the first destination register. For example, the two or more vector destination registers may be the registers associated with a contiguous set of architectural register identifiers starting from the architectural register identifier of the first destination register that is explicitly encoded in the instruction encoding. With this approach, the software developer or compiler is constrained to select registers with contiguous architectural register identifiers as the destinations for the widening vector load instruction, but this constraint has the advantage of reducing the amount of encoding space needed for encoding the multiple destination registers, which can be useful as instruction encoding space can be at a premium. Regardless of the particular approach taken to encode the vector source registers in the instruction, each vector source register explicitly or implicitly identified by the instruction is associated with a different architectural register identifier, and so can separately be specified as a source or destination register by another instruction of the instruction set supported by the instruction decoding circuitry. That is, where a given vector instruction specifies a source / destination vector register field for specifying an identifier of a corresponding vector register used as a source / destination operand, each vector source register of the narrowing vector store instruction may have an associated architectural register identifier which corresponds to a different encoding of the source / destination register field of the given vector instruction. Hence, each source register of the narrowing vector store instruction could independently be specified as an operand for a vector operation or as a destination to be updated based on the result of the vector operation. It is not necessary that subsequent instructions after the widening vector load instruction process each destination of the vector load instruction collectively - separate instructions could individually process each destination register of the widening vector load instruction. The widening vector load instruction may permits the loaded at least one vector of data elements to have a total size greater than or equal to the given vector length. It is not essential for every instance of the widening vector load instruction to load an amount of data of size greater than or equal to the given vector length, as for some cases of predication, it might be that the predicate operand of the widening vector load instruction may have selected an active portion of data of size less than the given vector length. Nevertheless, the maximum amount of data capable of being loaded by the widening vector load instruction may be greater than or equal to the given vector length. This helps to preserve memory throughput compared to equivalent non-widening vector load instructions. A de-interleaving variant of the widening vector load instruction is supported. In response to the de-interleaving variant, the instruction decoding circuitry controls the issue circuitry to issue the at least one micro-operation to control the processing circuitry to deinterleave two or more interleaved channels of data elements obtained from the at least one vector, to cause each vector destination register to specify one or more widened data elements corresponding to a different channel of the interleaved channels. The de-interleaving variant can be useful for supporting processing workloads which operate on a storage structure comprising multiple interleaved channels of data elements, such as pixel data for an image represented in RGB (red, green, blue) or RGBA (red, green, blue, alpha) format, but which require processing kernels to be applied to individual channels of data extracted from the stored multi-channel structure. By combining the widening and de-interleaving operations into a single instruction, this can give flexibility for circuit designers to implement more efficient use of permute units which may be able to do both operations in a single action. Alternatively, other implementations may implement the widening and de-interleaving steps as separate steps which could occur in either order (either widening first and then de-interleaving, or deinterleaving first and then widening). A de-interleaving pattern for writing the widened data elements to the plurality of vector destination registers can be implicitly defined by an encoding of the de-interleaving variant of the widening vector load instruction. Hence, there is no need for the de-interleaving variant of the widening vector load instruction to specify an index operand which specifies index values explicitly identifying which of the loaded data elements is to be inserted at each respective element position of the destination registers. For example the implicitly defined de-interleaving pattern may be a pattern in which successive loaded data elements from the loaded at least one vector are alternatively allocated to the respective vector destination registers in a round-robin fashion (e.g. if data stored in RGB or RGBA format as stored data RGB(A)RGB(A)RGB(A)... is being de-interleaved, the “R” elements are allocated to one vector destination register, the “G” elements are allocated to another vector destination register, and so on). Hence, the deinterleaving variant of the widening vector load instruction may be architecturally constrained to control the processing circuitry to perform a particular implicitly- defined de-interleaving pattern, and cannot support any arbitrary general-purpose permutation where any single data element from the loaded vector(s) can be arbitrarily permuted to any position within the vector destination registers. Using an implicitly defined de-interleaving pattern can be advantageous because an index vector used to control a general-purpose permutation can make it difficult to write vector-length-agnostic software according to a scalable vector architecture (discussed further below), as the index values for the index vector would need pre-computing in software for a specific vector length, and the limited range available for each index value of the index vector can constrain the maximum vector length that can be supported by a generic permutation operation controlled by the index vector. By providing a de-interleaving variant of the widening vector load instruction which uses an implicitly-defined interleaving pattern, these problems can be avoided, and scalable vectorised software becomes possible for handling workloads which operate on narrower data elements stored in memory as a packed interleaved data structure, which require expansion when being loaded for processing. The de-interleaving variant of the widening vector load instruction specifies at least one predicate value specifying element predication information indicative of which data elements of the at least one vector are masked data elements for which corresponding portions of the plurality of vector destination registers are to specify a value independent of the masked data elements. For example, for a portion of the vector destination registers which would otherwise be written with a widened data element corresponding to a given masked data element if predication had not been applied, the value independent of the masked data element could be zero or could be a previous value associated with that portion of the vector destination registers. The predication information could be represented in different ways. Some examples may specify, as the at least one predicate value, a predicate mask comprising a number of bit fields each indicating whether a corresponding element group is masked or non-masked. Alternatively, a predicate counter could be used to indicate a total number of non-masked data elements (which might implicitly be considered to start from the first data element of the loaded at least one vector which is stored at the target memory address itself). In other words, the predicate counter could indicate the boundary between an initial set of non-masked data elements and a subsequent set of masked data elements. Regardless of the specific way in which the predicate value represents the masked data elements, by supporting predication, this allows software to prevent the load operations for the widening vector load instruction spilling into a subsequent region of memory beyond the end of the data structure being processed, even if the data structure being processed has a total number of data elements that does not correspond to an exact multiple of the number of elements that can be processed using a single instance of the widening vector load instruction. For the de-interleaving variant of the widening vector load instruction, the element predication information is specified by the at least one predicate value at granularity of element groups, each element group comprising one data element from each of the plurality of interleaved channels. For example, all of the elements within the same element group may have their predication controlled by the same mask bit of a predicate mask specified as the at least one predicate value. Alternatively, in the case of a predicate counter, monotonically increasing values of the predicate counter cause successive groups of elements to be selected as active (e.g. a count value of 3 causes a further element group (comprising multiple data elements) to be selected as active which would have been masked if the count value was 2). Hence, for the de-interleaving variant, the encoding of the instruction constrains the predication to either mask all data elements of the same element group or not mask any of the data elements are the same element group, so it would not be possible to partially mask some elements of the element group while not masking other elements in the same element group. Applying predication at granularity of element groups can be particularly useful for the deinterleaving variant as typically if there is a need to de-interleave multiple channels of interleaved data, each of the channels of a given element group will either need to be processed or not, and so there is little benefit to supporting partial predication. Restricting predication to granularity of element groups can also simplify the micro-architectural implementation because when de-interleaving the elements of a single element group to multiple vector destination registers, a common predicate control can be applied to the corresponding element position in each vector destination register. Some examples may support a non-de-interleaving variant of the widening vector load instruction (which could be supported in addition to the de-interleaving variant). In response to the non-de-interleaving variant of the widening vector load instruction, the instruction decoding circuitry may control the issue circuitry to issue the at least one micro-operation to control the processing circuitry to write to a given one of the plurality of vector destination registers a set of widened data elements corresponding to data elements loaded from locations in the memory system corresponding to a contiguous block of memory addresses. The non-de-interleaving variant can be useful for supporting workloads where either the storage structure in memory does not pack multiple channels in interleaved fashion, or while the storage structure comprises interleaved channels of data, the processing kernel to be applied to that storage structure requires the elements of a single multi-channel element group to be processed collectively so that is useful to locate these at adjacent positions within the vector destination registers. Nevertheless, both the de-interleaving variant and non-deinterleaving variant can provide the instruction set design advantages discussed above. The non-de-interleaving variant of the widening vector load instruction may specify at least one predicate value specifying element predication information indicative of which data elements of the at least one vector are masked data elements for which corresponding portions of the plurality of vector destination registers are to specify a value independent of the masked data elements. Hence, similar to the de-interleaving variant, a predication option is supported to allow the amount of data to be processed by a given instance of the instruction to be adjusted based on software control. For example, this can be useful to ensure that the load operations do not spill beyond a memory page boundary into a subsequent region which the current software is not permitted to access (avoiding loss of performance by handling the associated page faults). However, unlike the de-interleaving variant, for the non-de-interleaving variant it can be useful for the element predication information to be specified at granularity of individual data elements of the at least one vector, rather than at granularity of element groups. Hence, the non-de-interleaving variant has more architectural flexibility in specifying which elements are masked, which can be useful for supporting application of the non-de-interleaving variant of the widening vector load instruction to data structures which do not comprise packed interleaved channels (although the non-de-interleaving variant can also be applied to such packed structures, the architectural flexibility given by individual element granularity predication can support wider use cases for the non-de-interleaving variant). The non-de-interleaving variant of the widening vector load instruction may specify at least one predicate register, each predicate register specifying a predicate value specifying element predication information for controlling predication for two or more of the plurality of vector destination registers. This exploits the fact that, as the loaded data elements are being widened to a larger data element size, the number of widened elements per vector destination register will be reduced compared to an equivalent non-widening load instruction, and so there may be some spare predicate encodings in a single predicate register that would not be used if one predicate register per vector destination was provided. For example, some bitfields of a predicate mask, or some count values for a predicate counter may be spare, in a predicate value designed to support a number of bitfields or range of the counter that is sufficient to handle the largest possible number of data elements within one vector register. Therefore, when the widening instruction is used, a single predicate register can control predication of multiple vector registers. For example, for a predicate mask, a first portion of the predicate mask may control predication for a first predicate register, and a second portion of the predicate mask may control predication for a second predicate register. If the predicate value is implemented as a counter value which specifies the position of a boundary between masked and non-masked data elements, the maximum range for the counter may span across widened data elements in two or more of the vector destination registers. Either way, using a single predicate register to control predication of multiple vector destination registers allows the number of predicate registers encoded in the instruction encoding to be less than the number of vector destination registers, saving encoding space in the instruction encoding. The number of vector destination registers specified by the widening vector load instruction can vary. Some examples may support a two-register variant of the widening vector load instruction. Other examples may support three-register and / or four-register versions of the instruction, or could support further vector destination registers. A de-interleaving variant with two vector destination registers could be useful for handling de-interleaving of real and imaginary parts of complex numbers stored in interleaved fashion in memory. A de-interleaving variant with three vector destination registers can be useful for supporting operations on packed image data in RGB format. A de-interleaving variant with four vector destination registers can be useful for supporting operations on packed image data in RGBA format. On the other hand, regardless of whether the variant is de-interleaving or non-de-interleaving, supporting more than two vector destination registers can help to increase the memory throughput, allowing fewer vectorised loop iterations to be processed for a given amount of data. Where more than one variant of the instruction is supported corresponding to different numbers of vector destination registers, the respective variants of the instruction can be distinguished by their instruction opcodes or by another field of the instruction identifying the number of vector destination registers. In some examples, the widening vector load instruction may permit the loaded at least one vector of data elements to have a total size greater than or equal to twice the given vector length. For example, this could be useful for an implementation which loads and de-interleaves packed RGBA data into four vector destination registers with a 2x widening operation, so that the result is that two vector’s worth of data (i.e. data of a size twice the given vector length) is loaded and widened into four vector operands each corresponding to a single channel. By enabling more than one vector length of data to be loaded in a single instruction, memory throughput can be increased. Some implementations may support a fixed definition for the first data element size and the second data element size (e.g. with a fixed ratio between the first data element size and second data element size, e.g. with the second data element size being twice or four times the first data element size). However, in some examples, at least one of the first data element size and the second data element size is variable depending on at least one control parameter associated with the widening vector load instruction. For example, this control parameter could comprise one or more of: the opcode of the instruction, a field of the instruction encoding for specifying element size information; and / or parameter stored in a control register for specifying element size information. For example, variants of the instruction corresponding to different settings of the control parameter could be provided for supporting two-times and / or four-times widening operations, and for operating on different sized elements in memory. For example, variants could be provided for cases where the first data element size and second data element size are 8 and 16 bits respectively, 8 and 32 bits respectively and / or 16 and 32 bits respectively, say. In some implementations, the given vector length may be implicitly defined as a fixed value in the instruction set architecture. In other examples, the given vector length may be variable, based on a parameter associated with the widening vector load instruction. However, it can be useful for the apparatus to comprise vector length storage circuitry to store a vector length parameter indicative of the given vector length. This can help to support vector-length-agnostic software written according to a scalable vector instruction set architecture, where the given vector length used for execution of the widening vector load instruction is unknown at compile time, so that the same software could execute on different processing platforms (implementing different vector lengths as the given vector length), but instruction such as loop control instructions may adapt their operation to the implemented vector length based on the given vector length read from the vector length storage circuitry. In some examples, the apparatus comprising the instruction decoding circuitry and issue circuitry may also comprise the processing circuitry controlled by the issue circuitry to perform the operation corresponding to the widening vector load instruction. However, in other examples, for at least a subset of types of instruction, the issue circuitry may issue the at least one micro-operation corresponding to the widening vector load instruction to off-chip processing circuitry on a separate integrated circuit to the issue circuitry. Hence, it is not essential that the processing circuitry which performs the operation in response to the widening vector load instruction is part of the same apparatus as the instruction decoding circuitry and issue circuitry which decodes the widening vector load instruction and issues one or more corresponding micro-operations. For example, the off-chip processing circuitry may comprise a co-processor to which the main processor comprising the instruction decoding circuitry and issue circuitry may offload operations, where the co-processor could be implemented on a separate chiplet to the instruction decoding / issuing circuit logic of the main processor. In some examples, the apparatus may comprise a co-processor configured to perform processing operations for a subset of instruction types offloaded by a main processor, and the co-processor may comprise the instruction decoding circuitry for decoding instructions of said subset of instruction types and the issue circuitry. The coprocessor could be located on the same chip as the main processor or on a different chip compared to the main processor. For the subset of instruction types offloaded to the co-processor, that co-processor may have its own internal instruction decoding circuitry and issue circuitry, and so the techniques discussed above could also be implemented within the co-processor. Hence, there are a variety of use cases where instruction decoding circuitry and issue circuitry may be provided supporting the widening vector load instruction. The techniques discussed above may be implemented within an apparatus which has hardware circuitry provided for implementing the instruction decoding circuitry, issue circuitry (and if provided in the same apparatus, processing circuitry) as discussed above. However, the same technique can also be implemented within a computer program which executes on a host data processing apparatus to provide an instruction execution environment for execution of target code. Such a computer program may control the host data processing apparatus to simulate the architectural environment which would be provided on a hardware apparatus which actually supports target code according to a given instruction set architecture, even if the host data processing apparatus itself does not support that architecture. The computer program may have instruction decoding program logic which emulates functions of the instruction decoding circuitry discussed above, and processing program logic which performs a processing operation corresponding to a given instruction decoded by the instruction decoding program logic. For example, the instruction decoding program logic may comprise if / then statements to control selection, in response to a given instruction of the target code, of a corresponding sequence of code (part of the processing program logic) written in the native instruction set of the host data processing apparatus, where execution of that sequence of code would control the host data processing apparatus to perform the operations corresponding to the decoded instruction. The instruction decoding program logic and processing program logic support a widening vector load instruction as discussed above, which causes a corresponding load / widening operation (with de-interleaving) to be performed by the processing program logic. However, registers and memory address space expected to be provided in the target program code’s instruction set architecture may not actually be provided in the host apparatus. Therefore, such registers and memory address space may be simulated by mapping them onto the host’s storage circuitry (e.g. registers and memory of the hots apparatus). Hence, in the simulation embodiment, the load target address represents an address in a simulated address space (which may differ from the address space used to access host memory of the host data processing apparatus) and the vector destination registers may be emulated using corresponding regions of the host storage circuitry rather than being mapped to any specific hardware register file. Such a simulation computer program can be useful, for example, when legacy code written for one instruction set architecture is being executed on a host processor which supports a different instruction set architecture. Also, the simulation can allow software development for a newer version of the instruction set architecture to start before processing hardware supporting that new architecture version is ready, as the execution of the software on the simulated execution environment can enable testing of the software in parallel with ongoing development of the hardware devices supporting the new architecture. The simulation program may be stored on a storage medium, which may be an non-transitory storage medium. Figure 1 schematically illustrates an example of a data processing apparatus 2. The data processing apparatus has a processing pipeline 4 which includes a number of pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8; a decode stage 10 (an example of instruction decoding circuitry) for decoding the fetched program instructions to generate micro-operations (decoded instructions) to be processed by remaining stages of the pipeline; an issue stage 12 (an example of issuing circuitry) for checking whether operands required for the micro-operations are available in registers 14 and issuing micro-operations for execution once the required operands for a given micro-operation are available; an execute stage 16 (an example of processing circuitry) for executing data processing operations corresponding to the micro-operations, by processing operands read from the registers 14 to generate result values; and a writeback stage 18 for writing the results of the processing back to the registers 14. It will be appreciated that this is merely one example of possible pipeline arrangement, and other systems may have additional stages or a different configuration of stages. For example, in an out-of-order processor a register renaming stage could be included for mapping architectural registers specified by program instructions or micro-operations to physical register specifiers identifying physical registers in the registers 14. In some examples, there may be a one-to-one relationship between program instructions decoded by the decode stage 10 and the corresponding microoperations processed by the execute stage. It is also possible for there to be a one-to-many or many-to-one relationship between program instructions and micro-operations, so that, for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused to be processed as a single micro-operation. The execute stage 16 includes a number of processing units, for executing different classes of processing operation. For example the execution units may include a scalar processing unit 20 (e.g. comprising a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from the registers 14); a vector processing unit 22 for performing vector operations on vectors comprising multiple vector elements; and a load / store unit 28 for performing load / store operations to access data in a memory system 8, 30, 32, 34. Other examples of processing units which could be provided at the execute stage could include a floating-point unit for performing operations involving values represented in floating-point format, or a branch unit for processing branch instructions. The registers 14 include scalar registers 25 for storing scalar values, vector registers 26 for storing vector values, and predicate registers 27 for storing predicate values. The predicate values 27 may be used by the vector processing unit 22 when processing vector instructions, with a predicate value in a given predicate register indicating which vector elements of a corresponding vector operand stored in the vector registers 26 are active (non-masked) vector elements or inactive (masked) vector elements (where operations corresponding to inactive data elements may be suppressed or may not affect a result value generated by the vector processing unit 22 in response to a vector instruction). A memory management unit (MMU) 36 controls address translations between virtual addresses (specified by instruction fetches from the fetch circuitry 6 or load / store requests from the load / store unit 28) and physical addresses identifying locations in the memory system, based on address mappings defined in a page table structure stored in the memory system. The page table structure may also define memory attributes which may specify access permissions for accessing the corresponding pages of the address space, e.g. specifying whether regions of the address space are read only or readable / writable, specifying which privilege levels are allowed to access the region, and / or specifying other properties which govern how the corresponding region of the address space can be accessed. Entries from the page table structure may be cached in a translation lookaside buffer (TLB) 38 which is a cache maintained by the MMU 36 for caching page table entries or other information for speeding up access to page table entries from the page table structure shown in memory. In this example, the memory system includes a level one data cache 30, the level one instruction cache 8, a shared level two cache 32 and main system memory 34. It will be appreciated that this is just one example of a possible memory hierarchy and other arrangements of caches can be provided. The specific types of processing unit 20 to 28 shown in the execute stage 16 are just one example, and other implementations may have a different set of processing units or could include multiple instances of the same type of processing unit so that multiple micro-operations of the same type can be handled in parallel. It will be appreciated that Figure 1 is merely a simplified representation of some components of a possible processor pipeline arrangement, and the processor may include many other elements not illustrated for conciseness. Figure 2 illustrates sets of architectural registers available for referencing by instructions encoded according to the instruction set architecture (ISA) supported by the processing system 2. Figure 2 does not show the physical register files provided in hardware for implementing these architectural registers, but merely shows which registers are logically available for referencing by instructions. The particular mapping of the architectural registers logically referenced by instructions onto physical storage within the physical register file(s) 14 can be implemented in many different ways (e.g. with a one-to-one mapping between architectural registers and physical registers in an in-order processor or a variable mapping between architectural registers and physical registers controlled by register renaming in an out-of-order processor). In this example, the ISA supports: • a general purpose register set 25 comprising general purpose scalar registers for specifying scalar operands for scalar processing operations; • a vector register set 26 comprising vector registers for specifying vector operands for vector processing operations, matrix operations or other SI MD operations; • a predicate register set 27 comprising predicate registers for specifying predicate values for predicating vector, matrix or other SI MD operations; and • a set of control registers 40 for storing control values for controlling operation of the processing apparatus 2. Information stored in the control registers may be set automatically in response to certain events, or can be programmable based on execution of a system register updating instruction. In this example, the ISA supported by the processing apparatus 2 is a scalable vector ISA (also known as a “vector length agnostic” vector ISA) supporting vector instructions operating on vectors of scalable vector length to enable the same instruction sequence to be executed on apparatuses with hardware supporting different maximum vector lengths. This allows different hardware designers of processor implementations to choose different maximum vector lengths depending on whether their design priority is high-performance or reduced circuit area and power consumption, while software developers need not tailor their software to a particular hardware platform as the software written according to the scalable vector ISA can be executed across any hardware platform supporting the scalable vector ISA, regardless of the particular maximum vector length supported by a particular hardware platform. Hence, the vector length to be used for vector registers 26 accessed by a particular vector instruction of the scalable vector ISA (and hence also the predicate length of the corresponding predicate registers 27) is unknown at compile time (neither defined to be fixed in the ISA itself, nor specified by a parameter of the software itself). The operations performed in response to a given vector instruction of the scalable vector ISA may differ depending on the vector length chosen for a particular hardware implementation (e.g. hardware supporting a greater maximum vector length may process a greater number of vector elements for a given vector instruction than hardware supporting a smaller maximum vector length). An implementation with a shorter vector length may therefore require a greater number of loop iterations to carry out a particular function than an implementation with a longer vector length. The vector length agnostic property of the scalable vector ISA is useful because within a fixed encoding space available for encoding instructions of the ISA, it is not feasible to create different instructions for every different vector length that may be demanded by processor designers, when considering the wide range of requirements scaling from relatively small energy-efficient microcontrollers to servers and other high-performance-computing systems. By not having a fixed vector length known at compile time, multiple markets can be addressed using the same ISA, without effort from software developers in tailoring code to each performance / power / area point. To achieve the scalable property of the scalable vector ISA, the functionality of the vector instructions of the scalable vector ISA is defined in the architecture with reference to a parameter (e.g. VL 43 or SVL 42 as shown in Figure 2, described in more detail below) which indicates the vector length in use (when considering the maximum vector length supported in hardware and any software-defined limitations using the control registers 40), where that parameter VL or SVL is unknown at compile time. Hence, execution of the same vector instruction on different systems may produce different results (typically varying in terms of the number of vector elements generated, a subset of which may have the same result values on different platforms, but in general platforms implementing a greater vector length may generate additional vector elements in comparison with a platform implementing a smaller vector length). Predicate values defined in the predicate registers 27 may be used to control which elements are generated in a given instance of an instruction and can be set based on vector length agnostic principles such as by using comparison instructions to automatically generate the values of predicate for a particular loop iteration or applying some generally-defined predicate pattern which can scale to different vector lengths. Certain instructions may update loop control parameters such as an element count value to track how many vector elements have been processed so far, so that across all iterations of a loop as a whole both implementations with wider and narrow vector lengths may eventually achieve the same results but with different levels of performance, since the implementation with a wider vector length may require fewer loop iterations than an implementation with a narrower vector length. This particular example of an ISA also supports two different modes for executing vector operations: a non-streaming mode of operation and a streaming mode of operation. Mode indicating state information 41 stored in the control registers 40 indicates whether the current mode is the non-streaming mode or streaming mode, and can be set in response to execution of a mode changing instruction. Scalar operations using the general purpose registers 25 may be processed in the same way regardless of whether the current mode is the non-streaming mode or the streaming mode, but operations using the vector registers 26 and predicate registers 27 may be processed differently depending on whether the current mode is the streaming mode or the non-streaming mode. In the non-streaming mode, vector registers 26 are architecturally designated as having a vector register length VL identified by a non-streaming vector length specifying value 43 specified in the control registers 40, and the predicate registers 27 are architecturally designated as having a register length VL / X, where X is a constant corresponding to a minimum vector element size supported (e.g. X may equal 8 for an implementation where the smallest vector element size is 8 bits). In the streaming mode, vector registers 26 are architecturally designated as having a streaming mode vector length SVL identified by a streaming vector length specifying value 42 specified in the control registers 40 (the streaming vector length specifying value 42 being separate from the non-streaming vector length specifying value 43), and the predicate registers 27 are architecturally designated as having a register length SVL / X. Hence, both the vector registers 26 and predicate registers 27 may logically be seen as changing register length when there is a change of mode between the streaming mode and the non-streaming mode. Both the non-streaming vector length specifying value 43 and streaming mode vector length specifying value 42 may be implemented in different ways. In some examples, these vector length specifying values 43, 42 could simply be a hardwired piece of state information which is not programmable by software, and simply indicates the maximum register length supported for each mode by the hardware. This can then be read by software to identify the particular vector length implemented on the hardware executing the program, so that the same software can execute with different vector lengths on different hardware. In other examples, the ISA may support more privileged software being able to limit the maximum vector length which is usable by software executing in a less privileged state. For example, to save power a given piece of software could be limited so that it cannot make use of the full vector length supported in hardware. Hence, the vector length specifying values 43, 42 could include information settable by software, to specify the vector length to be used in each mode. Nevertheless, even if the more privileged software applies a limit on vector length, the vector length for the application software is still unknown at compile time because it will not be known whether the actual implemented vector length in a particular processor will be greater or less than the limit defined in the length specifying value 43, 42. For implementations with hardware supporting a smaller maximum vector length than the limit defined in the length specifying value 43, 42, a smaller vector length than indicated by the limit will actually be used. For example, the effective vector length seen by software may correspond to the minimum of the maximum vector length supported in hardware for the current mode and the vector length limit set by software. The vector length specifying values 43, 42 may be banked per exception level so that different limits on maximum vector length supported may be specified for software executing in different exception levels (e.g. software at one exception level may be allowed to use a longer vector length than software at another exception level). Hence, there can be a variety of ways in which control state information stored in the control registers 40 may influence the vector length useful vector operations, but in general some state information is available which can enable software to determine the effective vector length used for each mode. Hence, a given vector length is defined for the vectors associated with a given vector instruction to be executed. It can be useful to support both the non-streaming modes and streaming modes, as this can provide greater flexibility for hardware microarchitecture designers to support different hardware implementations as shown in Figures 3 and 4 for example. In the example of Figure 3, the vector instructions are executed by processing circuitry 16 of a main processor 2, without any operations being offloaded to a coprocessor. On the other hand, in the example of Figure 4, a coprocessor 50 is provided for executing a particular subset of vector operations using the vector registers 26 and predicate registers 27. The coprocessor 50 may comprise coprocessor decode circuitry 52 for decoding instructions issued to the coprocessor 50 by issue circuitry 12 of the main processor 2, and coprocessor issue circuitry 54 for receiving the decoded microoperations from the coprocessor decode circuitry 52 and determining when operands for those instructions will be available and issuing the micro-operations to coprocessor processing circuitry 56 when the operands are available. The coprocessor 50 may have its own register storage 58 separate from the register storage 14 and the main processor 2. The coprocessor 50 may have access to the shared memory system shared with the main processor 2 and so can execute vector load / store instructions to load / store data from / to memory (for example, the coprocessor 50 may have access to one or more of the main processor’s data caches 30, 32 and may access main memory 34). The coprocessor processing circuitry 56 executes the load / store and computation operations represented by the instructions offloaded to the coprocessor 50 by the main processor 2, with reference to operands stored in the coprocessor register storage 58 and data accessed from the memory system. The architecturally defined streaming mode of processing and separate vector length indicating values 42, 43 for the respective modes makes it simpler for the hardware to determine when instructions requiring vector registers should be offloaded to the coprocessor 50 or executed within the local execution units 16 of the main processor 2. It also allows software to explicitly designate whether a particular workload would be more suited for execution on the general purpose execution units 16 of the processor 2 or on the more bespoke hardware of the coprocessor 50. This can be useful because for vector processing routines requiring smaller vectors and / or workloads where vector operations are interspersed with scalar operations, it may be more appropriate for the vector operations to be processed on the general purpose execution units 16 local to the processor 2 itself, while the coprocessor 50 may be more suited to processing “streaming” workloads which require high throughput of vector operations on large datasets with relatively little need for intervening scalar operations (e.g. workloads associated with machine learning applications such as neural network processing). For such streaming workloads, longer vector lengths may be useful to reduce the instruction fetch / decode overhead associated with processing a given number of vector elements. Hence, although the ISA does not require it (the vector length for non-streaming mode may be selected from among a certain set of vector lengths supported, and the streaming mode vector length may be selected from among a second set of vector lengths supported, with no fixed relation between the length selected for non-streaming mode and streaming mode), in implementations which choose to provide a coprocessor 50 for supporting the streaming vector mode, it is relatively likely that the streaming mode vector length may be greater than the nonstreaming mode vector length, in some cases many times greater. As just one example (other lengths can also be used), an implementation might choose to implement a maximum vector length of 128 bits in the non-streaming mode and 512 bits in the streaming mode, with the predicate registers therefore having an architectural vector length of 16 bits in the nonstreaming mode and 64 bits in the streaming mode. In the example using a coprocessor 50 shown in Figure 4, the coprocessor 50 could be either on the same chip (integrated circuit) as the main processor 2, or on a separate chip. For example, the main processor 2 and coprocessor 50 may be implemented a separate chiplets on an interposer, each chiplet being manufactured as a separate component and then assembled on the interposer. Hence, when considering instruction decoding circuitry, issue circuitry and processing circuitry for implementing the widening vector load instruction mentioned in this application, a number of different implementations are possible, including: • a first example where the instruction decoding circuitry 10, issue circuitry 12 and processing circuitry 16 are all provided within a processor 2 as shown in Figure 3. • a second example where the instruction decoding circuitry 10 and issue circuitry 12 are in the main processor 2, but the processing circuitry which executes the widening vector load instruction is (at least in some operating modes, such as the streaming mode described above) the coprocessor processing circuitry 56 in the coprocessor 50, which could be either on the same integrated circuit as the main processor 2 or could be off-chip processing circuitry 56 on a separate integrated circuit from the main processor 2. In other operating modes (e.g. the non-streaming mode), the processing circuitry which executes the widening vector load instruction could be the processing circuitry 16 of the main processor 2 as in the first example. • a third example as shown in Figure 4 where the responsibility for decoding the widening vector load instruction into one or more micro-operations lies with the coprocessor decode circuitry 52, and so the apparatus handling the widening vector load instruction can be considered to be the coprocessor 50 which may or may not be on the same chip as the main processor 2. In this case, the instruction decoding circuitry, issue circuitry and processing circuitry may be the coprocessor decode circuitry 52, coprocessor issue circuitry 54 and coprocessor processing circuitry 56 respectively. As it is possible that the processing circuitry which actually executes the operations for the widening vector load instruction could be on a different chip to the instruction decoding circuitry 10, 52 and issue circuitry 12, 54 that decodes and issues the widening vector load instruction, it is not essential for the processing circuitry 16, 56 itself to be in the same apparatus as the instruction decoding circuitry 10, 52 and issue circuitry 12, 54. While the example of Figure 2 discussed a scalable vector ISA, the widening vector load instruction described in this patent application can also be applied to a non-scalable vector ISA for which the vector length is known at compile time (either being fixed in the architecture, or being variable based on a software-specified parameter). Also, while a scalable vector ISA supporting separate non-streaming and streaming modes is described above, the widening vector load instruction could also be provided in a scalable vector ISA not supporting the streaming mode, so that mode indication 41 and streaming vector length parameters 42 are not provided, and the given vector length to be used for vector instructions is defined by VL parameter 43. Figure 5 shows an example of a de-interleaving variant of the widening load instruction. As shown in Figure 5, it can be relatively common in image processing workloads for pixel data to be stored in memory as interleaved channels of data elements, e.g. as RGB data (red, green, blue) for each pixel position, or RGBA data (red, green, blue, alpha) for each pixel position, with the alpha channel indicating opacity. Figure 5 shows an example with four interleaved channels for RGBA data. Image data comprising RGB or RGBA data is just one example of a packed interleaved structure, and it will be appreciated that the widening load instruction could also be used for processing other kinds of data structures. When a processing kernel is to be applied to such a packed data structure, it can be common to load a bunch of data elements (e.g. pixels), de-interleave channels to form separate operands each comprising data elements for a single one of the channels, and pad the data to process it as a wider data type. For example, 8-bit pixel data stored in memory may be widened to 16 bits per data element, to allow for processing at higher precision. However, existing vector architectures may be inefficient at processing this type of operation. One approach can be to use non-widening vector load instructions to load the packed multi-channel data into first set of vector registers without any widening being applied at the time of the load, and then to execute a separate register-to-register permute instruction specifying an index vector operand, which controls a permute unit to rearrange the loaded data elements from the first set of vector registers into a further set of vector registers, with each element of the index vector operand corresponding to a portion of the further set of vector registers and specifying which portion of the first set of vector registers should provide the data value to be stored in that further set of vector registers (the index vector operand can specify that zeroes should be inserted in some portions of the further set of vector registers to pad the narrower loaded elements to a wider data element size). However, a problem with this approach is that such a generic permute instruction capable of any arbitrary permutation can be expensive to implement in hardware logic and performance cost of manipulating the arbitrary register-to-register rearrangements. Also, it is difficult to write vector-length-agnostic software using the general purpose permute instruction, as the index values in the index vector operand would need to be pre-computed in software for a specific vector length, so they cannot scale gracefully in hardware with the vector length selected based on VL 43 or SVL 42 as described above. This makes software development more complex. Another problem is that the nonwidening vector load uses a first set of architectural vector registers as destination registers and the subsequent permute instruction uses a further set of architectural vector registers as destination registers, and so this increases register pressure as it means that the software will be sooner to run out of spare architectural vector register identifiers available for identifying new variables, which can reduce performance due to increased memory operations to spill variables out to memory that could not fit in the architectural register space. Another problem with some existing approaches is that load instructions which support widening of data elements from a first date element size to a second (larger) data element size generally write to a single destination register, and so as the widening causes fewer elements to fit in one destination register, the memory throughput (number of memory-based data elements processed per load instruction) is reduced compared to an equivalent non-widening load instruction. To compensate and maintain equivalent memory throughput, software may execute multiple load instructions per loop iteration, but this causes complexity in predicating the loads, as the presence of multiple distinct loads per loop iteration makes it more awkward to write predicates for a single loop iteration that can cause a partial vector to be marked as inactive based on a count of how many elements have been processed so far halt once a certain number of elements has been processed, and so many software implementations may instead choose to implement a main loop with processing of a certain number of fully active vectors of elements followed by a separate tail loop to mop up the remaining tail of elements that could not occupy a full vector. Such tail loops reduce performance as they require additional instructions to be executed in addition to the main loop. Also, executing multiple load instructions per loop iteration consumes additional memory control bandwidth (e.g. required increased numbers of memory translation requests at the MMU 36, increased consumption of load / store unit slots within the load / store unit 28, and / or increased churn in outsourcing memory accesses to the coprocessor 50 for an embodiment where the coprocessor 50 is supported). These issues can be addressed by providing, as an instruction supported in the instruction set architecture, a de-interleaving widening vector load instruction which specifies at least one address operand for defining a target memory address for a load operation, and specifies multiple vector destination registers 26. The instruction can also specify predicate information, for example using a predicate register 27. The function of the instruction is to cause processing circuitry 16, 56 to load at least one vector of data elements having a first data element size from a location in memory corresponding to the target memory address (subject to predication, the loaded elements are obtained from a contiguous region of memory starting from the target memory address), widen the data elements to a wider second data element size, and de-interleaving the multiple channels of loaded data into separate destination registers each providing widened data elements for one of the channels. Hence, in the example of Figure 5, the instruction specifies 4 destination vector registers Z1-Z4 and is used to de-interleave four interleaved channels of data elements of a first data element size (e.g. 8 bits), such as interleaved RGBA data for an image, to provide 4 respective vectors in the 4 destination registers each representing a single channel of data (e.g. R, G, B or A respectively) with an expanded second data element size (e.g. 16 bits). Each destination register has the given vector length VL, SVL currently in use for the vector processing operations. Hence, for the de-interleaving variant, contiguously located elements obtained from memory are striped across the respective destination vector registers to de-interleave them into separate channels. If predication is applied, then the predicate value controls predication at granularity of element groups. As shown in Figure 5, each element group comprises a contiguous block of data elements in the memory based structure, each element group comprising a single data element from each of the channels. If a given element group is indicated as masked by the predicate, the corresponding positions in the vector destination registers are set to a value independent of the masked data elements. For example, the element group starting at element R2 in Figure 5 is marked as inactive (in this example using a “0” in the predicate mask), and so the portions of the vector destination registers Z1-Z4 corresponding to that element group (marked with in Figure 5) are set independent of the values of those masked elements. For example, the masked regions of the destination registers can be set to 0 (zeroing predication) or can retain the previous value of the corresponding portion of the destination registers (merging predication). While Figure 5 shows an example using a bit mask as the predicate value, other examples could use a predicate counter which indicates the boundary between the active elements and masked elements. For the de-interleaving variant of the instruction, the counter counts at granularity of element groups so that, in the particular example shown in Figure 5, the counter could specify a value of 2 to indicate that the first 2 element groups starting from the target memory address are active and subsequent element groups are masked. For example, the widening vector load instruction could specify various operands, such as: Id4b{z1.h-z4.h}, pO / z, [x17, x16] Of course, the instruction encoding seen by the instruction decoding circuitry 10, 52 would comprise a binary value encoded to represent the corresponding information. Here, Id4b represents the type of instruction (a 4-register de-interleaving widening vector load instruction), and can correspond to the opcode encoded in the binary encoding. The register identifiers z1-z4 identify the four destination vector registers. In some examples, these could all be explicitly identified in the instruction encoding, or alternatively the instruction may be constrained to select as destination registers a group of vector registers having adjacent register identifiers, and only one of these register identifiers may be explicitly encoded in the instruction encoding, with others implicitly being at certain offsets relative to the encoded register identifier. The notation .h represents that the second data element size to be used for the widened data elements is “halfword” size (16 bits) (as opposed to byte size .b (8 bits) or fullword size .w (32 bits)). In this example, it is implicit that the first data element size for the data in memory is 8 bits, but other examples could include an operand for identifying the first data element size. The predicate register identifier pO identifies the predicate register providing the predicate value. The suffix / z represents that this instruction is to use zeroing predication (rather than merging predication), but other examples may not support both of these options and so the type of predication could be implicit. The register identifiers x17 and x16 represent address operands used to identify the target memory address (e.g. x17 can identify a base register and x16 can identify a register used to specify an offset to be added to the value stored in the base register to generate the target address). It will be appreciated that this is just one example of an addressing mode and any other addressing mode could also be used (e.g. other examples could use an immediate value, program counter value, and / or stack pointer value as one of the address operands). Hence, when the instruction is decoded by the instruction decoding circuitry 10, 52, the instruction decoding circuitry 10, 52 generates at least one micro-operation which when issued by issue circuitry 12, 54 causes the processing circuitry 16, 56 to load the data elements from memory, widen them to the second data element size from the first data element size (e.g. by padding with 0s as shown for element A0 in Figure 5), de-interleave the elements and write the de-interleaved widened elements to the destination registers. The particular micro-operations generated for this instruction can vary depending on the specific implementation, so could include a combined micro-operation for which the load and widening / de-interleaving are handled by a single functional unit comprising both the load stage and the permute stage, or could be split into separate micro-operations directed to a load / store unit and permute unit respectively. The widening and de-interleaving operations could be performed separately in either order, or could be combined into a single permutation operation (as the permutation to control the de-interleaving could also support injecting 0s at the upper portions of each element of the first data element size, to expand the element to the second data element size). While Figure 5 shows an example where elements are widen by padding with 0s, it will be appreciated that if the instruction was processed using signed data values, the widening could comprise sign-extending the data to increase the width of each data element. While Figure 5 shows a four-destination-register example of the instruction, it will be appreciated that other variants could write to a different number of vector registers (e.g. a three-register variant could be provided for handling RGB interleaved data, or a two-register variant could be provided for handling two interleaved channels). Also, variants can be provided to support different element sizes for the first and second data element size, possibly with different ratios between the second data element size and first data element size (e.g. a 4x widening rather than a 2x widening). The 8-bit to 16-bit widening example shown above is just one example and other examples could vary the data element size for one or both of the first / second data element size based on a programmable parameter referenced by the instruction (either in the instruction encoding itself, or in a control register, or a combination of both). Using this type of instruction can provide several advantages. It can support more flexible micro-architectural implementations than would be possible in ISAs where the load, widening and de-interleaving have to be split into at least two separate architectural instructions, as the provision of a single instruction for load, widening and de-interleaving expresses an intent that these operations are to be performed as a single operation, enabling use of specialized pipelines which can pass the result of the load direct to the permute unit without use of an intervening temporary register. By allowing a single load operation to write to multiple vector registers while also widening, this maintains memory throughput without consuming multiple MMU lookups per loop iteration and also simplifies predication reducing the need for tail loops to handle a tail of remaining elements, and so improving performance for code using the instruction. Also, while the instruction can be used in both non-scalable and scalable vector ISAs, it can be particularly helpful in scalable vector ISAs as the implicitly defined deinterleaving permute operation avoids the need to specify any index vector for controlling the permutation and so avoids the need for precomputation of index values (which would require specific non-vector-length agnostic code to be written). Therefore, this type of instruction can allow the operation to scale to any vector length without requiring platform-specific code to be developed. Figure 6 shows a non-de-interleaving variant of the widening vector load instruction. In this example, similar to Figure 5, the instruction causes a set of data elements to be loaded from memory and widened to a second data element size larger than the first data element size with which the data elements are represented in the memory based data structure, but unlike in Figure 5, there is no de-interleaving and so the order of the widened data elements in the destination vectors remains the same as in the memory-based structure. Hence, the first vector destination register Z1 comprises widened data elements corresponding to a first contiguous block of data elements Ro to Ai loaded from memory, the next vector destination register Z2 comprises widened data elements corresponding to a second contiguous block of data elements R2 to A3, and so on (subject to predication which, as shown in the example of Figure 6, may mask out some of these elements as inactive, causing the corresponding portions marked with “ in Figure 6 to be set to 0 or remain at the previous value of the corresponding portions of the destination registers). In the example of Figure 6, predication is applied at granularity of individual data elements, rather than at granularity of element groups as in Figure 5. The example of Figure 6 can be useful for processing workloads where, rather than processing individual channels from an interleaved structure, the multi-channel data is to be processed collectively so that it is useful to keep each element group together in the destination registers. Also, this can allow the non-de-interleaving variant of the instruction to be applied to single-channel data structures which do not comprise interleaved channels of data. Similar to the example of Figure 5, the widening vector load instruction of Figure 6 writes to multiple destination registers and so enables at least one vector’s worth of data (each vector having a size corresponding to the given vector length VLISVL) to be obtained from memory in a single instruction, despite the widening causing each destination register to accept fewer destination registers. For example, if the given vector length in use is 128 bits, for a 2-register version of the instruction and a 2x widening ratio, this will mean that the size of the block of data loaded from memory when all elements are active is also 128 bits, so that the widening load instruction has not sacrificed any memory throughput compared to a standard non-widening load writing to a single vector register. Other examples could support more than 2 destination registers and could have other ratios between the first / second data element sizes. Hence, in some examples, multiple vectors of data could be loaded from memory (each of the given vector length VL, SVL), so that the loaded amount of data can corresponding to 2 or more times the given vector length VL, SVL. Figure 7 shows a method of performing data processing. At step 100, instruction decoding circuitry 10, 52 decodes an instruction that is encoded according to a given instruction set architecture. At step 102, in response to decoding of the instruction by the instruction decoding circuitry 10, 52, issue circuitry 12, 54 issues at least one micro-operation corresponding to the instruction. At step 104, processing circuitry 16, 56 performs a corresponding processing operation in response to the at least one micro-operation. Figure 8 illustrates steps performed for the processing operation performed at step 104 when the instruction decoded at step 100 is a widening load instruction. At step 110, the processing circuitry 16, 56 loads at least one vector of data elements from memory locations corresponding to a target memory address computed based on at least one address operands of the widening load instruction. At step 112, the processing circuitry 16, 56 widens the loaded data elements from a first data element size to a second data element size greater than the first data element size. At step 114, the processing circuitry 16, 56 writes the widened data elements to two or more vector destination registers as respective vector operands having the given vector length VL, SVL currently in use. Figure 9 illustrates steps performed for the processing operation performed at step 104 when the instruction decoded at step 100 is a de-interleaving variant of the widening load instruction. At step 120, the processing circuitry applies predication at granularity of element groups, based on at least one predicate value specified as an operand of the widening load instruction. An element group comprises one data element per channel, for an interleaved multichannel structure of data elements such as the one shown in Figure 5. Based on the predication, one or more element groups comprising masked data elements are identified. At step 122, the processing circuitry loads at least one vector of data elements having the first data element size from memory locations corresponding to a target memory address computed from at least one address operand of the instruction. Load requests can be suppressed in respect of portions of the memory range referenced by the instruction that correspond to masked data elements identified at step 120, to prevent memory faults being triggered by accesses that go past a page boundary into regions which do not correspond to the data structure being accessed. Alternatively, a load request can be generated specifying an access corresponding to the full vector width regardless of predication, but if it is found that page faults would arise for data elements marked as masked by the predicate, the fault handling response for such masked data elements can be suppressed, and any loaded data associated with the masked data can be discarded without writing it to the destination vector registers. At step 124, the processing circuitry 16, 56 de-interleaves and widens multiple channels of data elements within the loaded vector(s), to generate separate individual channels of widened data elements having the second data element size. The de-interleaving and widening operations could be performed as a single permute operation carrying out both functions, or could be implemented sequentially either with de-interleaving performed before widening or with widening performed before deinterleaving, depending on the circuit implementation. At step 126, the widened data elements are written to two or more vector destination registers as respective vector operands having the given vector length VL, SVL. Portions of the destination registers corresponding to masked data elements are set to a value independent of those masked data elements that would otherwise have had their widened version written to those portions. For example, the masked portions of the destination registers can be set to zero or may retain the value previously specified in those portions of the destination registers. Figure 10 illustrates steps performed for the processing operation performed at step 104 when the instruction decoded at step 100 is a non-de-interleaving variant of the widening load instruction. At step 130, the processing circuitry applies predication at granularity of individual data elements, based on at least one predicate value specified as an operand of the widening load instruction. Based on the predication, one or more individual data elements are identified as masked data elements. At step 132, the processing circuitry loads at least one vector of data elements having the first data element size from memory locations corresponding to a target memory address computed from at least one address operand of the instruction. Load requests can be suppressed in respect of portions of the memory range referenced by the instruction that correspond to masked data elements identified at step 130. Alternatively, a load request can be generated specifying an access corresponding to the full vector width regardless of predication, but if it is found that page faults would arise for data elements marked as masked by the predicate, the fault handling response for such masked data elements can be suppressed, and any loaded data associated with the masked data can be discarded without writing it to the destination vector registers. At step 134, the processing circuitry 16, 56 widens the loaded data elements (without de-interleaving), to generate widened data elements having the second data element size. At step 126, the widened data elements are written to two or more vector destination registers as respective vector operands having the given vector length VL, SVL. Again, either zeroing or merging predication can be used, so that the masked portions of the destination registers can be set to zero or may retain the value previously specified in those portions of the destination registers (in either case, the values in the masked portions are independent of the corresponding masked data elements of the data stored in memory). For the non-de-interleaving variant of the instruction, when all elements are active elements (without any elements being masked by predication) the elements written to a given one of the destination registers correspond to data elements stored at a contiguous block of memory addresses in the memory-based data structure. Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein. For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts. Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly. The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated. Such computer-readable code can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept. Figure 11 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 330 having host storage circuitry 332 (e.g. registers and / or memory), optionally running a host operating system 320, supporting the simulator program 310. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 IISENIX Conference, Pages 53 - 63. To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure stored in the host storage (e.g. memory or registers) of the host processor 330. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 330), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 310 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 300 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 310. Thus, the program instructions of the target code 300 may be executed from within the instruction execution environment using the simulator program 310, so that a host computer 330 which does not actually have the hardware features of the apparatus 2 discussed above (e.g. an instruction decoder 10 and processing circuitry 16 supporting the widening vector load instruction as discussed above) can emulate these features. Hence, the simulator program 310 may have instruction decoding program logic 312 for decoding instructions of the target code 300 and mapping these to corresponding sets of instructions in the native instruction set of the host apparatus 330 which are provided as part of processing program logic 313 of the simulator program. The instruction decoding program logic 312 includes decoding program logic 313 for decoding the widening vector load instruction as described above. Register emulating program logic 314 maps register accesses requested by instructions of the target code to accesses to corresponding data structures maintained in the host storage circuitry 332 of the host apparatus 330, such as by accessing data in registers or memory of the host apparatus 330. Memory management program logic 316 implements address translation, page table walks and access permission checking to simulate access to a simulated address space by the target code 300, in a corresponding way to the MMU 36 as described in the hardware-implemented embodiment above. Memory address space simulating program logic 318 is provided to map the simulated physical addresses, obtained by the memory management program logic 316 based on address translation using the page table information maintained by software of the target program code 300, to host virtual addresses used to access host memory of the host processor 330. These host virtual addresses may themselves be translated into host physical addresses using the standard address translation mechanisms supported by the host (the translation of host virtual addresses to host physical addresses being outside the scope of what is controlled by the simulator program 310). In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. In the present application, lists of features preceded with the phrase “at least one of” mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination. Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. An apparatus comprising:instruction decoding circuitry to decode instructions; andissue circuitry to issue, in response to decoding of a given instruction by the instruction decoding circuitry, at least one micro-operation to control processing circuitry to perform a processing operation corresponding to the given instruction; in which:in response to decoding of a widening vector load instruction specifying at least one address operand and a plurality of vector destination registers each for specifying a vector operand having a given vector length, the instruction decoding circuitry is configured to control the issue circuitry to issue at least one micro-operation to control the processing circuitry to:load at least one vector of data elements from a location in a memory system corresponding to a target memory address determined based on the at least one address operand;widen the data elements of the loaded at least one vector from a first data element size to a second data element size larger than the first data element size; andwrite the widened data elements having the second data element size to the plurality of vector destination registers as a plurality of respective vector operands;in which, in response to a de-interleaving variant of the widening vector load instruction, the instruction decoding circuitry is configured to control the issue circuitry to issue the at least one micro-operation to control the processing circuitry to de-interleave a plurality of interleaved channels of data elements obtained from the at least one vector, to cause each vector destination register to specify one or more widened data elements corresponding to a different channel of the plurality of interleaved channels;the de-interleaving variant of the widening vector load instruction specifies at least one predicate value specifying element predication information indicative of which data elements of the at least one vector are masked data elements for which corresponding portions of the plurality of vector destination registers are to specify a value independent of the masked data elements; andthe element predication information is specified by the at least one predicate value at granularity of element groups, each element group comprising one data element from each of the plurality of interleaved channels.

2. The apparatus according to claim 1, in which the widening vector load instruction permits the loaded at least one vector of data elements to have a total size greater than or equal to the given vector length.

3. The apparatus according to any of claims 1 and 2, in which a de-interleaving pattern for writing the widened data elements to the plurality of vector destination registers is implicitly defined by an encoding of the de-interleaving variant of the widening vector load instruction.

4. The apparatus according to any preceding claim, in which, in response to a non-deinterleaving variant of the widening vector load instruction, the instruction decoding circuitry is configured to control the issue circuitry to issue the at least one micro-operation to control the processing circuitry to write to a given one of the plurality of vector destination registers a set of widened data elements corresponding to data elements loaded from locations in the memory system corresponding to a contiguous block of memory addresses.

5. The apparatus according to claim 4, in which the non-de-interleaving variant of the widening vector load instruction specifies at least one predicate value specifying element predication information indicative of which data elements of the at least one vector are masked data elements for which corresponding portions of the plurality of vector destination registers are to specify a value independent of the masked data elements.

6. The apparatus according to claim 5, in which the element predication information specified by the non-interleaving variant of the widening vector load instruction is specified by the at least one predicate value at granularity of individual data elements of the at least one vector.

7. The apparatus according to any of claims 5 and 6, in which the non-de-interleaving variant of the widening vector load instruction specifies at least one predicate register, each predicate register specifying a predicate value specifying element predication information for controlling predication for two or more of the plurality of vector destination registers.

8. The apparatus according to any preceding claim, in which the plurality of vector destination registers comprise at least three vector destination registers.

9. The apparatus according to any preceding claim, in which the plurality of vector destination registers comprise at least four vector destination registers.

10. The apparatus according to any preceding claim, in which the widening vector load instruction permits the loaded at least one vector of data elements to have a total size greater than or equal to twice the given vector length.

11. The apparatus according to any preceding claim, in which at least one of the first data element size and the second data element size is variable depending on at least one control parameter associated with the widening vector load instruction.

12. The apparatus according to any preceding claim, comprising vector length storage circuitry to store a vector length parameter indicative of the given vector length.

13. The apparatus according to any preceding claim, comprising the processing circuitry.

14. The apparatus according to any preceding claim, in which, for at least a subset of typesof instruction, the issue circuitry is configured to issue the at least one micro-operation to off-chip processing circuitry on a separate integrated circuit to the issue circuitry.

15. The apparatus according to any of claims 1 to 13, comprising a co-processor configured to perform processing operations for a subset of instruction types offloaded by a main processor, the co-processor comprising the instruction decoding circuitry for decoding instructions of said subset of instruction types and the issue circuitry.

16. Computer-readable code for fabrication of an apparatus comprising:instruction decoding circuitry to decode instructions; andissue circuitry to issue, in response to decoding of a given instruction by the instruction decoding circuitry, at least one micro-operation to control processing circuitry to perform a processing operation corresponding to the given instruction; in which:in response to decoding of a widening vector load instruction specifying at least one address operand and a plurality of vector destination registers each for specifying a vector operand having a given vector length, the instruction decoding circuitry is configured to control the issue circuitry to issue at least one micro-operation to control the processing circuitry to:load at least one vector of data elements from a location in a memory system corresponding to a target memory address determined based on the at least one address operand, the at least one vector of data elements having a total size greater than or equal to the given vector length;widen the data elements of the loaded at least one vector from a first data element size to a second data element size larger than the first data element size; andwrite the widened data elements having the second data element size to the plurality of vector destination registers as a plurality of respective vector operands each having the given vector length;in which, in response to a de-interleaving variant of the widening vector load instruction, the instruction decoding circuitry is configured to control the issue circuitry to issue the at least one micro-operation to control the processing circuitry to de-interleavea plurality of interleaved channels of data elements obtained from the at least one vector, to cause each vector destination register to specify one or more widened data elements corresponding to a different channel of the plurality of interleaved channels;the de-interleaving variant of the widening vector load instruction specifies at least one predicate value specifying element predication information indicative of which data elements of the at least one vector are masked data elements for which corresponding portions of the plurality of vector destination registers are to specify a value independent of the masked data elements; andthe element predication information is specified by the at least one predicate value at granularity of element groups, each element group comprising one data element from each of the plurality of interleaved channels.

17. A method comprising:decoding instructions; andin response to decoding of a given instruction, issuing at least one micro-operation to control processing circuitry to perform a processing operation corresponding to the given instruction; in which:in response to decoding of a widening vector load instruction specifying at least one address operand and a plurality of vector destination registers each for specifying a vector operand having a given vector length, at least one micro-operation is issued to control the processing circuitry to:load at least one vector of data elements from a location in a memory system corresponding to a target memory address determined based on the at least one address operand, the at least one vector of data elements having a total size greater than or equal to the given vector length;widen the data elements of the loaded at least one vector from a first data element size to a second data element size larger than the first data element size; andwrite the widened data elements having the second data element size to the plurality of vector destination registers as a plurality of respective vector operands each having the given vector length;in which, in response to a de-interleaving variant of the widening vector load instruction, the at least one micro-operation is issued to control the processing circuitry to de-interleave a plurality of interleaved channels of data elements obtained from the at least one vector, to cause each vector destination register to specify one or more widened data elements corresponding to a different channel of the plurality of interleaved channels;the de-interleaving variant of the widening vector load instruction specifies at least one predicate value specifying element predication information indicative of whichdata elements of the at least one vector are masked data elements for which corresponding portions of the plurality of vector destination registers are to specify a value independent of the masked data elements; andthe element predication information is specified by the at least one predicate value at granularity of element groups, each element group comprising one data element from each of the plurality of interleaved channels.

18. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising:instruction decoding program logic to decode instructions of the target program code; andprocessing program logic to perform a processing operation corresponding to a given instruction decoded by the instruction decoding program logic; in which:in response to decoding of a widening vector load instruction specifying at least one address operand and a plurality of vector destination registers each for specifying a vector operand having a given vector length, the instruction decoding program logic is configured to control the processing program logic to:load at least one vector of data elements from a location in a simulated address space corresponding to a target memory address determined based on the at least one address operand, the at least one vector of data elements having a total size greater than or equal to the given vector length;widen the data elements of the loaded at least one vector from a first data element size to a second data element size larger than the first data element size; andwrite the widened data elements having the second data element size to host storage circuitry corresponding to the plurality of vector destination registers as a plurality of respective vector operands each having the given vector length;in which, in response to a de-interleaving variant of the widening vector load instruction, the instruction decoding program logic is configured to control the processing program logic to de-interleave a plurality of interleaved channels of data elements obtained from the at least one vector, to cause each vector destination register to specify one or more widened data elements corresponding to a different channel of the plurality of interleaved channels;the de-interleaving variant of the widening vector load instruction specifies at least one predicate value specifying element predication information indicative of which data elements of the at least one vector are masked data elements for which corresponding portions of the plurality of vector destination registers are to specify a value independent of the masked data elements; andthe element predication information is specified by the at least one predicate value at granularity of element groups, each element group comprising one data element from each of the plurality of interleaved channels.5 19. A storage medium storing the computer-readable code of claim 16 or the computerprogram of claim 18.10

Images