search for: legalizeop

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

...- } public: explicit SelectionDAGLegalize(SelectionDAG &DAG, bool TypesNeedLegalizing, @@ -157,21 +113,11 @@ void LegalizeDAG(); private: - /// HandleOp - Legalize, Promote, or Expand the specified operand as - /// appropriate for its type. - void HandleOp(SDValue Op); - /// LegalizeOp - We know that the specified value has a legal type. /// Recursively ensure that the operands have legal types, then return the /// result. SDValue LegalizeOp(SDValue O); - /// UnrollVectorOp - We know that the given vector has a legal type, however - /// the operation it performs is n...

...am running into a legalize dag issue after custom lowering a load. If someone can give me pointers that would be great. I am using llvm 2.6 When custom lowering a load, the following code gets executed. Tmp1 = TLI.LowerOperation(Tmp3, DAG); if (Tmp1.getNode()) { Tmp3 = LegalizeOp(Tmp1); Tmp4 = LegalizeOp(Tmp1.getValue(1)); <----------------- what is the value expected } What is the value supposed to legalized by the second call to legalizeOp. ? My problem is that the second call asserts inside legalize ops at ResultVals[Op.getResNo()]; b'cos Resu...

On Sep 28, 2007, at 1:10 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > Attached please find the gdb backtrace dump and the postscript file of > the DAG right before assertion. > The red Node is the current Node in LegalizeOp() Okay, this is the problem. LegalizeOp should only be called on a node if the VT is valid for the target. In this case, ExpandOp should have been called to split the register up. I'd suggest going up the stack to figure out who called LegalizeOp instead of ExpandOp. > Here is my...

I'm hitting an issue where legalizeOp is overflowing the stack. Are there any recommended ways of getting around this? The bitcode that causes this issue is attached. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-...

This isn't running in a child process, but this is a win32 machine. The problem I'm having is LegalizeOp is recursively calling itself 6 times, followed by 3 calls to ExpandEXTRACT_VECTOR_ELT, with each LegalizeOp pushing 20KBof data onto the stack and Expand pushing 800B of data on the stack. So that is 9 function calls pushing ~140KB of data onto the stack. This set of 9 function calls repeats itsel...

Attached please find the gdb backtrace dump and the postscript file of the DAG right before assertion. The red Node is the current Node in LegalizeOp() The only thing that I am customizing before we get here is the FORMAL_ARGUMENTS. At this time I don't really care about the arguments, just want to get some global values working. When I trace the program, it is well passed the legalizing of formal arguments when it crashes so I'm not sur...

Are you running with restricted stack size, e.g. in a pthread process? Evan On Mar 10, 2009, at 5:16 PM, Villmow, Micah wrote: > I’m hitting an issue where legalizeOp is overflowing the stack. Are > there any recommended ways of getting around this? > > The bitcode that causes this issue is attached. > > Thanks, > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > S1-609 One AM...

LegalizeDAG.cpp SDOperand SelectionDAGLegalize::LegalizeOp(SDOperand Op) { case ISD::RET: Tmp1 = LegalizeOp(Node->getOperand(0)); // Legalize the chain. switch (Node->getNumOperands()) { case 2: // ret val [skipped] case 1: // ret void [skipped] default: { // ret <values> [skipped] Does it...

...ured and rebuilt the project. However, gdb does not consistently recognize SelectionDAG::viewgraph(), some times it finds it and some times it says that llvm::SelectionDAG does not have viewGraph(). It worked for couple of instances when I was in my modules but when for example I am in LegalizeDAG::LegalizeOp() it is not recognized. I tried "viewGragh()" as well as "this->viewGrah()" Could someone shed some light on this for me please? Thanks, Alireza Moshtaghi Senior Software Engineer Development Systems, Microchip Technology -------------- next part -------------- A...

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

...stem memory. But I can't get a handle on why it is doing this, and it is not obvious to me that the changes between v5.0 and v6.0 RC3 invalidate our implementation in a way that might cause this. The only time I see our code entered is when lowering is called for vector element insert by 'LegalizeOp'. Does anybody have an advice on how I should approach debugging this? Thanks, MartinO

...erations to 8-bit! On Sep 28, 2007, at 1:10 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > Attached please find the gdb backtrace dump and the postscript file of > the DAG right before assertion. > The red Node is the current Node in LegalizeOp() Okay, this is the problem. LegalizeOp should only be called on a node if the VT is valid for the target. In this case, ExpandOp should have been called to split the register up. I'd suggest going up the stack to figure out who called LegalizeOp instead of ExpandOp. > Here is my...

...t; > be legal in legal register types. > > That sounds like a bug, not a feature. > -Chris The -enable-legalize-types infrastructure is entirely based upon getVTAction (), so it will be completely ignored once we have i16 regclass, ditto with ExpandOp of LegalizeDAG. And LegalizeDAG::LegalizeOp() allows very few things to be auto expanded. -Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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()); This seems incorrect as SINT_TO_FP should be querying the convert a...

...s action is not supported yet!", file=0x7ffff75b4128 "/home/dmikushin/sandbox/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp", line=1198) at /home/dmikushin/sandbox/src/llvm/lib/Support/ErrorHandling.cpp:98 #3 0x00007ffff6e9a612 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd300, Node=0x722820) at /home/dmikushin/sandbox/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1198 #4 0x00007ffff6e911ca in (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG (this=0x7fffffffd300) at /home/dmikushin/sandbox/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDA...

...ible for tail call optimizations at this point. > Then checks for eligibility and fix the call nodes after all the > instructions are lowered. I am not sure that i understand where this point would be. As I view it the only place would be in LegalizeDAG.cpp in SDOperand SelectionDAGLegalize::LegalizeOp(SDOperand Op) { ... case ISD::CALL: // The only option for this is to custom lower it. Tmp3 = TLI.LowerOperation(Result.getValue(0), DAG); } would change to (pseudo code) SDOperand SelectionDAGLegalize::LegalizeOp(SDOperand Op) { SDOperand Result = Op; ... case ISD::CALL: // The on...

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 Can someone explain to me what this means in term of backend code generation, how it might be occurring, and possible ways to fix this? I don't see how the value type of an

...ut I can't get a handle on why it is doing this, and it is not obvious to > me that the changes between v5.0 and v6.0 RC3 invalidate our implementation > in a way that might cause this. The only time I see our code entered is > when lowering is called for vector element insert by 'LegalizeOp'. Does > anybody have an advice on how I should approach debugging this? > > Thanks, > > MartinO > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/li...