search for: int_vector_reduce_add

...code themselves. Front-ends which want to do this currently must deal with the difficulties of generating the tree shuffle pattern to ensure that they're matched to efficient instructions later. Proposal ======== We propose to introduce the following reduction intrinsics as a starting point: int_vector_reduce_add(vector_src) int_vector_reduce_fadd(vector_src) int_vector_reduce_and(vector_src) int_vector_reduce_or(vector_src) int_vector_reduce_eor(vector_src) int_vector_reduce_mul(vector_src) These intrinsics do not do any type promotion of the scalar result. Architectures like SVE which can do type promoti...

...les into a ZIP. The argument that the intrinsic is harder to destroy through optimisation passes is the same as other cases of stiff rich semantics vs. generic pattern matching, so orthogonal to this issue. > We propose to introduce the following reduction intrinsics as a starting point: > int_vector_reduce_add(vector_src) Is this C intrinsic? Shouldn't an IR builtin be something like: @llvm.vector.reduce.add(...) ? > These intrinsics do not do any type promotion of the scalar result. Architectures like SVE which can do type promotion and reduction in a single instruction can pattern match the...

...ent that the intrinsic is harder to destroy through > optimisation passes is the same as other cases of stiff rich semantics > vs. generic pattern matching, so orthogonal to this issue. > > >> We propose to introduce the following reduction intrinsics as a starting point: >> int_vector_reduce_add(vector_src) > > Is this C intrinsic? Shouldn't an IR builtin be something like: > > @llvm.vector.reduce.add(...) ? You're right, in IR assembly it would appear like that. The ones I proposed were the tablegen syntax of the intrinsics definitions, so in practice they would look...