[LLVMdev] Extending vector operations
Stefanus Du Toit
stefanus.dutoit at rapidmind.com
Tue Jul 22 06:33:39 PDT 2008
On 21-Jul-08, at 7:33 PM, Eli Friedman wrote:
> On Mon, Jul 21, 2008 at 1:21 PM, Stefanus Du Toit
> <stefanus.dutoit at rapidmind.com> wrote:
>> 1) Vector shl, lshr, ashr
>>
> 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.
That's great. Please do send it over, it'd be great to have a starting
point like this.
>> 2) Vector strunc, sext, zext, fptrunc and fpext
>>
> 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.
Right, though it seems they can generally be split up as necessary (as
Chris pointed out as well). I just don't know how well this fits the
existing infrastructure. More pointers would be welcome here!
>> 5) Vector comparisons that return <N x i1>
>>
> 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?
Right, the type that needs to be used at the birthpoint of the value
will generally be determined by the operation being performed to
define it. At uses, that representation will have to be converted.
There are some operations which may not provide a unique
representation at a definition. Phi statements are the most obvious
ones - if a phi statement joins two boolean vectors of different
representations, the optimal choice of the result may depend on where
that result is used.
Conversion code that may need to be inserted can also probably benefit
from optimizations like CSE.
--
Stefanus Du Toit <stefanus.dutoit at rapidmind.com>
RapidMind Inc.
phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463
More information about the llvm-dev
mailing list