search for: legalizesetccoperand

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 it tries to create a > legal LHS and RHS but it this case it fails to return a legal LHS. > The following patch allows me to > compile my original file. > > --- LegalizeDAG.cpp~ 2008-07-03 23:03:35....

...sborne 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 it tries to create a >> legal LHS and RHS but it this case it fails to return a legal LHS. >> The following patch allows me to >> compile my original file. >> >> --- LegalizeD...

...ct but it seems to work so >> far for >> my target. See the attached diff. > > 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 it tries to create a legal LHS and RHS but it this case it fails to return a legal LHS. The following patch allows me to compile my original file. -------------- next part -------------- A non-text attachment was scrubbed......

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: >>>> >>>> >>>>> I'm trying to write a backend for a target with no hardware

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: >>> >>> >>>> I'm trying to write a backend for a target with no hardware floating >>>> point support. I've added a single i32 register class. I'm

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

...f order or result bytes, but on a type /// whose vector element type is narrower than the original shuffle type. @@ -278,19 +139,17 @@ bool LegalizeAllNodesNotLeadingTo(SDNode *N, SDNode *Dest, SmallPtrSet<SDNode*, 32> &NodesLeadingTo); - void LegalizeSetCCOperands(SDValue &LHS, SDValue &RHS, SDValue &CC, - DebugLoc dl); void LegalizeSetCCCondCode(MVT VT, SDValue &LHS, SDValue &RHS, SDValue &CC, DebugLoc dl); void LegalizeSetCC(MVT VT, SDValue &LHS, SDValue &RHS,...