search for: lagalization

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 purpo...

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

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...

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.

Hi Chris, Thank you very much for your answer! It helps me to move in the right direction. When you explain it, it sounds rather easy. But I still have some tricky issues. This is either because I'm not so familiar with LLVM or because it is a bit underestimated how much LLVM legalizer/expander relay on expandable types to be integers (see my explanations below). --- Chris Lattner <sabre

On Mon, 20 Nov 2006, Roman Levenstein wrote: >> The first step is to get somethign simple like this working: >> >> void %foo(double* %P) { >> store double 0.0, double* %P >> ret void >> } >> >> This will require the legalizer to turn the double 0.0 into two >> integer zeros, and the store into two integer stores. > > Sample code

On Fri, 17 Nov 2006, Roman Levenstein wrote: > I still have some questions about FP emulation for my embedded target. > To recap a bit: > My target only has integer registers and no hardware support for FP. FP > is supported only via emulation. Only f64 is supported. All FP > operations should be implemented to use i32 registers. ok > allocation. But anyway, I have an almost

Hi, I still have some questions about FP emulation for my embedded target. To recap a bit: My target only has integer registers and no hardware support for FP. FP is supported only via emulation. Only f64 is supported. All FP operations should be implemented to use i32 registers. Based on the fruitful discussions on this list I was already able to implement mapping of the FP operations to