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

Yes. It doesn't works properly. I also read the your discussion in bug 
1784: http://llvm.org/bugs/show_bug.cgi?id=1784
I found that know Type and Vector Lagalization and in DAGCombining 
implicitly assumed that element size of MemoryVT is multiply of 8 bits. 
Thats the main reason why v2i5 works improperly with load/store. But I 
can't determine exactly what MemoryVT means...

-Stepan.

Stepan Dyatkovskiy wrote:
> Probably, I misunderstood MemoryVT purpose? Should it be a type that
> equal to original vector type (e.g. v2i5). Or it is a type of memory
> area for this vector (e.g. v2i8) ?
>
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>> Hi all. The question about 'load' instruction.
>> When we promote
>> v2i5 = load<addr>   ;<MemoryVT = v2i5>
>> to
>> v2i64 = load<addr>   ;<MemoryVT = v2i5>
>>
>> should we insert vector shuffling that moves second v2i5 item to the
>> second v2i64 item?
>>
>> Or it is still depends from target?
>>
>> Thanks.
>>
>> -Stepan.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi Stepan,
> Yes. It doesn't works properly. I also read the your discussion in bug
1784:
> http://llvm.org/bugs/show_bug.cgi?id=1784
> I found that know Type and Vector Lagalization and in DAGCombining
implicitly
> assumed that element size of MemoryVT is multiply of 8 bits. Thats the main
> reason why v2i5 works improperly with load/store. But I can't determine
exactly
> what MemoryVT means...
do you understand what it means in the non-vector case?

Ciao, Duncan.
>
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>> Probably, I misunderstood MemoryVT purpose? Should it be a type that
>> equal to original vector type (e.g. v2i5). Or it is a type of memory
>> area for this vector (e.g. v2i8) ?
>>
>> -Stepan.
>>
>> Stepan Dyatkovskiy wrote:
>>> Hi all. The question about 'load' instruction.
>>> When we promote
>>> v2i5 = load<addr> ;<MemoryVT = v2i5>
>>> to
>>> v2i64 = load<addr> ;<MemoryVT = v2i5>
>>>
>>> should we insert vector shuffling that moves second v2i5 item to
the
>>> second v2i64 item?
>>>
>>> Or it is still depends from target?
>>>
>>> Thanks.
>>>
>>> -Stepan.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Duncan Sands wrote:
 > 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. So this type should be original always (as it was 
defined in .ll) isn't it?

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