[PATCH] Fix PR15131

Nadav Rotem nrotem at apple.com
Wed Mar 6 16:33:45 PST 2013


I think that SROA assumes that vector operands are not bitpacked. Can you check if we can SROA the packed vectors ?

Thanks,
Nadav 

On Mar 6, 2013, at 9:35 AM, Michael Liao <michael.liao at intel.com> wrote:

> ping again. - michael
> 
> On Fri, 2013-03-01 at 00:35 -0600, Hal Finkel wrote:
>> ----- Original Message -----
>>> From: "Michael Liao" <michael.liao at intel.com>
>>> To: llvm-commits at cs.uiuc.edu
>>> Sent: Thursday, February 28, 2013 11:13:30 PM
>>> Subject: [PATCH] Fix PR15131
>>> 
>>> Hi All,
>>> 
>>> The attached patch fixes PR15131 which is caused by mismatching
>>> between
>>> global vector constant emission logic and vector in-memory
>>> representation (bitpacked now.)
>> 
>> + at X = global <4 x i1> <i1 0, i1 1, i1 2, i1 3>
>> + at Y = global <4 x i3> <i3 0, i3 1, i3 2, i3 3>
>> + at Z = global <5 x i30> <i30 0, i30 1, i30 2, i30 3, i30 4>
>> +
>> +; CHECK: byte 10
>> +; CHECK: short 1672
>> +; CHECK: quad 2305843010287435776
>> +; CHECK: quad 288230376353038336
>> +; CHECK: quad 0
>> +; CHECK: quad 0
>> 
>> Is this really the behavior that we want, or do we only want to bitpack i1 vectors? Or vectors with an element size less than 1 byte? I could be wrong, but I think that at least your last example (<5 x i30>) will break currently-working code that operates on vectors of arbitrarily-sized integers. Duncan?
>> 
>> -Hal
>> 
>>> 
>>> Thanks for review
>>> - Michael
>>> 
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
> 
> <0001-Fix-PR15131-part-of-PR1784.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130306/aa516f59/attachment.html>


More information about the llvm-commits mailing list