search for: promoteop

...xor 0x1500f60, 0x15011b0 0x15012d0: ch = BasicBlock <bb20 0x14ff930> 0x15013e0: ch = brcond 0x1501330, 0x1501220, 0x15012d0 The setcc's are promoted to i32, since they are comparing i32 operands. The problem arises when the select (0x1500f60) is promoted by SelectionDAGLegalize::PromoteOp(), because the select's i1 is promoted to i8, which triggers an assert because select's arguments (i32) don't match the new, promoted value type. It's possible to convince the SELECT case inside of SelectionDAGLegalize::PromoteOp() that it should really look at the operands'...

B. Scott Michel wrote: > It'd be easy to hack PromoteOp to make a pass to determine all operands' > promoted value types, take the max, then figure out some way to > re-promote them to maximal promoted value type. Except that this is a > non-optimal solution requiring PromoteOp to potentially traverse the > operand tree twice. > &...

B. Scott Michel wrote: >B. Scott Michel wrote: > > >>It'd be easy to hack PromoteOp to make a pass to determine all operands' >>promoted value types, take the max, then figure out some way to >>re-promote them to maximal promoted value type. Except that this is a >>non-optimal solution requiring PromoteOp to potentially traverse the >>operand tree t...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...he INSERT_VECTOR_ELT instruction. In this case, it /// is necessary to spill the vector being inserted into to memory, perform @@ -179,94 +125,9 @@ SDValue PerformInsertVectorEltInMemory(SDValue Vec, SDValue Val, SDValue Idx, DebugLoc dl); - /// PromoteOp - Given an operation that produces a value in an invalid type, - /// promote it to compute the value into a larger type. The produced value - /// will have the correct bits for the low portion of the register, but no - /// guarantee is made about the top bits: it may be zero, sign-extended, or...

...integers. To do so, I tried to modify the HowToUseJIT example by replacing the Int32Ty with another size (let's say 12 bits for the example). While it compiles ok, I get the following assert at run-time: HowToUseJIT: LegalizeDAG.cpp:4059: llvm::SDOperand <unnamed>::SelectionDAGLegalize::PromoteOp(llvm::SDOperand): Assertion `NVT > VT && MVT::isInteger(NVT) == MVT::isInteger(VT) && "Cannot promote to smaller type!"' failed. The corresponding code is the following: SDOperand SelectionDAGLegalize::PromoteOp(SDOperand Op) { MVT::ValueType VT = Op.getValueTyp...

...vm/build-release/include -DL_mulsc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../2006-05-08-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_mulsc3.o cc1: /home/mcm/projects/llvm/build-release/../llvm-cvs/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:2826: llvm::SDOperand <unnamed>::SelectionDAGLegalize::PromoteOp(llvm::SDOperand): Assertion `getTypeAction(VT) == Promote && "Caller should expand or legalize operands that are not promotable!"' failed. ../../2006-05-08-llvm-gcc-4/gcc/libgcc2.c:1714: internal compiler error: Aborted Please submit a full bug report, with preprocessed sou...

...t would even make sense to have two > different mappings because of this? One mapping will be used for > allocation of virtual registers and the like and would always return a > legal type and the other will be used just as getTypeToTransformTo > () in > LegalizeOp(), ExpandOp() and PromoteOp() and can return also illegal > types? No need to change getTypeToTransformTo(). There is a getTypeToExpandTo () that is expand the type recursively until it find a legal type. > >> It's not done simply because there isn't a need for it right now. :-) > > Since I have t...

...correctness". May be it would even make sense to have two different mappings because of this? One mapping will be used for allocation of virtual registers and the like and would always return a legal type and the other will be used just as getTypeToTransformTo() in LegalizeOp(), ExpandOp() and PromoteOp() and can return also illegal types? > It's not done simply because there isn't a need for it right now. :-) Since I have this need, I'll try to find a solution for this issue and to provide a patch. -Roman __________________________________________________ Do You Yahoo!? Tired...

> >> d) Would it be possible with current implementation of soft-float >> support to map f32/f64 to integer types smaller than i32, e.g. to >> i16? >> I have the impression that it is not necessarily the case, since it >> would require that f64 is split into 4 parts. > > Yes, this should be fine. > >> This question is more about a theoretical

Hi All, There's a new snapshot of llvmgcc4 available here: http://nondot.org/sabre/2006-05-08-llvm-gcc-4.tar.gz This release includes the various portability fixes contributed on llvmdev, includes fixes to build with mainline CVS (and, thus, *requires* mainline CVS), and includes various other bug fixes. If you're interested, please try it out. Thanks, -Chris --

...; two > > different mappings because of this? One mapping will be used for > > allocation of virtual registers and the like and would always > return a > > legal type and the other will be used just as getTypeToTransformTo > > () in > > LegalizeOp(), ExpandOp() and PromoteOp() and can return also > illegal > > types? > > No need to change getTypeToTransformTo(). There is a > getTypeToExpandTo > () that is expand the type recursively until it find a legal type. > > > > >> It's not done simply because there isn't a need f...

...SDOperand, llvm::SelectionDAG&)+0x26c5)[0x83fe515] /home/snir/jingyu/resources/llvm/build2/Debug/bin/llc((anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDOperand)+0xa318)[0x851262c] /home/snir/jingyu/resources/llvm/build2/Debug/bin/llc((anonymous namespace)::SelectionDAGLegalize::PromoteOp(llvm::SDOperand)+0x3030)[0x851c3cc] /home/snir/jingyu/resources/llvm/build2/Debug/bin/llc((anonymous namespace)::SelectionDAGLegalize::HandleOp(llvm::SDOperand)+0xa9)[0x85080bf] /home/snir/jingyu/resources/llvm/build2/Debug/bin/llc((anonymous namespace)::SelectionDAGLegalize::LegalizeDAG()+0x236)[0...

...different mappings because of this? One mapping will be used for >>> allocation of virtual registers and the like and would always >> return a >>> legal type and the other will be used just as getTypeToTransformTo >>> () in >>> LegalizeOp(), ExpandOp() and PromoteOp() and can return also >> illegal >>> types? >> >> No need to change getTypeToTransformTo(). There is a >> getTypeToExpandTo >> () that is expand the type recursively until it find a legal type. >> >>> >>>> It's not done simply be...

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

.../src/llvm/test/ CodeGen/Generic/2007-04-08-MultipleFrameIndices.ll | llc .ident "LLVM-ia64" .psr lsb .radix C .psr abi64 NODE: 0x2000000001d09460: i32 = TargetConstant <1> Assertion failed: (0 && "Do not know how to promote this operator!"), function PromoteOp, file /dumpster/home/marcel/LLVM/src/llvm/lib/ CodeGen/SelectionDAG/LegalizeDAG.cpp, line 4089. FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/ 2007-04-27-LargeMemObject.ll for PR1557 Failed with exit(1) at line 1 while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/te...