[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