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

[Dan Gohman]

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