similar to: [LLVMdev] Bad legalization?

On Sep 15, 2008, at 3:05 PM, Villmow, Micah wrote: > I am getting an assert on a bad legalization. > Assertion failed: Result.getValueType() == Op.getValueType() && "Bad > legalization!", file ..\..\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp, > line 3976 > When you run into issues like this, it helps if you provide a bit more information. Please dump out

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

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

Hi, The attached patch implements sub.ovf/mul.ovf intrinsics similarly to the recently added add.ovf intrinsics. These are useful for implementing some vm instructions like sub.ovf/mul.ovf in .NET IL efficiently. sub.ovf is supported in target independent lowering and on x86, while mul.ovf is only supported in the x86 backend. Please review

I'm trying to write a store pattern that accepts both i32 and f32, however, when tablegen generates the code, it only generates the code for i32 only. def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; def MEM : Operand<i32> { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPR, GPR); } def global_st :

My target supports only 8-bit arithmetic, hence I specified it to exapand ADD for i32 and i16. llc fails at the following place in LegalizeDAG.cpp: assert(MVT::isVector(Node->getValueType(0)) && "Cannot expand this binary operator!"); // Expand the operation into a bunch of nasty scalar code. Result = LegalizeOp(UnrollVectorOp(Op)); I don't

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:

How do I determine what type of register(i.e. i32, f32, etc..) I am accessing from a MachineOperand? I.e. how do I get to the MVT struct, or equivalent information, from a MachineOperand object? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596

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 simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

Index: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- llvm.orig/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:23.000000000 +0200 +++ llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:52.000000000 +0200 @@ -696,7 +696,7 @@ } } break; - case ISD::EH_RETURN: + case ISD::EH_RETURN: {

Evan Cheng wrote: > On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > > >> Evan Cheng wrote: >> >>> On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: >>> >>> >>> >>>> Evan Cheng wrote: >>>> >>>> >>>>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote:

On Jul 3, 2008, at 3:07 PM, Richard Osborne wrote: >> >> This seems to break the convention. It should be the responsibility >> of the caller to further legalize the results. >> >> Evan > That makes sense. In that case I believe > SelectionDAGLegalize::LegalizeSetCCOperands > should be legalizing the result. The description of this function > says

Evan Cheng wrote: > On Jul 3, 2008, at 3:07 PM, Richard Osborne wrote: > >>> This seems to break the convention. It should be the responsibility >>> of the caller to further legalize the results. >>> >>> Evan >>> >> That makes sense. In that case I believe >> SelectionDAGLegalize::LegalizeSetCCOperands >> should be

On Sep 23, 2008, at 10:44 AM, Villmow, Micah wrote: > I’m trying to write a store pattern that accepts both i32 and f32, > however, when tablegen generates the code, it only generates the > code for i32 only. > > def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; > def MEM : Operand<i32> { > let PrintMethod = "printMemOperand";

You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information. Evan On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: > How do I determine what type of register(i.e. i32, f32, etc..) I am > accessing from a MachineOperand? I.e. how do I get to the MVT > struct, or equivalent information, from

Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the

Hi! I noticed in the LegalizeDAG.cpp (SelectionDAGLegalize::LegalizeOp): case ISD::INIT_TRAMPOLINE: case ISD::FRAMEADDR: case ISD::RETURNADDR: // These operations lie about being legal: when they claim to be legal, // they should actually be custom-lowered. Action = TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0)); if (Action == TargetLowering::Legal)

Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) ... case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::EXTRACT_VECTOR_ELT: Action = TLI.getOperationAction(Node->getOpcode(), Node->getOperand(0).getValueType());

Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at

Hi all, considering following .ll file ; ModuleID = 'vect3x.ll' target triple = "armv7-none-linux-gnueabi" define arm_aapcscc void @test_hi_char8(i8* %.T0351, <8 x i8>* nocapture %srcA, <4 x i8>* nocapture %dst) noinline { L.entry: %0 = tail call arm_aapcscc i32 (...)* @get_global_id(i8* %.T0351, i32 0) %1 = bitcast <8 x i8>* %srcA to <4 x i8>*