search for: srcvt

...get this failed assertion: llc: LegalizeDAG.cpp:1309: llvm::SDValue<unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `0 && "This action is not supported yet!"' failed. I initially expected the if statement on line 1191 (in my copy), `if (SrcWidth != SrcVT.getStoreSizeInBits()` to catch my i16 promotion case - but it doesn't because SrcVT.getSizeInBits() and SrcVT.getStoreSizeInBits() equals 16 with SrcVT == MVT::i16. I'd appreciate any pointers in the right direction. Thank you, Alex

...y an > extension". So, the "EXT" part is probably irrelevant here, if that's > what's bugging you ;) Nevermind, grepping around shows this is specifically about ISD::EXTLOAD, in LegalizeLoadOps (LegalizeDAG.cpp). There's some code above, with an "isTypeLegal(SrcVT)" check, that tries to turn an EXTLOAD into LOAD+[SZ]EXT. I'm guessing that on your target, both the EXTLOAD from i8 and the i8 type are illegal? In that case, again, I don't know how one could legalize this. -Ahmed

...part is probably irrelevant here, if that's >> > what's bugging you ;) >> >> Nevermind, grepping around shows this is specifically about >> ISD::EXTLOAD, in LegalizeLoadOps (LegalizeDAG.cpp). >> >> There's some code above, with an "isTypeLegal(SrcVT)" check, that >> tries to turn an EXTLOAD into LOAD+[SZ]EXT. I'm guessing that on your >> target, both the EXTLOAD from i8 and the i8 type are illegal? >> >> In that case, again, I don't know how one could legalize this. >> >> -Ahmed > >

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

...ave SSE, these could be more efficient, by using movd/movq. @@ -4608,8 +4612,14 @@ SDValue Chain = DAG.getStore(DAG.getEntryNode(), dl, Op.getOperand(0), StackSlot, PseudoSourceValue::getFixedStack(SSFI), 0); + return BuildFILD(Op, SrcVT, Chain, StackSlot, DAG); +} +SDValue X86TargetLowering::BuildFILD(SDValue Op, MVT SrcVT, SDValue Chain, + SDValue StackSlot, + SelectionDAG &DAG) { // Build the FILD + DebugLoc dl = Op.getDebugLoc(); SDVTList Tys;...

Ahmed, Yes, this is the case, I'm sure many other 'spots' in DAGCombiner use this same check or use a similar check with LegalOperations. It just seems like bad form to have core code that generates an illegal node that legalization cannot seem to handle, unless I'm missing something, which is entirely possible. Potentially we are using the wrong LegalAction, though each I've

...+ /// in some non-standard address space, and populates the address space and + /// offset as appropriate. + virtual bool getUnsafeStackPtrLocation(unsigned &AddressSpace, + unsigned &Offset) const; + SDValue BuildFILD(SDValue Op, EVT SrcVT, SDValue Chain, SDValue StackSlot, SelectionDAG &DAG) const; diff --git a/lib/Transforms/IPO/Inliner.cpp b/lib/Transforms/IPO/Inliner.cpp index 4ce6dfe..e0695d2 100644 --- a/lib/Transforms/IPO/Inliner.cpp +++ b/lib/Transforms/IPO/Inliner.cpp @@ -93,7 +93,8 @@ static voi...