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

jingu kang via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 28 06:16:54 PDT 2016


Thanks Ahmed.

2016-06-28 12:49 GMT+01:00 Ahmed Bougacha <ahmed.bougacha at gmail.com>:
> 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