search for: expandop

...; > regclass, > > I suspected that. But I wonder if that's going to be the approach or > is this something we want to change. > Even after VT is legal, is it possible to check if the target still wants the result of this operation to be expanded? > > > > ditto with ExpandOp of LegalizeDAG. > > And LegalizeDAG::LegalizeOp() allows very few things to be auto > > expanded. > > Really?! ExpandOp handles quite a lot of cases. And you can always add > the ones you need. Most of them share the same mechanism (and common > code). > ExpandOp is cal...

...ris > > The -enable-legalize-types infrastructure is entirely based upon > getVTAction (), so it will be completely ignored once we have i16 > regclass, I suspected that. But I wonder if that's going to be the approach or is this something we want to change. > > ditto with ExpandOp of LegalizeDAG. > And LegalizeDAG::LegalizeOp() allows very few things to be auto > expanded. Really?! ExpandOp handles quite a lot of cases. And you can always add the ones you need. Most of them share the same mechanism (and common code). Evan > > > -Sanjiv >> ______...

...east some basic operations, like add, to > > 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/llvmd...

...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 code in the formalizing arguments (copied ISD::MERGE_VALUES > from PowerPC implementation, not sure if it is really needed) MergeVa...

ExpandOp is not called at all. In SelectionDAGLegalize::HandleOp() only the ValueType is considered in the switch statement to decide if it is legal or promote or expand. As I trace back (correct me if I'm wrong) these values are set in TargetLowering::computeRegisterProperties() and it is based on the...

...s to create a register of such a promoted type > and fails in the above mentioned case. All of the issues can be solved by adding the logic to recursively expand operands. They shouldn't be too complicated. > > > Evan wrote: >> That means, you will have to either 1) modify ExpandOp() to >> handle cases which need to be recursively expanded or 2) modify it to > >> return a vector of SDOperand's. Solution one is what I would pursue. > > Agreed. I also feel that some sort of recursive expansion is required. > > I also have a feeling that getTypeToT...

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

...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 - /// garbage. - SDValue PromoteOp(SDValue O); - - /// ExpandOp - Expand the specified SDValue into its two component pieces - /// Lo&Hi. Note that the Op MUST be an expanded type. As a result of this, - /// the LegalizedNodes map is filled in for any results that are not expanded, - /// the ExpandedNodes map is filled in for any results that are expan...

...ll already 'expand' them for you. > This will probably require a slightly more extensive patch to legalizer. The current mechanism assumes either 1->1 or 1->2 expansion. It also assumes the result of expansion are of legal types. That means, you will have to either 1) modify ExpandOp() to handle cases which need to be recursively expanded or 2) modify it to return a vector of SDOperand's. Solution one is what I would pursue. It's not done simply because there isn't a need for it right now. :-) Evan > > -Chris > > -- > http://nondot.org/sabre/...

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

More information on this... still not working When I build the project for Debug and run the program, the following message is printed before assert. NODE: 0x937bac8: i64 = GlobalAddress <i32* @var> 0 I guess it is expecting that GlobalAddress be legalized before reaching ExpandOp(). I haven't implemented anything for ISD::GlobalAddress, and that may explain it, however, I couldn't find much about it in the PowerPC implementation either. The only thing is in the ctor of PPCTargetLowering there is setOperationAction(ISD::GlobalAddress, MVT::i32, Custom); and setOpe...

...have most of the classes and Tblgen files written for a very basic hypothetical microcontroller with very few instructions. The project builds and the llc recognizes the new processor, however, when it reaches the point where it wants to lower llvm IR to PICxx DAG, it asserts in LegalizeDAG.cpp in ExpandOp() function after it hits the default case of switch(Node->getOpcode()) Can someone please help me understand how am I ending up in the default case? Thanks, A. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

...t legalizer implementation. Currently, it is assumed that the result of getTypeToTransformTo() is a legal type. For example, CreateRegForValue tries to create a register of such a promoted type and fails in the above mentioned case. Evan wrote: > That means, you will have to either 1) modify ExpandOp() to > handle cases which need to be recursively expanded or 2) modify it to > return a vector of SDOperand's. Solution one is what I would pursue. Agreed. I also feel that some sort of recursive expansion is required. I also have a feeling that getTypeToTransformTo(MVT::ValueType...

...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 already present ExpandOp infrastructure. -Sanjiv

...e > > and fails in the above mentioned case. > > All of the issues can be solved by adding the logic to recursively > expand operands. They shouldn't be too complicated. > > > > > > > Evan wrote: > >> That means, you will have to either 1) modify ExpandOp() to > >> handle cases which need to be recursively expanded or 2) modify it > to > > > >> return a vector of SDOperand's. Solution one is what I would > pursue. > > > > Agreed. I also feel that some sort of recursive expansion is > required. > &g...

...0 This implies that your target uses 64-bit pointers, but that it doesn't have a 64-bit register file, is this right? If you aren't using 64-bit pointers, you should investigate where this node came from. > I guess it is expecting that GlobalAddress be legalized before reaching > ExpandOp(). I haven't implemented anything for ISD::GlobalAddress, and > that may explain it, however, I couldn't find much about it in the > PowerPC implementation either. The only thing is in the ctor of > PPCTargetLowering there is setOperationAction(ISD::GlobalAddress, > MVT::i32, Cu...

...gen files written > for a very basic hypothetical microcontroller with very few > instructions. > The project builds and the llc recognizes the new processor, > however, when it reaches the point where it wants to lower llvm IR > to PICxx DAG, it asserts in LegalizeDAG.cpp in ExpandOp() function > after it hits the default case of switch(Node->getOpcode()) > Can someone please help me understand how am I ending up in the > default case? > > Thanks, > A. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at...

...0 This implies that your target uses 64-bit pointers, but that it doesn't have a 64-bit register file, is this right? If you aren't using 64-bit pointers, you should investigate where this node came from. > I guess it is expecting that GlobalAddress be legalized before reaching > ExpandOp(). I haven't implemented anything for ISD::GlobalAddress, and > that may explain it, however, I couldn't find much about it in the > PowerPC implementation either. The only thing is in the ctor of > PPCTargetLowering there is setOperationAction(ISD::GlobalAddress, > MVT::i32, Cu...

...the above mentioned case. >> >> All of the issues can be solved by adding the logic to recursively >> expand operands. They shouldn't be too complicated. >> >>> >>> >>> Evan wrote: >>>> That means, you will have to either 1) modify ExpandOp() to >>>> handle cases which need to be recursively expanded or 2) modify it >> to >>> >>>> return a vector of SDOperand's. Solution one is what I would >> pursue. >>> >>> Agreed. I also feel that some sort of recursive expansion is...