Permute prefix instruction

Abstract

In response to a permute prefix instruction specifying at least one permute source vector register Zn and a destination vector register Zd1, instruction decoding circuitry is configured to generate a

Description

The present technique relates to the field of data processing. Processing apparatus may support vector processing (also known as single instruction, multiple data, SIMD, processing) which is a technique in which a single instruction causes processing circuitry to perform operations on respective vector elements representing independent data values within the same vector operand, to generate corresponding vector elements of a result vector. By providing the ability to cause multiple independent lanes of processing to be applied to respective vector elements in response to a single instruction, the overhead of fetching, decoding and issuing instructions can be shared across each of those lanes of processing, providing a performance improvement in comparison to performing the same processing operations using scalar instructions with each scalar instruction performing an operation corresponding to a single lane of the vector processing. At least some examples of the present technique provide an apparatus comprising: instruction decoding circuitry configured to decode instructions to generate micro-operations; and processing circuitry configured to perform data processing operations in response to the microoperations decoded by the instruction decoding circuitry; in which: in response to a permute prefix instruction specifying at least one permute source vector register and a destination vector register, the instruction decoding circuitry is configured to generate a micro-operation to control the processing circuitry to perform at least a permute operation to permute vector elements of at least one permute source vector operand specified by the at least one permute source vector register to generate a permuted vector operand corresponding to the destination vector register; and the permute prefix instruction has an encoding providing an instruction fusion hint indicating to the instruction decoding circuitry that a next instruction in program order after the permute prefix instruction is expected to be a vector processing instruction specifying, as a source vector register for defining a source vector operand to which a vector processing operation is to be applied, the destination vector register of the permute prefix instruction. At least some examples of the present technique provide computer-readable code for fabrication of the apparatus described above. At least some examples of the present technique provide a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: instruction decoding program logic configured to decode instructions of the target program code; and processing program logic configured to perform data processing operations in response to the instructions decoded by the instruction decoding program logic; in which: in response to a permute prefix instruction of the target program code specifying at least one permute source vector register and a destination vector register, the instruction decoding program logic is configured to control the processing program logic to perform at least a permute operation to permute vector elements of at least one permute source vector operand specified by the at least one permute source vector register to generate a permuted vector operand corresponding to the destination vector register; and the permute prefix instruction has an encoding providing an instruction fusion hint indicating to the instruction decoding program logic that a next instruction of the target program code in program order after the permute prefix instruction is expected to be a vector processing instruction specifying, as a source vector register for defining a source vector operand to which a vector processing operation is to be applied, the destination vector register of the permute prefix instruction. The computer program may be stored on a storage medium. The storage medium may be a non-transitory storage medium. At least some examples provide a method comprising: decoding instructions to generate micro-operations; and performing data processing operations in response to the microoperations; in which: in response to a permute prefix instruction specifying at least one permute source vector register and a destination vector register, the permute prefix instruction is decoded to generate a micro-operation to control processing circuitry to perform at least a permute operation to permute vector elements of at least one permute source vector operand specified by the at least one permute source vector register to generate a permuted vector operand corresponding to the destination vector register; and the permute prefix instruction has an encoding providing an instruction fusion hint indicating that a next instruction in program order after the permute prefix instruction is expected to be a vector processing instruction specifying, as a source vector register for defining a source vector operand to which a vector processing operation is to be applied, the destination vector register of the permute prefix instruction. 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 data processing apparatus; Figure 2 illustrates an example of a permute prefix instruction; Figure 3 illustrates an example of an operation corresponding to a fused micro-operation obtained by fusing the permute prefix instruction with a subsequent vector instruction; Figures 4 to 7 illustrate examples of variants of the permute prefix instruction corresponding to different permutation operations; Figure 8 illustrates a method for processing a permute prefix instruction; Figure 9 illustrates a method for processing a permute-pattern-predicate-setting instruction; and Figure 10 illustrates a simulation example. An apparatus comprises instruction decoding circuitry configured to decode instructions to generate micro-operations; and processing circuitry configured to perform data processing operations in response to the micro-operations decoded by the instruction decoding circuitry. While vector processing can often improve performance in comparison to equivalent scalar processing implementations, the inventors have recognized there can be some use cases, such as convolutional neural networks, matrix inversion, or complex number linear algebra, in which data stored in memory may need to be rearranged prior to processing the data using a given vector instruction. For example, for convolutional neural network (CNN) processing, the same set of data stored in memory may be combined in many different combinations (e.g. when shifting a given row of activation data relative to corresponding kernel weights), and so it may be that a large majority of vector multiply-add operations performed in the CNN algorithm are preceded by a permutation operation to shuffle the positions of vector elements. Hence, while vector processing can indeed improve performance relative to a scalar implementation, the large number of permutation instructions may still represent a significant performance cost, reducing the throughput of vector operations. Some vector instruction set architectures may support indexed vector processing instructions which specify an index operand identifying the position of the elements of an input vector operand to be processed in a particular lane of vector processing, enabling the permutation operation to be combined into the same instruction as a corresponding vector processing operation and reducing the number of instruction slots occupied by permute instructions. However, limited instruction encoding space available in the instruction set means that, typically, the number of distinct types of vector processing operations that can support an indexed variant of a vector processing instruction is limited, and the range of permutation options supported by the indexed vector processing instruction may be more limited than supported by a generic permutation instruction. In general, there will be insufficient encoding space spare in an instruction set architecture to allow every possible vector processing instruction to be provided with a corresponding indexed variant. Hence, many processing workloads may need to fall back on including dedicated permutation instructions, which occupy instruction slots in issue queues and execute units, therefore reducing the effective throughput of vector processing instructions. Recognizing these points, the inventors have proposed that the instruction set architecture supported by the instruction decoding circuitry and processing circuitry includes, as an instruction of the instruction set architecture, a permute prefix instruction which specifies at least one permute source vector register and a destination vector register. In response to the permute prefix instruction, the instruction decoding circuitry generates a micro-operation to control the processing circuitry to perform at least a permute operation to permute vector elements of at least one permute source vector operand specified by the at least one permute source vector register to generate a permuted vector operand corresponding to the destination vector register. For example, the permute operation may comprise shuffling of element positions within the at least one permute source vector operand to generate corresponding elements of the permuted vector operand (e.g. with at least one vector element of the at least one permute source vector operand being moved to a different element position within the permuted vector operand). The permute prefix instruction has an encoding providing an instruction fusion hint indicating to the instruction decoding circuitry that a next instruction in program order after the permute prefix instruction is expected to be a vector processing instruction specifying, as a source vector register for defining a source vector operand to which a vector processing operation is to be applied, the destination vector register of the permute prefix instruction. As the permute prefix instruction encoding the permutation is defined in the instruction set architecture as a separate instruction from the next instruction encoding the vector operation, this supports a much wider variety of combinations of permutations and vector operations than would be practical to encode using specific indexed vector processing instructions. However, unlike generic permute instructions not providing an instruction fusion hint, the software-specified hint encoded by the permute prefix instruction enables hardware designers to more efficiently implement circuitry to fuse the permute prefix instruction with the next instruction to form a combined fused micro-operation which controls the processing circuitry to perform both the permutation represented by the permute prefix instruction and the vector processing operation represented by the next instruction in a single micro-operation (such fusion improving performance by freeing up pipeline slots for other operations so that overall instruction throughput is higher). The instruction fusion hint helps to reduce barriers to implementing such instruction fusion because the hint indicates expected properties of the next instruction, which can reduce the need to incur circuit area, power and latency cost in implementing circuitry to check those properties of the next instruction when deciding whether to fuse the permute prefix instruction and the next instruction. Hence, an instruction set architecture supporting the permute prefix instruction gives the design flexibility to enable an increased variety of processing workloads to benefit from fusion of permute operations with vector processing operations, in comparison to an instruction set architecture which supports such permutation only via generic permute instructions not providing the instruction fusion hint or by indexed vector processing instructions corresponding to a limited number of vector processing operation types. The instruction fusion hint could be encoded in different ways. For example, the opcode of the permute prefix instruction may indicate that this instruction is to be interpreted as a permute prefix instruction providing the instruction fusion hint (distinguished from other instructions, including permute instructions, which have a different opcode and do not provide the instruction fusion hint). Alternatively, the permute prefix instruction could share an opcode with at least one alternative permute instruction variant which does not provide the instruction fusion hint, and a parameter encoded by the permute prefix instruction (e.g. an immediate flag or other parameter) may indicate whether the instruction represents the permute prefix instruction providing the instruction fusion hint or another alternative permute instruction variant not providing the instruction fusion hint. As noted above, the instruction fusion hint indicates that the next instruction is expected to have a source vector register corresponding to the destination vector register of the permute prefix instruction. This means that the overall effect of the permute prefix instruction and the next instruction would be to perform a vector processing operation on a permuted source vector operand obtained by applying the permutation represented by the permute prefix instruction. By providing a hint that the next instruction is expected to have a source vector register matching the destination vector register of the permute prefix instruction, this can reduce barriers to supporting instruction fusion as it means it is not necessary to implement circuitry for checking whether the next instruction actually specifies a source vector register corresponding to the destination vector register of the permute prefix instruction (comparing register identifiers may be relatively slow and make it harder for the fusion circuitry to meet timing requirements, so it can be beneficial to use the software-provided hint to allow the comparison logic to be eliminated). In some examples, the instruction fusion hint may also indicate that, at least when the next instruction specifies a destination vector register, the next instruction is expected to be a destructive instruction specifying, as both a source vector register and the destination vector register of the destructive instruction, the destination vector register of the permute prefix instruction. This assumption does not need to apply in cases where the next instruction is an instruction not specifying any destination vector register (e.g. where the next instruction is a vector store instruction). A destructive instruction is an instruction which specifies the same register as both its destination register and one of its source registers. By using the hint to indicate that the next instruction is expected to have the same destination register as the permute prefix instruction, this can again reduce the barrier to implementing instruction fusion circuitry, making adoption of implementation’s supporting fusion more likely. If the destination vector register of the next instruction was permitted to be different to the destination vector register of the permute prefix instruction, any fused micro-operation corresponding to the permute prefix instruction and next instruction would be required to have two separate destination registers to ensure that it gives the same architectural result as executing the permute prefix instruction and next vector processing instruction as separate unfused micro-operations. As instructions which write to two vector destination registers in one instruction may be relatively uncommon, requiring two destination register writes in the fused micro-operation may be undesirable for some micro-architectures and may therefore be a barrier to adoption of fusion. Hence, by providing the architectural constraint that the permute prefix instruction should be used by software only in cases where (if the next instruction has a destination vector register), the next instruction is a destructive instruction specifying as both its source and destination vector register the destination vector register of the permute prefix instruction, this means any fused micro-operation still only needs one destination register and so it is feasible to implement circuitry for fusing these instructions even in implementations which are limited to writing to one destination register per micro-operation. In some examples, the permute prefix instruction specifies an element size indication indicative of a vector element size for the at least one permute source vector operand specified by the at least one permute source vector register. The instruction fusion hint may also indicate to the instruction decoding circuitry that the next instruction is expected to specify an element size indication indicating a same vector element size as the element size indication of the permute prefix instruction. While not essential (and some examples could support cases where the element size for the next instruction differs from the element size for the permute prefix instruction), constraining valid use of the permute prefix instruction to cases where the element size is the same for both permutation and vector operation can simplify implementation of instruction fusion circuitry, as it reduces the need to check whether the combination of element size for the permute prefix instruction and subsequent vector instruction corresponds to a valid combination of element sizes capable of being handled with a fused micro-operation. Hence, as mentioned above, the instruction fusion hint may express various properties of the next instruction (e.g. information about the source vector register of the next instruction, and in some cases also about the destination vector register and / or element size of the next instruction). It will be appreciated that these properties of the next instruction do not need to be explicitly encoded in the instruction fusion hint. In some cases, the information defining the instruction fusion hint (e.g. the opcode of the permute prefix instruction) could provide a single value which indicates all of these properties as implicitly being satisfied by the next instruction, based on an architecturally defined understanding of the meaning of the parameter defining the instruction fusion hint. Hence, the instruction fusion hint may be architecturally defined as constraining compilers to use the permute prefix instruction only in scenarios where the conditions expressed by the instruction fusion hint are satisfied. If the software developer or compiler generates software code not meeting these conditions, there is a risk that hardware may generate the wrong result as the hardware may treat the instruction fusion hint as a guarantee that these conditions are satisfied and may not itself check whether the conditions are satisfied. Although it is useful to define the permute prefix instruction in the instruction set architecture (ISA) supported by the instruction decoding circuitry and processing circuitry, as this permits implementations with less complex instruction fusion circuitry, it is not essential for an apparatus supporting the permute prefix instruction to actually implement such instruction fusion circuitry. Hence, in some examples the micro-operation generated in response to the permute prefix instruction may be an unfused micro-operation which implements the permute operation only, without representing any vector processing operation encoded by the next instruction after the permute prefix instruction. Some implementations of the processing apparatus supporting the permute prefix instruction may choose not to provide instruction fusion circuitry, and simply implement the permute prefix instruction and the next instruction as separate micro-operations processed separately by the processing circuitry. Nevertheless, an ISA supporting the permute prefix instruction can be regarded as a more performance-efficient ISA than an ISA not supporting the permute prefix instruction as it gives the flexibility for system designers to decide whether to implement either fused or unfused implementations in hardware, with lower barriers to adoption of the fusion circuitry. Software designed to use the permute prefix instruction can execute either on an unfused implementation (with lower performance) or on a fused implementation (with higher performance), but the presence of the permute prefix instruction increases the fraction of implementations which are able to implement fusion, as the barriers to adoption are lower. Nevertheless, the permute prefix instruction can also be supported by implementations not using instruction fusion, with the instruction fusion hint encoded by the permute prefix instruction simply being ignored on such implementations. However, in some implementations, the instruction decoding circuitry comprises instruction fusion circuitry configured to fuse the permute prefix instruction and the next instruction to generate a fused micro-operation to control the processing circuitry to perform both the permute operation and a vector processing operation represented by the next instruction. Hence, for implementations actually comprising the instruction fusion circuitry, performance can be improved by reducing the number of micro-operation slots occupied by standalone permutation operations, improving throughput of operations. The instruction fusion circuitry could be implemented either at the principal decode stage of a processing pipeline where program instructions are initially decoded by the instruction decoding circuitry, or at another stage of the pipeline (e.g. fusion could be implemented “late” at a later pipeline stage than the principal decode stage). Hence, in some cases it will be appreciated that the instruction decoding circuitry (including the instruction fusion circuitry) may be distributed across more than one pipeline stage. The instruction fusion circuitry may determine whether to fuse the permute prefix instruction and the next instruction based on a determination of whether at least one fusion condition is satisfied. For example, the at least one fusion condition may include a condition that the next instruction is one of a subset of instruction types for which fusion of the permute prefix instruction and the next instruction supported by the instruction fusion circuitry (e.g. some implementations may only support fused micro-operations corresponding to a limited subset of instruction types, so fusion may not be supported if the next instruction is not one of those subset of instruction types for which fusion is supported on a particular implementation). However, any assumptions about the next instruction that are represented by the instruction fusion hint do not need to be explicitly checked by the instruction fusion circuitry when deciding whether to fuse the permute prefix instruction and the next instruction. Hence, the instruction fusion circuitry can be configured to fuse the permute prefix instruction and the next instruction without checking whether the source vector register of the next instruction is the same register as the destination vector register of the permute prefix instruction, as the presence of the instruction fusion hint may implicitly indicate that the next instruction is expected to use as a source the destination vector register of the permute prefix instruction. Similarly, in some examples, the instruction fusion circuitry may fuse the permute prefix instruction and the next instruction based on an assumption that the next instruction is a destructive instruction specifying, as both a source vector register and a destination vector register of the destructive instruction, the destination vector register of the permute prefix instruction, without checking whether that assumption is correct. Also, in examples where the instruction fusion hint also expresses a hint that the next instruction is expected to specify the same element size indication as the permute prefix instruction, the instruction fusion circuitry may fuse the permute prefix instruction and the next instruction without checking whether an element size indication specified by the permute prefix instruction specifies the same vector element size as an element size indication specified by the next instruction. Hence, use of the permute prefix instruction simplifies design of the instruction fusion circuitry by reducing the amount of checking needed to permit fusion. Nevertheless, some fusion conditions may still be checked, such as the instruction type of the next instruction as mentioned above, or other implementation-specific criteria, so it is not guaranteed that in the presence of the instruction fusion hint expressed by the permute prefix instruction, the instruction fusion circuitry would always fuse the permute prefix instruction with the next instruction. Fusion could be supported for various types of vector processing instruction that may follow the permute prefix instruction. For example, in some cases the instruction fusion circuitry may fuse the permute prefix instruction and the next instruction at least when the next instruction is a vector arithmetic instruction for which the vector processing operation comprises a vector arithmetic operation. For example, the vector arithmetic instruction for which fusion is supported could comprise a vector multiply instruction for which the vector arithmetic operation comprises an operation comprising a multiplication. The vector arithmetic operation involving multiplication could be a standalone multiply operation, or a multiply-add operation which adds the result of the multiplication in each vector lane to an addend operand or accumulator value). In some examples the operation comprising a multiplication comprises a fused-multiply add operation performed on vector data elements represented in a floating-point representation. Such fused multiply add operations are extremely common in workloads such as convolutional neural networks which require vector permutations ahead of each vector processing operation, so it can be particularly beneficial for such workloads to support fusion of the permute prefix instruction with vector multiply instructions such as a vector floating-point fused multiply-add instruction. Some examples may support fusing the permute prefix instruction and the next instruction at least when the next instruction is a vector store instruction for which the vector processing operation comprises storing the source vector operand to one or more memory locations identified based on an address specified by the vector store instruction. The vector store instruction for which fusion is supported could be a contiguous vector store instruction (for which the memory locations are at contiguous addresses in memory), or could be a scatter vector store instruction (for which the memory locations can be at non-contiguous addresses identified based on an index vector operand). By supporting fusion of a permute prefix instruction with a vector store instruction, this enables a single micro-operation to trigger both rearrangement of element positions in a vector and storing of the permuted vector to memory, improving performance compared to handling the permutation in a separate micro-operation from the store operation. Again, some processing workloads such as CNNs may involve permutation just before writing back result data from a source vector to memory, and so such operations can be accelerated with support for fusion. In the permute operation represented by the permute prefix instruction, the permutation pattern defining which source vector elements of the at least one permute source vector element are mapped to each vector element position in the permuted vector operand may be defined in different ways. In some examples, the permutation pattern may be fixed for a given variant of permute prefix instruction. For example, for a permute prefix instruction having a given opcode, the permutation pattern may be fixed as represented by that given opcode, e.g. to define interleaving or deinterleaving of elements selected from one or more source vector registers specified by the permute prefix instruction, or to extract elements from element positions at given intervals throughout one or more source vector registers specified by the permute prefix instruction. Such an instruction may not require an explicit operand to define the permutation pattern. In some implementations, the instruction decoding circuitry and processing circuitry may support two or more variants of the permute prefix instruction, distinguished by their opcodes or other parameters of the instruction, which correspond to different permutation patterns. Some implementations may support at least one variant of the permute prefix instruction which specifies a register operand identifying the permutation pattern to be applied in the permute operation. This allows for more flexible definition of the permutation pattern, as the contents of the register referenced as the register operand may define the pattern of permutations used to map the source vector operand to the permuted vector operand. For example, the register operand may specify a series of index elements, with each index element specifying an index value identify the position of the source vector element in the at least one source vector operand which is to be mapped to a corresponding vector element position in the permuted vector operand. The register operand used to encode the permutation pattern could, in some examples, be a vector register. However, in some examples, it can be beneficial to use a predicate register to encode the permutation pattern. Hence, in some examples, the permute prefix instruction specifies a predicate register and the permute operation comprises permuting vector elements of the at least one permute source vector operand according to a permutation pattern identified by a predicate value specified by the predicate register. A predicate register is a register type which, when specified by a vector processing instruction (other than the permute prefix instruction), identifies which vector elements are active / inactive elements (inactive elements being elements that do not contribute to the result of that vector processing instruction). Predicate registers are normally used to control the processing circuitry mask out effects of unused processing lanes of vector processing operations (in the case where the total number of elements to be processed does not correspond to an exact multiple of the vector length), or to implement conditional processing where some lanes may be masked out depending on comparison operations performed on corresponding vector elements by an earlier instruction. Such predication is normally applied lane by lane, with the predicate value corresponding to a given lane of processing influencing only the outcome of that lane and not influencing results in other lanes. However, the inventors propose reusing such predicate registers for the permute prefix instruction to encode the pattern of permutations to be applied to the at least one source vector operands. This is unusual since it would mean that the predicate register is expressing cross-lane movements of elements, which is contrary to the usual lane-by-lane application of predicate masks. However, the inventors recognised that using a predicate register for encoding the permutation pattern can be helpful to reduce the barriers to adoption of instruction fusion when implementing a variant of the permute prefix instruction permitting relatively arbitrary permutation patterns expressed using index values corresponding to each element position. This is because typical processing pipeline implementations may be limited in the number of vector register read ports supported for reading multiple registers from a register file in response to a single microoperation, and the combination of the permute prefix instruction and the next vector instruction may, for some types of next vector instruction, already be using the maximum allowed number of source registers for their vector operands. Hence, requiring another vector register to be used for encoding the permutation pattern of the permute prefix instruction would risk limiting which instruction types are able to be fused with the permute prefix instruction, as any vector instructions already using the maximum supported number of source vector registers may not be able to be fused. Hence, by using a predicate register to express the permutation pattern, barriers to fusion of the permute prefix instruction and a subsequent vector instruction can be reduced. In practice, for many workloads likely to benefit from fusion of the permute prefix instruction, the vector operations likely to be fused with the permute are unpredicated operations which would not otherwise use a predicate register, so use of a predicate register for expressing the permutation pattern is more likely to benefit performance in the average case than use of a vector register for the permutation pattern. In some examples, the permute operation may comprise, for each vector element of the permuted vector operand, setting that vector data element of the permuted vector operand to a value determined based on a selected vector element at a selected vector element position within the permute source vector operand, where the selected vector element position is indicated by an index value specified by a corresponding portion of the predicate value. In an example using the predicate register for expressing the permutation pattern, the instruction fusion hint encoded by the permute prefix instruction may also indicate to the instruction decoding circuitry that the next instruction is expected to be an unpredicated vector processing instruction. Hence, if instruction fusion circuitry is provided, the instruction fusion circuitry may fuse the permute prefix instruction and the next instruction based on the assumption that the next instruction is unpredicated. For the particular case of a variant of the permute prefix instruction which uses a predicate register to encode the permutation pattern, constraining the valid use of that variant of the permute prefix instruction to cases where the next instruction is unpredicated avoids risk of two predicate registers needing to be read for one fused microoperation, which would make it less likely that fusion is adopted as it may be that some processor hardware implementations provide a limited number of predicate register file read ports (e.g. supporting only one predicate register read per micro-operation). Hence, by representing in the hint an assumption that the next instruction is expected to be unpredicated (so that the permute prefix instruction can be fused assuming the next instruction is unpredicated, to generate a fused micro-operation requiring one predicate register read), this is likely to be more compatible with many hardware implementations, increasing the likelihood of adoption of fusion. In some examples, to support use of predicate registers in defining the permutation pattern, the instruction set architecture may support at least one permute-pattern-predicate-setting instruction. In response to the permute-pattern-predicate-setting instruction being decoded by the instruction decoding circuitry, the processing circuitry may update a target predicate register specified by the permute-pattern-predicate-setting instruction to specify an updated permutation pattern. The updated permutation pattern to be specified in the target predicate register could be defined in various ways. For example, a source vector register of the permute-pattern-predicate-setting instruction could specify the updated permutation pattern (e.g. with lower bits of each vector element of the source vector register indicating the index to be transferred to a corresponding portion of the target predicate register). Alternatively, the permute-pattern-predicate-setting instruction could specify a given transformation of the target predicate register (e.g. adding a specified offset to each index value specified in the target predicate register). Another example of the permute-pattern-predicate-setting instruction could define specified index patterns using one or more operands. For example, sequences such as 0, 0, 0, 3, 3, 3, 6, 6, 6 involving repetitions of the same index value multiple times could be represented by operands defining the starting index value for the pattern, the number of repetitions of each index value, and the offset between the value to be repeated in one portion of the predicate and the value repeated in another portion. A permute-pattern-predicate-setting instruction could also specify an operand defining a sequence of index values to be repeated multiple times within the predicate. Hence, there are a wide variety of techniques that could be used to define the permutation pattern specified in a given predicate register, so that a subsequent permute prefix instruction can apply a permutation based on that permutation pattern. In some examples, the permute operation corresponding to the permute prefix instruction comprises permuting the vector elements of the permute source vector operand according to a permutation pattern selected from a first set of one or more permutation patterns supported by the permute prefix instruction; and in response to the instruction decoding circuitry decoding a non-prefix permute instruction specifying a given source vector operand and having a different encoding to the permute prefix instruction, the processing circuitry is configured to perform a permute operation comprising permuting vector elements of the given source vector operand according to a permutation pattern selected from a second set of permutation patterns, the nonprefix permute instruction having an encoding which does not provide the instruction fusion hint. Hence, the permute prefix instruction is distinguished from other more generic permute instructions not providing the instruction fusion hint. If a permutation is required in a scenario in which any assumptions of properties of the next instruction encoded by the instruction fusion hint would not be satisfied by the instruction after a permute instruction, then the software developer / compiler can choose to use one of the non-prefix permute instructions instead of the permute prefix instruction. However, in cases where those assumptions can be satisfied, use of the permute prefix instruction is preferred in software, as that enables the software to run with improved performance on implementations supporting instruction fusion. The second set of permutation patterns may comprise each of the permutation patterns of the first set supported by the permute prefix instruction. Hence, each permutation pattern supported by the permute prefix instruction may also be supported by a corresponding non-prefix permute instruction. Therefore, the circuit logic for supporting the permute prefix instruction (either as an unfused micro-operation or as a fuse micro-operation fused with a corresponding vector operation) may reuse circuit logic already provided for supporting the non-prefix permute instruction, so supporting the permute prefix instruction may not require much additional overhead. On the other hand, the second set of permutation patterns may comprise at least one permutation pattern not supported by the first set of permutation patterns. Hence, it is not necessary for permute prefix instruction encoding options to be provided to support all possible permutation patterns supported by non-prefix permute instructions. For example, permute prefix instructions may support a subset of permutation patterns expected to be likely to be most common in workloads which require frequent permutations prior to each vector operation (such as convolutional neural network processing). In some implementations, the range of possible element sizes supported for the permute prefix instruction may be more limited than the range of element sizes supported for the nonprefix permute instructions. The non-prefix permute instruction may support performing the permute operation on vector elements of the given source vector operand having a vector element size selected from a second set of vector element sizes, the second set of vector element sizes comprising at least one vector element size not supported by a first set of vector element sizes supported for the permute operation performed in response to the permute prefix instruction. This can be useful particularly for examples of the prefix permute instruction which use a predicate register to encode a permutation pattern, as the predicate register may have fewer bits than a vector register and so may have insufficient encoding space to fully encode lane by lane index positions at fine granularity when smaller element sizes. Nevertheless, it is expected that a permute prefix instruction using a predicate register to define index values for defining a permutation pattern is likely to be of benefit to workloads such as convolutional neural network processing even if the permute prefix instruction is limited to use in scenarios where the vector element size is within the first set of vector element sizes which is more limited than the full set of vector element sizes supported for other non-prefix permute instructions. Specific examples are now set out with reference to the drawings. Figure 1 schematically illustrates an example of a data processing apparatus 2 comprising a processing pipeline 4 including a number of pipeline stages. In this example the pipeline stages include a fetch stage 6 for fetching instructions from a data store (e.g. an instruction cache or memory), a decode stage for decoding the fetched instructions, a rename stage 10 for performing register renaming, an issue stage 12 for issuing instructions for execution, and an execute stage 14 for executing the issued instructions. The execute stage 14 includes a number of execute units for executing different kinds of instructions, for example a scalar ALU (arithmetic logic unit) 20 for executing scalar data processing instructions, a vector ALU 22 for executing vector data processing instructions, a floating point unit 24 for executing floating point instructions (in some cases separate scalar and vector floating point units could be provided), and a load / store unit 26 for executing load / store instructions for transferring data between registers 30 and a data store such as a data cache or memory. A translation lookaside buffer (TLB) 32 may be provided for caching address translation data for translating virtual addresses specified by the load / store instructions to physical addresses identifying locations within the data cache or the memory. The registers 30 include scalar registers 34 for storing scalar operands each comprising a single data element, vector registers 36 for storing vector operands each comprising multiple data elements, and predicate registers 38 for storing predicate values identifying which elements of a vector register 36 are active or inactive. In response to a vector instruction processed by the vector ALU 22, one or more vector operands may be read from the vector register 36 and a predicate value stored in one of the predicate register 38 may control the vector ALU 22 to perform a given data processing operation on any active data elements indicated by the predicate value to generate corresponding result data elements to be written back to one of the vector registers, while any elements corresponding to inactive lanes indicated by the predicate may take some other value. Different inactive lane handling modes may be defined for determining how to set the values of the inactive lanes in the destination register. For example, the inactive result data elements could be cleared to a predetermined value (e.g. zero) or could retain the previous value of the corresponding element of the destination register. On the other hand, for scalar instructions, the scalar ALU 20 or floating point unit 24 may read data values from the scalar registers 34, process them and write a result value back to one of the scalar registers 34. In the example of Figure 1, the pipeline 4 is an out-of-order pipeline which supports execution of instructions in a different order to the program order in which the instructions were fetched by the fetch stage 6. The issue stage 12 has an issue queue 40 for queuing instructions to be executed while waiting for their operands to become available. When an instruction’s operands become available (or are guaranteed to become available in time for the pipeline stage at which the operands are needed), then it may be issued for execution by the execute stage 40 even if an earlier instruction in the program order is still waiting for its operands. To increase the extent to which reordering of instructions is possible, the rename stage 10 is provided to map architectural register specifiers specified by the fetched instructions to physical register specifiers identifying physical registers 30 provided in hardware. Typically the number of physical registers provided is greater than the number of architectural registers available in the instruction set architecture, to allow different instructions specifying the same architectural register to be mapped to different physical registers so that dependencies between these instructions can be eliminated. This permits greater flexibility to reorder the execution of instructions, to improve performance. The rename stage 10 maintains a rename table 42 fortracking the mapping between architectural register specifiers and physical register specifiers. It will be appreciated that other examples may provide an in-order pipeline for which program instructions are executed in their original program order. In this case the rename stage 10 could be omitted and the issue stage 12 may issue a given instruction when its operands are available (or are guaranteed to be available by the time the instruction reaches the stage at which the operands are needed) and any earlier instructions in the program order have been issued. It will be appreciated that this is just one example of a possible pipeline architecture and other examples may have different stages or different combinations of execute units in the execute stage 14. For example, some pipelines may have an additional dispatch stage between the decode stage 8 and the issue stage 12 so that decoded instructions may wait in the dispatch stage when the issue queue 40 is full to avoid blocking the decoding of other instructions at the decode stage 8. The instructions fetched from the data store by the fetch circuitry 6 may be referred to as “macro-instructions”, while the decoded instructions passed to the execute stage 14 for execution may be referred to as “micro-instructions” or “micro-operations”. For some types of instruction, there may be a one-to-one mapping between the macro-instruction fetched from the cache or memory and the micro-operation executed by the execute stage 14. However, for other types of instruction, a complex instruction may be decoded by the decode stage 8 into multiple microoperations which can then be issued separately for execution by the execute stage 14. For example, a load multiple instruction could be decoded into a number of individual load microoperations each for loading data from memory into a different register. Also, two or more macro-instructions may be fused to generate a single micro-instruction to be executed. In this example, the decode stage 8 has instruction fusing circuitry 50 for fusing various groups of two or more instructions detected within the stream of instructions fetched by the fetch stage from the instruction cache or memory, and when such a group is detected, fusing these to generate a single fused data processing instruction giving an equivalent result which can then be forwarded to subsequent stages for processing. This enables improved performance since a single instruction can typically be executed faster than two or more separate instructions (and consumes fewer slots in the issue queue 40 or execute stages, enabling greater throughput of other instructions). While Figure 1 shows the decode stage 8 comprising the instruction fusing circuitry 50, in other examples the instruction fusion could take place at another stage such as a dispatch stage or the issue stage 12 (for example, the decode stage 8 could initially decode the group of instructions into separate decoded instructions, but fusing circuitry at the issue stage could then fuse these into a single micro-operation). Therefore, in some cases the instruction decoding circuitry 8 comprising the instruction fusion circuitry 50 could be distributed across multiple pipeline stages, rather than shown in one stage as in Figure 1. The instruction fusing circuitry 50 may detect a fusible group of instructions which can be mapped to a corresponding fused instruction (fused micro-operation) to be sent to the processing circuitry 14. There may be several different fusible groups which can each be mapped to a corresponding fused instruction. However, the subsequent examples will focus on a particular group comprising a permute prefix instruction and subsequent vector processing instruction. This does not exclude the instruction fusing circuitry 50 being able to fuse other types of instructions as well. Figure 2 illustrates an example of a permute prefix instruction for controlling the processing circuitry 14 to perform a permute operation. The permute prefix instruction specifies an opcode identifying the type of instruction as being a permute prefix instruction, a destination vector register Zd1, and at least one source vector register Zn. Optionally, more than one source vector register could be specified by the instruction. Any additional vector register Zm could either be identified by a separate register identifier field in the instruction encoding from the register identifier field specifying the first source vector register Zn, or could be identified with reference to the same register identifier field used to identify the first source vector register Zn (e.g. with predetermined offset(s) between the register identifier of the first source vector register Zn and the register identifier of any further source vector register - for example a single field indicating the identifier of vector register Zn may also implicitly identify a second source operand using vector register Zn+1). Although not shown in Figure 2, some variants of the instruction could have more than two source registers. The permute operation comprises permuting source vector elements from at least one source vector operand obtained corresponding to at least one source vector register Zn, [Zn+1 / Zm, etc.], to generate corresponding permuted vector elements of a permuted vector operand to be architecturally assigned to the destination vector register Zd1. The permutation function used to map the source vector elements to the permuted vector elements may correspond to a particular permutation pattern, which could either be fixed for a given permute prefix instruction opcode (e.g. with a predetermined pattern of shuffling elements, such as interleaving pairs of elements from respective source vectors or selecting elements at regular intervals of element position), or could be variable for a given permute prefix instruction opcode based on a permutation pattern operand. For variants using a permutation pattern operand, that operand could be provided as an immediate value in the instruction encoding, or using a register operand. In particular, it can be useful for some examples to provide, as the register operand defining the permutation pattern, a predicate register (Pi) 38, because this avoids consuming additional vector register which can be helpful to reduce barriers to fusion of the permute prefix instruction with a following vector processing instruction. The permutation function comprises shuffling element positions of the source vector operand(s) to move elements from one element position to another to generate a rearranged set of elements in the permuted vector operand corresponding to the destination vector register. As shown in Figure 2, the permute prefix instruction is intended, when in use within a software algorithm, to precede an immediately following destructive vector processing instruction which specifies, as both a source vector register and destination vector register of the vector processing instruction, the destination vector register Zd1 of the permute prefix instruction, so that the overall effect of the permute prefix instruction and the vector processing instruction is to perform the permutation operation on the source vector operand(s) of the prefix instruction and then process the permuted vector operand generated by the permutation operation as one of the source vector operands for a subsequent vector processing operation (such as a vector arithmetic / logical operation or vector store operation). For some variants of the vector processing instruction, the vector processing operation may take one or more further source vector operands, in addition to the permuted vector operand generated by the permutation operation performed corresponding to the permute prefix instruction. The result of the data processing operation is written to the destination vector register Zd1 of the vector processing instruction. Unlike other more generic permute instructions included in the instruction set supported by the apparatus 2, the permute prefix instruction encodes an instruction fusion hint, which indicates that certain conditions can be assumed to be satisfied by the immediately following instruction in program order after the permute prefix instruction. The instruction fusion hint may be implicitly represented by the opcode of the permute prefix instruction (which may be different to opcodes of other permute instructions not providing the instruction fusion hint), or could be indicated by a flag or other parameter in the instruction encoding which distinguishes whether a given permute instruction should be regarded as the permute prefix instruction providing the instruction fusion hint or a non-prefix permute instruction not providing the instruction fusion hint. For example, the assumptions that can be made about the next instruction following the permute prefix instruction in program order may include: that the next instruction specifies as a source vector register the destination vector register of the permute prefix instruction; for some examples, that the next instruction is a destructive instruction (instruction specifying a same register as both source and destination) specifying as its destination vector register the same register as the destination vector register of the permute prefix instruction (this assumption may apply in cases when the next instruction is a vector ALU instruction, but may not need to be satisfied for certain examples of subsequent vector instruction such as vector store operations which do not have a destination vector register). in some examples, if the permute prefix instruction supports variable vector element size defined by an element size parameter, that the next instruction is a vector instruction specifying the same element size as the permute prefix instruction; in some examples, which use a predicate register to provide an operand defining the permutation pattern applied for the permutation operation corresponding to the permute prefix instruction, that the next instruction is an unpredicated vector instruction which does not require a predicate register as an input operand. It will be appreciated that not all of these assumptions may apply for a particular instruction set architecture (ISA) implementation or for a particular variant of the permute prefix instruction within a given ISA implementation, and some ISA implementations may only represent a subset of these assumptions using the instruction fusion hint. If the instruction fusion circuitry 50 is provided and decides for a given instance of the permute prefix instruction to fuse the permute prefix instruction and the next instruction, then the instruction fusion circuitry 50 can generate a fused micro-operation corresponding to the combination of the permute prefix instruction and the next vector processing instruction. For example, based on the assumption that the next instruction is a destructive vector processing instruction specifying a source / destination vector register that is the same as the destination vector register Zd1 of the permute prefix instruction, the instruction fusion circuitry 50 can generate the fused micro-operation specifying the destination vector register Zd1 of either permute prefix instruction or the subsequent vector instruction, the input source vector(s) Zn, [Zn+11 Zm, etc.] of the permute prefix instruction and any further source vector registers (e.g. Zx) of the subsequent vector instruction. If the permute prefix instruction is a variant specifying a predicate register, then the predicate register can be specified as an operand of the fused microoperation, or the predicate register can be eliminated at the rename stage 10 (for example by being recognised as having been initialised with a known pattern), or the predicate register can simply be used as a signal to the instruction fusing circuitry 50, for example by a scheme by which a given predicate register, e.g. p5, can be treated as a hint for a particular permute pattern regardless of the value of the register. Hence, it will be appreciated that there can be different ways in which the permute register operand can be handled in the pipeline micro-architecture. As shown in Figure 3, the fused permute / vector-operation micro-operation may control the execute units (e.g. vector ALU 22, load / store unit 26, and / or another execute unit) to perform both a permute operation on the permute source vector operand(s) corresponding to Zn [Zn+1, Zm, etc.], to shuffle element positions of the source vector operand(s) to generate a permuted vector operand, and then perform a vector processing operation (e.g. ALU operation, or vector store operation) on the permuted vector operand and any further operands encoded by the vector processing instruction, to generate a result vector to be written to the destination vector register Zd1 (for a vector ALU operation) or to write the permuted vector operand to memory locations in the memory system (for a vector store operation). As shown in Figure 2, it is not essential for the permute prefix instruction to be fused with the subsequent vector instruction. Some hardware implementations of the apparatus 2 may not comprise instruction fusion circuitry 50 at all, and may choose to adopt the simpler approach of executing the permute prefix instruction and the vector processing instruction as two separate micro-operations. This is consistent with the architectural definitions of the permute prefix instruction and the vector instruction. Hence, the same software instruction sequence can be executed on a range of different processor implementations, some of which implement instruction fusion and others of which do not implement instruction fusion. Nevertheless, by providing a permute prefix instruction representing the instruction fusion hint which signals to the hardware of the apparatus 2 that particular assumptions can be made about the next instruction in program order, this can simplify design of instruction fusion circuitry 50, as instruction fusion circuitry 50 then does not need to check whether these assumptions are satisfied, when deciding whether to fuse the permute prefix instruction with the immediately following instruction in program order. The responsibility for ensuring that the permute prefix instruction is used in scenarios where these assumptions are satisfied by the next instruction lies with the software developer or compiler that generates the sequence of program instructions to be executed by the apparatus 2. Hence, if a sequence of instructions is executed in which the permute prefix instruction is used but the architecturally defined assumptions do not hold for the immediately following instruction in program order, there is a risk that unpredictable results could occur in some processor implementations, giving a different results to be result that would be obtained if the permute prefix instruction and subsequent instruction had been executed as separate microoperations. For example, the instructions may have been fused based on the assumption that the destination vector register of the permute prefix instruction is the same as one of the sources of the next instruction, so that the fused micro-operation may simply be generated taking destination register Zd1 of the permute prefix instruction as a source operand without checking whether that register Zd1 actually matches a source specified by the subsequent instruction. If the user / compiler has generated program code in which this assumption does not apply, there could be a risk that the fused micro-operation takes a different operand from the one actually specified by the vector processing instruction. The user / compiler should ensure this scenario does not occur, and in cases where the assumptions encoded by the instruction fusion hint would not apply, should select a different form of permute instruction which would not provide the instruction fusion hint. The various assumptions described above can help simplify instruction fusion circuitry 50 design because: constraining the next instruction to specify a source vector register corresponding to the destination vector register of the permute prefix instruction eliminates the need for circuitry to compare register specifiers of the permute prefix instruction and vector instruction when deciding whether to fuse these instructions; constraining the next instruction, if it specifies a destination vector register, to specify the same destination vector register as the permute prefix instruction means that it is not necessary to specify an additional destination vector register in the fused micro-operation, which reduces the barriers to fusion as some implementations may limit the maximum number of destination vector registers which can be written to in one micro-operation (e.g. based on the number of vector register write ports supported in hardware); similarly, constraining the next instruction to be unpredicated, if the permute prefix instruction uses a predicate register to specify a permutation pattern operand, avoids the need for the fused micro-operation to specify more than one predicate register, which again avoids contravening any limits to the maximum number of predicate registers read per micro-operation (based on the number of predicate register read ports provided); if variable element size is supported, constraining the next instruction to use the same element size as the permute prefix instruction may reduce complexity in supporting fused micro-operations, as the complexity of encoding a more arbitrary combination of element sizes in the permutation and vector processing operation and providing corresponding circuitry for implementing that combination in the execute stage 14 is reduced. Nevertheless, some implementations may choose to eliminate this constraint and support the ability to fuse micro-operations even when the element size differs between the permute prefix instruction and next instruction, so this constraint is not essential. An advantage of encoding the permute prefix instruction as a separate instruction to the subsequent vector instruction (rather than providing an indexed variant of a vector processing instruction which encodes both the permutation and the vector processing operation) is that the software developer or compiler has flexibility to combine the permute prefix instruction with a variety of different types of vector processing instruction as the next instruction, without needing to use up many different opcodes of encoding space in representing every type of combined permutation / vector processing operation that may be of use for some workloads. Given limited encoding space in an instruction set, this can be beneficial since it will be unfeasible to provide dedicated indexed variants of every possible vector processing instruction for which a prior permutation might be useful. Also, the double length of encoding space represented by the permute prefix instruction and the subsequent vector instruction may provide encoding space for encoding more complex types of permutations than would be feasible in a single instruction encoding both the permute operation and the vector processing operation, as in a single instruction once the parameters of the vector processing operation have been encoded there may be little additional space for encoding more complex forms of permutation. In contrast, the use of a separate permute prefix instruction offers additional encoding space for supporting a wider range of permutation patterns than could be supported in an indexed vector processing instruction. It will be appreciated that, even on an implementation which does support instruction fusion circuitry 50 to allow some fusion of a permute prefix instruction with a subsequent instruction based on the instruction fusion hint, the instruction fusion circuitry 50 does not need to always take the decision to fuse the permute prefix instruction with the subsequent instruction. For example, while the ISA may in principle allow the permute prefix instruction to be used in conjunction with a wide variety of types of vector processing instruction, a given hardware implementation may support fused micro-operations for only a subset of those types of vector processing instructions, so the instruction fusion circuitry 50 may check, in response to detecting a permute prefix instruction, whether the next instruction is of one of the types of instruction for which fusion is supported on that particular processor implementation, to decide whether to implement fusion. Also, there could be other implementation-specific criteria applied to determine whether to fuse the permute prefix instruction and subsequent instruction (e.g. based on alignment of the permute prefix instruction within a given window of instructions considered for decode in a given cycle - e.g. in an implementation supporting multiple parallel decode slots, if the permute prefix instruction is the final instruction in the decode window and so the next instruction is not available in the current cycle for checking whether the next instruction is one of the types for which fusion is supported, the instruction fusing circuitry 50 might choose to process the permute prefix instruction as a standalone permute micro-operation even if the next instruction would in theory have been fusible with the permute prefix instruction if they had been detected together in the same decode window). Hence, the criteria for determining whether fusion is possible may vary significantly from one hardware implementation to another depending on micro-architectural design choices made by the system designer. Figures 4 to 7 illustrate various examples of permute prefix instructions which correspond to different permutation options. It will be appreciated that these examples are not exhaustive, but serve to illustrate that the ISA may support different variants of permute prefix instruction corresponding to different permutation patterns. Figure 4 illustrates an indexed permute prefix instruction TBLPRFX which specifies, in the instruction encoding: an opcode 40 identifying that the instruction is the index permute prefix instruction and also encoding the instruction fusion hint mentioned above; an element size parameter 42 identifying an element size for each vector element of the source vector operand and permuted vector operand; a destination vector register identifier 44 identifying the destination vector register Zd corresponding to the permuted vector operand; a source vector register identifier 46 identifying the source vector register Zn providing the source vector operand; and a predicate register identifier 48 identifying a predicate register Pi which provides permutation pattern identifying information for identifying the permutation pattern to be applied to map vector elements of the source vector operands to vector elements of the permuted vector operand. In this example, the predicate register comprises a set of index values 50 corresponding to respective vector element positions within the permuted vector operand, with a given index value 50 corresponding to a given vector element position in the permuted vector operand indicating the vector element position of the vector element of the source vector operand which is to be mapped to the given vector element position in the permuted vector operand. For example, if the source vector operand comprises vector elements V0 to V7 and the predicate value specifies a series of indices (0, 3, 6, 1, 4, 7, 2, 5) corresponding to positions (0) to (7) in the permuted vector operand, then the permuted vector operand takes the value V[0]-V[7] = (V0, V3, V6, V1, V4, V7, V2, V5) as shown in Figure 4. Figure 5 shows a second example of an index permute prefix instruction TBL2PRFX which specifies similar parameters 40-48 as in the example of Figure 4 (although the opcode 40 may vary to differentiate the two types of instructions), but for which a second source vector register Zn+1 is specified implicitly by the register identifier field 46 identifying the first source vector register Zn (with the second source vector register being the vector register whose register identifier is one higher than the register identifier of the first source vector register). In other examples, the second source vector register Zn+1 could be specified by a further register identifier field in the instruction encoding, instead of being implicitly defined by the first source vector register field. The indexed permutation is similar to that of Figure 4, but the index values in the predicate register Pi select each element of the permuted vector register from among the elements of both the first and second source vector registers (e.g. with the second source vector register corresponding to higher numbered vector element positions than the first source vector register). Hence, some examples may support more than one source vector operand for the permute prefix instruction. The examples of Figures 4 and 5 may be referred to as “table” permute instructions (TBL) as the indexed permutation is equivalent to looking up elements at arbitrary positions within a table of elements to find the value to be written to each successive element of the permuted vector operand. This can be helpful for supporting algorithms such as matrix processing, convolutional neural network processing, etc. The ISA supported by apparatus 2 may support similar non-prefix permute instructions which also offer such indexed permutation functions, although typically such non-prefix indexed permute instructions may use a vector register to provide the index operand representing the permutation pattern to be applied, not a predicate register. The use of a predicate register to represent the permutation pattern may in some examples constrain the permute prefix instruction to support a smaller subset of permutation patterns than is offered by an equivalent non-prefix permute instruction, as the predicate register Pi may have fewer bits than a corresponding vector register. At smaller element sizes (where more index values are required as there are more element positions in the permuted vector operand, and each index would require more bits than at smaller element sizes to enable encoding of all possible options for selecting the selected element of the source vector operand(s) to be mapped to each element position in the permuted vector operand), it may be that there are insufficient bits in the predicate register to fully allow those smaller element sizes to support arbitrary selection of any element of the source vector operand(s) at each position in the permuted vector operand. In this case, one option is for the ISA to not support use of one or more smaller element sizes for the permute prefix instruction (e.g. a generic table permute instruction might support element sizes of 8, 16, 32, 64, ... bits, but the permute prefix instruction might only support element sizes of 32 bits or higher). Another option could be that the smaller element sizes might still be supported but the range of source vector element positions selectable for a given element position of the permuted vector operand could be restricted, e.g. to select between one of a smaller number of elements in a corresponding sub-portion of the vector (prohibiting selection of elements from other subportions). Hence, it will be appreciated that a variety of encoding options could be provided to address the restricted bit encoding space in the predicate register. Nevertheless, it can be helpful to use a predicate register to encode the permutation pattern to avoid consuming an additional vector source register which might make it harder for some implementations to fuse with a subsequent vector instruction already using the maximum number of source vector registers (although it will be appreciated that an example instruction using a source vector register to encode the permutation pattern could also be used). Figures 6 and 7 illustrate further examples of permute prefix instructions, respectively a “zip” and “unzip” variant of the permute prefix instruction. Both these variants do not require any operand 48 for defining the permutation pattern as the permutation pattern is implicit from the opcode 40. Both these variants take a second source vector operand, in this example defined using a second source vector register Zm defined in a separate register identifier field 47 from the first source vector register field 46 defining the register Zn used to provide a first source vector operand (although in other examples the second source vector register could be defined with reference to the same register identifier field as the first source vector register, using a similar technique to that shown in Figure 5). For the “zip” permute prefix variant shown in Figure 6, the permutation pattern interleaves vector elements selected alternately from the lower halves of the two source vector operands corresponding to registers Zn, Zm into the respective element positions of the permuted vector operand corresponding to Zd, retaining the same relative ordering between the series of elements selected from a given one of the source vector operands. For example, where the lower half of the first source vector operand Zn comprises elements V0-V3 and the lower half of the second vector operand Zm comprises elements V8-V11, the permuted source vector operand comprises elements VO, V8, V1, V9, V2, V10, V3, V11 as shown in Figure 6. As shown in Figure 6, an alternative “zip” permute prefix variant could instead select the interleaved elements from the upper halves of the respective source vector operands Zn, Zm. For the “unzip” permute prefix variant shown in Figure 7, the permutation pattern selects vector elements from alternate positions within the first source vector operand and second source vector operand and concatenates these to form the elements of the permuted vector operand. For the main example UZP1PRFX the selected elements are selected from the even-numbered element positions 0, 2, 4, etc. in the respective source vector operands, while for an alternative example UZP2PRFX shown in the lower part of Figure 7 the selected elements are selected from the odd-numbered element positions 1, 3, 5, etc. in the respective source vector operands. These are just some examples of possible permutations that could be represented by a permute prefix instruction, and it will be appreciated that further examples are possible. For any of these examples, some processor implementations may choose to fuse the permute prefix instruction with a following vector processing instruction to generate a fused micro-operation, based on the assumptions represented by the instruction fusion hint encoded using the opcode. Figure 8 is a flow chart illustrating a method for processing a permute prefix instruction. At step 100, the instruction decoding circuitry 8 detects whether an instruction that has been decoded is a permute prefix instruction. If not, then the instruction decoding circuitry 8 generates one or more micro-operations corresponding to another type of instruction, which are passed to subsequent pipeline stages for processing. However, if the instruction is a permute prefix instruction, then at step 102 the instruction decoding circuitry 8 determines whether the permute prefix instruction should be fused with the next instruction. For example, the instruction fusion circuitry 50 may determine whether the next instruction in program order after the permute prefix instruction is an instruction type for which a fused micro-operation is supported, and / or whether any other conditions for fusion are satisfied (e.g. the permute prefix instruction and next instruction both appearing in the same decode window). However, any assumptions regarding the next instruction that are architecturally defined as being indicated by the instruction fusion hint do not need to be checked by the instruction fusion circuitry 50 (e.g. there may be no need to compare register specifiers of the permute prefix instruction and the next instruction to determine whether it would be safe to fuse these instructions). If the instruction fusion circuitry 50 determines to fuse the instructions, then at step 104, the instruction fusion circuitry 50 generates a fused micro-operation corresponding to the permute prefix instruction and the next instruction. For example, the fused micro-operation may specify the destination vector register of the permute prefix instruction and any other source vector registers of the permute prefix instruction and the next instruction, and the predicate register of the permute prefix instruction if provided for that variant of the permute prefix instruction, and may indicate that the execute stage 14 should perform a combined permutation-vector-processing operation as shown in Figure 3 whereby the permuted vector operand resulting from the permutation represented by the permute prefix instruction is used as a source operand for the subsequent vector processing operation (e.g. vector ALU operation or vector store operation). At step 106, processing circuitry within the execute stage 14 of the pipeline processes the fused micro-operation to perform a permute operation on the permute source vector operand of the permute prefix instruction and perform a vector processing operation on the permuted source vector operand (optionally in combination with any other source operands of the vector processing operation). On the other hand, if at step 102, the instruction decoding circuitry 8 determines not to fuse the permute prefix instruction with the next instruction (either because no instruction fusion circuitry 50 is provided on this implementation, or because while the instruction fusion circuitry 50 is provided, the permute prefix instruction and next instruction do not meet all conditions for fusion), then at step 108 the instruction decoding circuitry 8 generates a permute micro-operation, separate from the micro-operation generated for the next instruction. At step 110, the permute micro-operation is processed by the processing circuitry (execute stage) 14 to perform the permute operation represented by the permute prefix instruction, to permute a source vector operand to generate a permuted vector operand. At step 112, the processing circuitry 14 processes a micro-operation corresponding to the next instruction in program order after the permute prefix instruction (which may or may not use the permuted vector operand generated in response to the permute micro-operation). Figure 9 illustrates processing of a permute-pattern-predicate-setting instruction, which may be supported in the ISA to provide helper functions for generating predicate values to represent commonly occurring permutation patterns, to assist with supporting the permute prefix instruction variants shown in Figures 4 and 5 for example. At step 200, the instruction decoding circuitry 8 decodes an instruction and determines whether that instruction is a permute-pattern-predicate-setting instruction. If not, then the other type of instruction is decoded in a manner specific to that instruction. If the instruction is the permute-pattern-predicate-setting instruction, then the decoder 8 generates a micro-operation which once processed by the processing circuitry 14 controls the processing circuitry 14 to update a target predicate register to specify an updated permutation pattern. That updated permutation pattern could be specified in different ways, either based on an explicit operand of the permute-pattern-predicate-setting instruction, or based on a fixed rule defined for a given variant of the permute-pattern-predicate-setting instruction. For example, examples of predicate setting rules for the permute-pattern-predicate-setting instruction could include: generation of index-like patterns (e.g. 0, 0, 0, 3, 3, 3, 6, 6, 6; or 1, 1, 1, 1, 5, 5, 5, 5, 9, 9, 9, 9), e.g. based on one or more operands defining one or more of: a starting index value for the pattern, the number of successive repetitions of the same index value to be included in a given portion of the predicate value, and the offset between the index value in one portion of repeated index values and the next portion of repeated index values; setting each index value of the predicate to a value represented by a portion of a corresponding vector element of a source vector operand of the permute-pattern-predicate-setting instruction; adding a defined increment value to each index value already stored in the target predicate register (e.g. the increment value could be variably specified using an instruction operand, or fixed by design, e.g. to 1). duplicating an index pattern defined in a given operand multiple times within the predicate value (e.g. if the given operand specifies a pattern (0, 5, 12, 13), the instruction could cause a pattern (0, 5, 12, 13, 0, 5, 12, 13, 0, 5, 12, 13, etc.) to be defined in the target predicate register. Again, it will be appreciated that these are just some examples of possible helper functions that could support setting of predicate values to represent permutation patterns. 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, System Verilog, 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 10 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 730, optionally running a host operating system 720, supporting the simulator program 710. 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. 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 730), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 710 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 700 (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 710. Thus, the program instructions of the target code 700 described above, including a permute prefix instruction as discussed above, may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features. The simulation program 710 may comprise instruction decoding program logic 712 for decoding instructions of the target program code, and processing program logic 714 for controlling the hots apparatus 730 to perform data processing operations in response to the instructions decoded by the instruction decoding program logic 712. For example, the instruction decoding program logic 712 may include “if, then, else” type instructions (or conditional compare instructions and branch instructions) which cause conditional selection of corresponding program instruction routines depending on the encoding of an instruction in the target code, and the processing program logic 714 may comprise the corresponding program instruction routines (written in the native instruction set architecture supported by the host hardware) which are invoked by the decoding program logic 712 to emulate a given instruction of the target code 700. Such simulation programs can be useful for allowing target code written with a non-native ISA to be executed on a host apparatus 730 not supporting that ISA. Also, the simulation program 710 can allow testing of software written based on newly introduced ISA features, for which no real hardware is yet available supporting those features, to be tested in parallel with continuing development of the real hardware, as the software can execute on the simulation platform provided by the simulation program 710 to identify bugs in the software so that once the hardware is available the software can be ready for use more quickly. 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 configured to decode instructions to generate microoperations; andprocessing circuitry configured to perform data processing operations in response to the micro-operations decoded by the instruction decoding circuitry; in which:in response to a permute prefix instruction specifying at least one permute source vector register and a destination vector register, the instruction decoding circuitry is configured to generate a micro-operation to control the processing circuitry to perform at least a permute operation to permute vector elements of at least one permute source vector operand specified by the permute source vector register to generate a permuted vector operand corresponding to the destination vector register; andthe permute prefix instruction has an encoding providing an instruction fusion hint indicating to the instruction decoding circuitry that a next instruction in program order after the permute prefix instruction is expected to be a vector processing instruction specifying, as a source vector register for defining a source vector operand to which a vector processing operation is to be applied, the destination vector register of the permute prefix instruction.

2. The apparatus according to claim 1, wherein the instruction fusion hint indicates that, at least when the next instruction specifies a destination vector register, the next instruction is expected to be a destructive instruction specifying, as both a source vector register and the destination vector register of the destructive instruction, the destination vector register of the permute prefix instruction.

3. The apparatus according to any of claims 1 and 2, wherein the permute prefix instruction specifies an element size indication indicative of a vector element size for the at least one permute source vector operand specified by the at least one permute source vector register; andthe instruction fusion hint also indicates to the instruction decoding circuitry that the next instruction is expected to specify an element size indication indicating a same vector element size as the element size indication of the permute prefix instruction.

4. The apparatus according to any preceding claim, in which the instruction decoding circuitry comprises instruction fusion circuitry configured to fuse the permute prefix instruction and the next instruction to generate a fused micro-operation to control the processing circuitry to perform both the permute operation and a vector processing operation represented by the next instruction.

5. The apparatus according to claim 4, in which the instruction fusion circuitry is configured to fuse the permute prefix instruction and the next instruction without checking whether the source vector register of the next instruction is the same register as the destination vector register of the permute prefix instruction.

6. The apparatus according to any of claims 4 to 5, in which the instruction fusion circuitry is configured to fuse the permute prefix instruction and the next instruction based on an assumption that the next instruction is a destructive instruction specifying, as both a source vector register and a destination vector register of the destructive instruction, the destination vector register of the permute prefix instruction, without checking whether said assumption is correct.

7. The apparatus according to any of claims 4 to 6, in which the instruction fusion circuitry is configured to fuse the permute prefix instruction and the next instruction without checking whether an element size indication specified by the permute prefix instruction specifies the same vector element size as an element size indication specified by the next instruction.

8. The apparatus according to any of claims 4 to 7, in which the instruction fusion circuitry is configured to fuse the permute prefix instruction and the next instruction at least when the next instruction is a vector arithmetic instruction for which the vector processing operation comprises a vector arithmetic operation.

9. The apparatus according to claim 8, in which the vector arithmetic instruction comprises a vector multiply instruction for which the vector arithmetic operation comprises an operation comprising a multiplication.

10. The apparatus according to claim 9, wherein the operation comprising a multiplication comprises a fused-multiply add operation performed on vector data elements represented in a floating-point representation.

11. The apparatus according to any of claims 4 to 10, in which the instruction fusion circuitry is configured to fuse the permute prefix instruction and the next instruction at least when the next instruction is a vector store instruction for which the vector processing operation comprises storing the source vector operand to one or more memory locations identified based on an address specified by the vector store instruction.

12. The apparatus according to any preceding claim, in which the permute prefix instruction specifies a predicate register and the permute operation comprises permuting vector elements ofthe at least one permute source vector operand according to a permutation pattern identified by a predicate value specified by the predicate register.

13. The apparatus according to claim 12, in which the permute operation comprises, for each vector element of the permuted vector operand, setting that vector data element of the permuted vector operand to a value determined based on a selected vector element at a selected vector element position within the at least one permute source vector operand, where the selected vector element position is indicated by an index value specified by a corresponding portion of the predicate value.

14. The apparatus according to any of claims 12 and 13, in which the instruction fusion hint also indicates to the instruction decoding circuitry that the next instruction is expected to be an unpredicated vector processing instruction.

15. The apparatus according to any of claims 12 to 14, in which in response to a permute-pattern-predicate-setting instruction decoded by the instruction decoding circuitry, the processing circuitry is configured to update a target predicate register specified by the permute-pattern-predicate-setting instruction to specify an updated permutation pattern.

16. The apparatus according to any preceding claim, wherein the permute operation corresponding to the permute prefix instruction comprises permuting the vector elements of the at least one permute source vector operand according to a permutation pattern selected from a first set of one or more permutation patterns supported by the permute prefix instruction; andin response to the instruction decoding circuitry decoding a non-prefix permute instruction specifying a given source vector operand and having a different encoding to the permute prefix instruction, the processing circuitry is configured to perform a permute operation comprising permuting vector elements of the given source vector operand according to a permutation pattern selected from a second set of permutation patterns, the non-prefix permute instruction having an encoding which does not provide the instruction fusion hint.

17. The apparatus according to claim 16, in which the second set of permutation patterns comprises each of the permutation patterns of the first set supported by the permute prefix instruction.

18. The apparatus according to any of claims 16 and 17, in which the second set of permutation patterns comprises at least one permutation pattern not supported by the first set of permutation patterns.

19. The apparatus according to any of claims 16 to 18, in which the non-prefix permute instruction supports performing the permute operation on vector elements of the given source vector operand having a vector element size selected from a second set of vector element sizes, the second set of vector element sizes comprising at least one vector element size not supported by a first set of vector element sizes supported for the permute operation performed in response to the permute prefix instruction.

20. Computer-readable code for fabrication of the apparatus according to any preceding claim.

21. A computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: instruction decoding program logic configured to decode instructions of the target program code; andprocessing program logic configured to perform data processing operations in response to the instructions decoded by the instruction decoding program logic; in which:in response to a permute prefix instruction of the target program code specifying at least one permute source vector register and a destination vector register, the instruction decoding program logic is configured to control the processing program logic to perform at least a permute operation to permute vector elements of at least one permute source vector operand specified by the at least one permute source vector register to generate a permuted vector operand corresponding to the destination vector register; andthe permute prefix instruction has an encoding providing an instruction fusion hint indicating to the instruction decoding program logic that a next instruction of the target program code in program order after the permute prefix instruction is expected to be a vector processing instruction specifying, as a source vector register for defining a source vector operand to which a vector processing operation is to be applied, the destination vector register of the permute prefix instruction.

22. A method comprising:decoding instructions to generate micro-operations; andperforming data processing operations in response to the micro-operations; in which:in response to a permute prefix instruction specifying at least one permute source vector register and a destination vector register, the permute prefix instruction is decoded to generate a micro-operation to control processing circuitry to perform at least a permute operation to permute vector elements of at least one permute source vector operand specified by the at least onepermute source vector register to generate a permuted vector operand corresponding to the destination vector register; andthe permute prefix instruction has an encoding providing an instruction fusion hint indicating that a next instruction in program order after the permute prefix instruction is expected5 to be a vector processing instruction specifying, as a source vector register for defining a source vector operand to which a vector processing operation is to be applied, the destination vector register of the permute prefix instruction.10

Images