Lots of parts of LLVM "know" about loads, and would be quite broken if
loads could suddenly be gathers.
Also, autovectorizers have to know a fair amount about target
instruction sets, especially if they're going to vectorize non-trivial things
like gathers.
So target-specific intrinsics seem like a reasonable start. A generic
'gather' instruction/intrinsic may make sense at some point, if it can
be designed cleanly enough.
Dan
Right, the natural evolution of LLVM IR is that things start out as intrinsics, then eventually get built into the instruction set if it makes sense. This is how unaligned loads were handled early on, for example.
-Chris
Chris Lattner <clattner@apple.com> writes:
So I was wondering whether in LLVM a gather operation is best
represented with a 'load' instruction taking vector operands,
or whether it's better to define it as a separate 'gather'
instruction. What would be the pros and cons of each approach,
and what do you think should be the long-term goals for the
LLVM instruction set?Lots of parts of LLVM "know" about loads, and would be quite broken if
loads could suddenly be gathers.
What are the problem areas? It seems natural to me to extend loads to
be able to take vectors of offsets and/or pointers.
Also, autovectorizers have to know a fair amount about target
instruction sets, especially if they're going to vectorize
non-trivial things like gathers.
True.
So target-specific intrinsics seem like a reasonable start. A
generic 'gather' instruction/intrinsic may make sense at some
point, if it can be designed cleanly enough.Right, the natural evolution of LLVM IR is that things start out as
intrinsics, then eventually get built into the instruction set if it
makes sense. This is how unaligned loads were handled early on, for
example.
Yes, intrinsics make perfect sense for the moment.
-Dave