[LLVMdev] Extending vector operations

[Eli Friedman]

On Mon, Jul 21, 2008 at 1:21 PM, Stefanus Du Toit
<stefanus.dutoit at rapidmind.com> wrote:
> 1) Vector shl, lshr, ashr
>
> I think these are no-brainers. We would like to extend the semantics
> of the shifting instructions to naturally apply to vectors as well.
> One issue is that these operations often only support a single shift
> amount for an entire vector. I assume it should be fairly
> straightforward to select on this pattern, and scalarize the general
> case as necessary.

I have a rough draft of a patch for this that works reasonably well
for simple cases... I don't think I really have the time to finish it
properly, but I'll clean it up a bit and send it to you as a starting
point.

> 2) Vector strunc, sext, zext, fptrunc and fpext
>
> Again, I think these are hopefully straightforward. Please let me know
> if you expect any issues with vector operations that change element
> sizes from the RHS to the LHS, e.g. around legalization.

These are tricky to generate efficient code for because they change
the size of the vector and most likely introduce illegal vectors.
It'll be a lot of work to get these working well for non-trivial
cases.

> 5) Vector comparisons that return <N x i1>
>
> This is maybe not a must-have, and perhaps more a question of
> preference. I understand the current vfcmp/vicmp semantics, returning
> a vector of iK where K matches the bitwidth of the operands being
> compared with the high bit set or not, are there for pragmatic
> reasons, and that these functions exist to aid with code emitted that
> uses machine-specific intrinsics.
>
> For code that does not use machine intrinsics, I believe it would be
> cleaner, simpler, and potentially more efficient, to have a vector
> compare that returns <N x i1> instead. For example, in conjunction
> with the above-mentioned vector select, this would allow a max to be
> expressed simply as a sequence of compare and select.
>
> I realize this is probably the most controversial change amongst
> these. I gather there is some concern about representing "variable
> width" i1s, but I would contend that that's the case even for i1s
> which are not vectors.

It makes sense; the difficulty is making CodeGen generate efficient
code for these constructs.  Legalization has to transform illegal
types into legal types, and as far as I know, none of the current
transformations varies the type transformation based on what is using
the value.  I don't know exactly how hard it would be, though... maybe
someone who's more familiar with the legalization infrastructure could
say more?

-Eli