[LLVMdev] canonicalizing types for vector operations

Bob Wilson bob.wilson at apple.com
Wed Aug 19 09:50:36 PDT 2009


On Aug 17, 2009, at 8:16 AM, Chris Lattner wrote:

> On Aug 17, 2009, at 7:15 AM, Bob Wilson wrote:
>> I committed a change to fix pr4731 yesterday but after thinking about
>> it some more, I'd like to get other opinions about this.  Chris and I
>> talked last week about the need to canonicalize the types used for
>> Neon vector shuffles so that they get CSEd.  I guess this was an  
>> issue
>> that came up for SSE.
>>
>> For pr4731, I changed llvm-gcc to canonicalize a bitwise vector
>> operation to use i32 elements.  For these operations, the type  
>> doesn't
>> matter since the vector are treated as a bunch of bits.  I was
>> thinking that we should do the canonicalization for all the bitwise
>> vector operations.  But is llvm-gcc the right place to do that?  The
>> changes that I discussed with Chris were in code gen.  It seems like
>> the front-end is not the best place to do that kind of optimization
>> and that ideally the optimizer would be able to recognize that  
>> bitwise
>> vector operations do not depend on the element type.
>
>
> "It depends" :)
>
> If the front-end is generating an intrinsic, it is useful for it to  
> canonicalize the type.  This constraints the intrinsic more.
>
> However, the code generator should accept and "do the right thing"  
> with arbitrary shuffles.  If the front-end is generating a shuffle  
> instruction, the right place to handle this is in the code generator.
>
> Does that make sense?

Yes.  It sounds like my intuition was right that the canonicalization  
should be handled in the code generator for this case where no  
intrinsics or shuffles are involved.  I'll change it to use something  
like the patch that Sandeep included in the bug report.  Thanks.



More information about the llvm-dev mailing list