[llvm-dev] Question about VectorLegalizer::ExpandStore() with v4i1

Ahmed Bougacha via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 28 04:49:02 PDT 2016


On Tue, Jun 28, 2016 at 2:45 AM, jingu kang via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi All,
>
> Can someone comment below question whether it is wrong or not please?
>
> 2016-06-25 7:52 GMT+01:00 jingu kang <jaykang10 at gmail.com>:
>> Hi All,
>>
>> I have a problem with VectorLegalizer::ExpandStore() with v4i1.
>>
>> Let's see a example.
>>
>> * LLVM IR
>> store <4 x i1> %edgeMask_for.body1314, <4 x i1>* %27
>>
>> * SelectionDAG before vector legalization
>> ch = store<ST1[%16](align=4), trunc to v4i1> t0, t128, t32, undef:i64
>>
>> * SelectionDAG after vector legalization
>> ch = store<ST1[%16](align=4), trunc to i1> t0, t133, t32, undef:i64
>>   t133: i32 = extract_vector_elt t128, Constant:i64<0>
>> ch = store<ST1[%16](align=4), trunc to i1> t0, t136, t32, undef:i64
>>   t136: i32 = extract_vector_elt t128, Constant:i64<1>
>> ch = store<ST1[%16](align=4), trunc to i1> t0, t139, t32, undef:i64
>>   t139: i32 = extract_vector_elt t128, Constant:i64<2>
>> ch = store<ST1[%16](align=4), trunc to i1> t0, t142, t32, undef:i64
>>   t142: i32 = extract_vector_elt t128, Constant:i64<3>
>>
>> As you can see above SelectionDAG, if backend decides to expand vector
>> store with v4i1, vector legalizer generates 4 store with same
>> destination address. I think it needs to handle non-byte addressable
>> types like ExpandLoad(). When I look at ExpandLoad(), it handles the
>> case. If I implement new backend, I might have done custom lowering to
>> avoid this case. But I am using x86_64 target and it generates above
>> codes. How do you think about it? If I missed something, please let me
>> know.

JinGu,

Your analysis is correct, vectors of i1 are incorrectly legalized.
This is a known issue (http://llvm.org/PR22603); the tricky part about
fixing it is the need to settle on a memory layout for these vectors
(packed vs byte per i1;  packed would be compatible with AVX512, I
think).

-Ahmed

>> Thanks,
>> JinGu Kang
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list