search for: legalizetyp

Hi all, I plan to turn on the new type legalization infrastructure "LegalizeTypes" by default tomorrow. This is a redesign/reimplementation of the logic currently in LegalizeDAG that turns (for example) 64 bit arithmetic on a 32 bit machine into a series of 32 bit operations. As well as being a cleaner design, it also supports code generation for arbitrary precision int...

On Oct 26, 2008, at 1:03 AM, Duncan Sands wrote: > Hi all, I plan to turn on the new type legalization infrastructure > "LegalizeTypes" by default tomorrow. This is a redesign/ > reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. > As well > as being a cleaner design, it also supports code generatio...

Hi, I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change anything and Combine(AfterLegalizeTypes) was not called. Vector legalization that comes afterwards just scalarized the operation. SelectionDAGISel::CodeGenAndEmitDAG() .. CurDAG->Combine(BeforeLegal...

On Mon, Feb 6, 2012 at 11:54 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. > I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change anything and Combine(AfterLegalizeTypes) was not called. > Vector legalization that comes afterwards just scalarized the operation. > > SelectionDAGISel::CodeGenAndEmitDAG() > .. >   CurDAG-...

On Sun, Oct 26, 2008 at 2:03 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi all, I plan to turn on the new type legalization infrastructure > "LegalizeTypes" by default tomorrow. This is a redesign/reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. As well > as being a cleaner design, it also supports code generation for arbitrar...

....7 using non-system gcc/binutils. My gcc version is 4.1.2, and binutils is 2.17.50.0.15. I get the following errors `.L2438' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) .... .... make[1]: *** [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7.so] Error 1 ma...

In 3.1, the backend is very slow to legalize types. Following is the code snippet which may be the culprit: %Result.i.i.i97 = alloca i33, align 8 %Result.i.i.i96= alloca i33, align 8 %Result.i.i.i95 = alloca i33, align 8 %Result.i.i.i94 = alloca i33, align 8 %Result.i.i.i93 = alloca i33, align 8 %Result.i.i.i92= alloca i33, align 8 %Result.i.i.i91 = alloca i33, align 8

...building LLVM; see http://llvm.org/docs/GettingStarted.html#brokengcc . Try upgrading your gcc version. -Eli > `.L2438' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) > .... > .... > make[1]: *** [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7...

At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND gives me the new chain LOAD -> ANY_EXTEND -> AND. I want to optimize ANY_EXTEND but is not analyzed in the same Combine(). Combine(AfterLegalizeTypes) is no called at all. - Elena -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gm...

...ngStarted.html#brokengcc > .  Try upgrading > your gcc version. > > -Eli > > > `.L2438' referenced in section > `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' > of > /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): > defined in discarded section > `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' > of > /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) > > .... > > .... > > make[1]: *** > [/build/toolchain/src...

...ngStarted.html#brokengcc > .  Try upgrading > your gcc version. > > -Eli > > > `.L2438' referenced in section > `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' > of > /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): > defined in discarded section > `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' > of > /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) > > .... > > .... > > make[1]: *** > [/build/toolchain/src...

PPC Altivec supports vector type v16i8 (and others) where the element type is not legal (in llvm's implementation). When we have a BUILD_VECTOR of these types with constant elements, LegalizeTypes first promotes the element types to i32, then builds a constant pool entry of type v16i32. This is wrong. I can fix it by truncating the elements back to i8 in ExpandBUILD_VECTOR. Does this seem like the right approach? I ask because we'll be relying on ConstantVector::get and g...

Hi, Can anyone please tell me how can I scalarize or de-vectorize the llvm vector ir. In this (http://old.nabble.com/Re%3A-Thoughts-about-the-llvm-architecture---p2961720 3.html) thread I found LegalizeTypes will do this while generating machine code from llvm ir.. How do I convert llvm ir to selection Dag. And scalarize the vector ir and again get back llvm ir. Thanks & Regards, Pachauri -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:...

Hi Chris, > Why not define an "add with overflow" intrinsic that returns its value and > overflow bit as an i1? what's the point? We have this today with apint codegen (if you turn on LegalizeTypes). For example, this function define i1 @cc(i32 %x, i32 %y) { %xx = zext i32 %x to i33 %yy = zext i32 %y to i33 %s = add i33 %xx, %yy %tmp = lshr i33 %s, 32 %b = trunc i33 %tmp to i1 ret i1 %b } codegens (on x86-32) to cc: xorl %eax, %eax movl 4(%esp), %ecx...

Hi Chris, > > what's the point? We have this today with apint codegen (if you turn on > > LegalizeTypes). For example, this function > > The desired code is something like: > > foo: > addl %eax, %ecx > jo overflow_happened > use(%ecx) how's an intrinsic going to help with this? Also, is there any chance of codegen being capable one day of combining carry ar...

...hey have been very helpful! Note: Sorry, i forgot to group reply.... ---------- Forwarded message ---------- From: Duncan Sands <baldrick at free.fr> Date: 2011/9/4 Subject: Re: [LLVMdev] Some questions on SelectionDAG To: Zakk <zakk0610 at gmail.com> Hi Zak, Therefore, after the LegalizeType phase, maybe SelectionDAG have > unsupported > type node? > no. As I tried to explain, there is no node with type MVT:i1 after type legalization. There is a VALUETYPE node with type MVT::Other that contains the type MVT::i1 as an auxiliary datum. My confusion is the unsupported type...

...le > to disable parts of itself in order to avoid foiling the backends. > Practicality sometimes steers elsewhere of course. Please explain > why you think suppressing this particular optimization is better; > it isn't obvious how it would look different in the end. Yeah, I agree. LegalizeTypes should be able to trivially lower this. -Chris

...Crash.ll | llc -march=arm -mattr=+v6 Processed value not in any map! 0 llc 0x09222aa7 1 llc 0x09223146 2 0x4001c400 __kernel_sigreturn + 0 3 libc.so.6 0x4019d018 abort + 392 4 llc 0x08d832ff 5 llc 0x08d83598 6 llc 0x08d84197 llvm::SelectionDAG::LegalizeTypes() + 45 7 llc 0x08d0e8db llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1261 8 llc 0x08d11218 llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*, llvm::ilist_iterator<llvm::Instruction>, llvm::ilist_iterator<llvm::Instruction>) + 456 9 llc 0x08d11cca llvm...

> > I don't think there is code in Legalizer to expand GlobalAddress. But you > can custom lower it. X86 custom lower GlobalAddress nodes for a different > reason. > > Evan > Hmmm...That means we have to make i16 as a legal type (since GlobalAddresses are 16-bits) and custom lower all 16-bit operations to 8-bit operations. I was thinking to take advantage of the

...ABRT) at line 1 > while running: llvm-as < > /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll > | llc -march=arm -mattr=+v6 > Processed value not in any map! building with ENABLE_EXPENSIVE_CHECKS=1 turns on a bunch of extra sanity checking in LegalizeTypes. "make check" used to pass all tests with this on. I notice that the failing node is a target constant. These are a special case, and the code dealing with them was tweaked a little while ago - probably that caused this. I will take a look. Ciao, Duncan.