llvm dev - Dec 2011 - [LLVMdev] [LLVM, llc] TypeLegalization, DAGCombining, vectors loading

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) ?

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

> 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.
Yes. Very SelectionDAG seems very complex for me. I spend all previous week to
learn it, but only now I'm begin to understand how all its parts cooperates
together.
> 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?"
2 x i5 ... Probably is not used anywhere. May be in 29 bit CPUs... But what
about N x i1 or N x i4? Since llvm assumes byte addressing there is a reason to
extend this kind of vectors to N x i8. This is a complex problem though.
Probably I missed something. But I have some draft patches that fixes load+store
problem for arm and for X86 rounding the size of vector element.

-Stepan.

Dan, 

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.

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.