search for: lagal

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

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

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.

...tioned above. The problem is probably that it cannot extract the corresponding halves from the target specific SELECT_CC node (and it can do it without problems for usual integer-based ISD::SELECT_CC nodes). At this place I got stuck, since I do not see how I can overcome it. Overall, changing the lagalizer to support the expansion of tge MVT::f64 proves to be more complicated as I initially expected. And it also seems to be a bit of overkill. Therefore I was thinking about the special pass after code selection, but before register allocation. After all, I just want to do a transformation on all i...

...and it can do it without problems for usual integer-based > ISD::SELECT_CC nodes). At this place I got stuck, since I do not see > how I can overcome it. I don't follow, can you try explaining it and including the relevant code that isn't working for you? > Overall, changing the lagalizer to support the expansion of tge > MVT::f64 proves to be more complicated as I initially expected. And it > also seems to be a bit of overkill. Therefore I was thinking about the > special pass after code selection, but before register allocation. Ok. > After all, I just want to do...

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