[LLVMdev] [LLVM, llc] TypeLegalization, DAGCombining, vectors loading

[Duncan Sands]

Hi Nadav,

> I completely agree with you.  The vectorizer (or whoever generates this vector code) should be aware of the target instruction set and decide on the vectorization factor accordingly.  When our vectorizer[1] decides on the vectorization factor, it takes into account the available instruction set, as well as the operations used in the program.
> For example, AVX1 focuses on floating point operations, and vectorizing integer code to VF=8, would generate suboptimal code, because it would require the op legalizer to unpack/pack operations on each 'hole' in the instruction set.

for what it's worth I agree too.  While I think support for <2 x i5> and
friends should be added some day, that's only so we can bask in the quiet
enjoyment of knowing that the code generators are "complete", not because
it is actually useful for anything.

Ciao, Duncan.

>
> Thanks,
> Nadav
>
>
>
> [1] Intel's OpenCL SDK Vectorizer
>
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dan Gohman
> Sent: Tuesday, December 13, 2011 23:21
> To: Stepan Dyatkovskiy
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] [LLVM, llc] TypeLegalization, DAGCombining, vectors loading
>
> On Dec 13, 2011, at 11:37 AM, Stepan Dyatkovskiy wrote:
>
>> Please ignore my concurrent post :-) Lets proceed in this branch.
>>
>>> do you understand what it means in the non-vector case?
>> I'm beginning to understand it now. It means the type that should be in
>> abstract VM memory. Isn't it? The main question about MemoryVT is:
>> should it be original always (as it was defined in .ll) or not?
>>
>> About vectors with element size less than 8 bits. This topic is
>> interesting for me. I would like to work with it. What is the best place
>> for discussing? llvmdev or bug #1784 (vectors of i1 and vectors x86 long
>> double don't work) ?
>
>
> I tried to fix PR1784 multiple times. I have since had
> some insights which have changed my mind.
>
> <4 x i32>  on a machine with<8 x i32>  vectors misses out on
> 50% of the theoretical performance.<8 x i32>  on a machine
> with only<4 x i32>  takes on unneeded code bloat and register
> pressure. No amount of heroism in LegalizeTypes can change
> this basic situation.
>
> The further you go, either in the conceptual distance
> between code and target machine, or in diversity of target
> machines, the worse the problem gets.
>
> Also, all of the proposed solutions for fixing exotic
> vector types have substantial downsides.
>
> So in addition to asking "why doesn't<2 x i5>  work?", it's
> also useful to ask "who is producing<2 x i5>  values, and
> what am I expecting to get out of letting them do that?"
>
> Dan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev