search for: gettypeaction

...sk_NotMixed)); There are identical sub-expressions 'FoldMskICmp_Mask_AllZeroes' and 'FoldMskICmp_Mask_NotAllZeroes' to the left and to the right of the '|' operator. Probably not a bug, just some duplicated code. ---- include/llvm/Target/TargetLowering.h:267       switch (getTypeAction(Context, VT)) {       case Legal:         return VT;       case Expand: Note that the values of different enum types (LegalizeAction and LegalizeTypeAction) are compared. This code works well because of the same order for enums, but it would be better to change this into       switch (getTypeActi...

...the process becomes confused. The operands are again split (as they should be), but it tries to widen the <v2i1> result back to <v4i1> (thus hitting the operand assertion). In some sense, the problem is that DAGTypeLegalizer::run decides what to do solely based on the result of calling getTypeAction(ResultVT), but it seems that in this case the operand types need to be accounted for in this determination. Enhancing the logic there to consider the result types in this case seems like it should be straightforward, but how general a problem is this? [Can this problem only happen with vsetcc nodes...

...tion. There are still some issues with this patch, but >> does >> >> the approach look sane? 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 complicated? Dan

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 complicated? Consider the case of an illegal operation (like division) on a <2 x i64> on x86-32. If we unroll it, the result has to go through type legalization. Therefore, if we want...

...te: > 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 complicated? > > Consider the case of an illegal operation (like division) on a <2 x > i64> on x86-32.  If we unroll it, the result has to go through type > legalizati...

...w 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 called only if getVTAction() returns ::Expand, and also we have assert(getTypeAction(VT) == Expand && "Not an expanded type!"); right in the beginning of the ExpandOp() function. - Sanjiv > Evan > >

...process becomes confused. The operands are again split (as they should be), but it tries to widen the <v2i1> result back to <v4i1> (thus hitting the operand assertion). > In some sense, the problem is that DAGTypeLegalizer::run decides what to do solely based on the result of calling getTypeAction(ResultVT), but it seems that in this case the operand types need to be accounted for in this determination. Enhancing the logic there to consider the result types in this case seems like it should be straightforward, but how general a problem is this? [Can this problem only happen with vsetcc nodes...

...o. // FIXME: C calling convention requires the return type to be promoted to // at least 32-bit. But this is not necessary for non-C calling conventions. if (MVT::isInteger(RetOp.getValueType()) && RetOp.getValueType() < MVT::i64) { MVT::ValueType TmpVT; if (TLI.getTypeAction(MVT::i32) == TargetLowering::Promote) TmpVT = TLI.getTypeToTransformTo(MVT::i32); else TmpVT = MVT::i32; This is wrong in at least two ways: 1. First it encodes C semantics in the backend, making other language front-ends difficult. The comment indicates that this is...

...39; and > 'FoldMskICmp_Mask_NotAllZeroes' to the left and to the right of the > '|' > operator. Probably not a bug, just some duplicated code. I've CC'd Owen who added this code. > > ---- > > include/llvm/Target/TargetLowering.h:267 > switch (getTypeAction(Context, VT)) { > case Legal: > return VT; > case Expand: > > Note that the values of different enum types (LegalizeAction and > LegalizeTypeAction) are compared. This code works well because of the same order > for enums, but it would be better to change...

...AG/LegalizeDAG.cpp (revision 72159) +++ lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (working copy) @@ -495,7 +495,7 @@ // types here except for target constants (the type legalizer does not touch // those) or for build vector used as a mask for a vector shuffle. assert((TypesNeedLegalizing || getTypeAction(VT) == Legal || - IsLegalizingCallArgs || Op.getOpcode() == ISD::TargetConstant) && + Op.getOpcode() == ISD::TargetConstant) && "Illegal type introduced after type legalization?"); switch (getTypeAction(VT)) { default: assert(0 &&...

...sed. The operands > are again split (as they should be), but it tries to widen the > <v2i1> result back to <v4i1> (thus hitting the operand assertion). > > In some sense, the problem is that DAGTypeLegalizer::run decides what > to do solely based on the result of calling getTypeAction(ResultVT), > but it seems that in this case the operand types need to be > accounted for in this determination. Enhancing the logic there to > consider the result types in this case seems like it should be > straightforward, but how general a problem is this? [Can this > problem only...

...this limit llvm starts acting wonky. I found all the items that are hard coded to 32 and a section that isn't, but I cannot figure out how to expand it so that there can be up to 64 data types. The section in question is TargetLowering.h and seems to be these two functions. LegalizeAction getTypeAction(MVT VT) const { if (VT.isExtended()) { if (VT.isVector()) return Expand; if (VT.isInteger()) // First promote to a power-of-two size, then expand if necessary. return VT == VT.getRoundIntegerType() ? Expand : Promote; assert(0 && &quot...

...AG/LegalizeDAG.cpp (revision 72159) +++ lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (working copy) @@ -495,7 +495,7 @@ // types here except for target constants (the type legalizer does not touch // those) or for build vector used as a mask for a vector shuffle. assert((TypesNeedLegalizing || getTypeAction(VT) == Legal || - IsLegalizingCallArgs || Op.getOpcode() == ISD::TargetConstant) && + Op.getOpcode() == ISD::TargetConstant) && "Illegal type introduced after type legalization?"); switch (getTypeAction(VT)) { default: assert(0 &&...

...; result back to <v4i1> (thus hitting the operand assertion). on your platform, are there any legal integer vectors types with two elements (eg: v2i32)? Ciao, Duncan. > > In some sense, the problem is that DAGTypeLegalizer::run decides what to do solely based on the result of calling getTypeAction(ResultVT), but it seems that in this case the operand types need to be accounted for in this determination. Enhancing the logic there to consider the result types in this case seems like it should be straightforward, but how general a problem is this? [Can this problem only happen with vsetcc nodes...

...ll -march=arm -mcpu=cortex-a9 -relocation-model=pic -o vect3x.s it compiles. When I use llc trunk or llc 3.1 it fails on an assert: llc: /work1/tools/llvm/trunk/sources/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:703: void<unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `TLI.getTypeAction(*DAG.getContext(), Node->getValueType(i)) == TargetLowering::TypeLegal && "Unexpected illegal type!"' failed. 0 libLLVM-3.2svn.so 0x00007fe073e4433f 1 libLLVM-3.2svn.so 0x00007fe073e4654a 2 libpthread.so.0 0x00007fe072d9d8f0 3 libc.so.6 0x00007fe07208ca75 gsig...

James, Thanks for your response. I'm working in LLVM 2.7 (I know, it's old) and the default behavior is already promote. This means that for example a call to DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON returns TypeWidenVector. From here legalization calls WidenVectorOperand() to process the STORE node and follows the call chain I have on my original email to FindMemType(). If my analysis is correct then your v316 STOREs are being broken into multiple o...

...ohman <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 complicated? >>> >> >> >> Consider the case of an illegal operation (like division) on a <2 x >> >> i64> o...

...isibility=hidden -DHIDE_EXPORTS -c ../../2006-05-08-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_mulsc3.o cc1: /home/mcm/projects/llvm/build-release/../llvm-cvs/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:2826: llvm::SDOperand <unnamed>::SelectionDAGLegalize::PromoteOp(llvm::SDOperand): Assertion `getTypeAction(VT) == Promote && "Caller should expand or legalize operands that are not promotable!"' failed. ../../2006-05-08-llvm-gcc-4/gcc/libgcc2.c:1714: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://devel...

...y, February 29, 2012 11:35 AM To: James Molloy; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Expand vector type James, Thanks for your response. I'm working in LLVM 2.7 (I know, it's old) and the default behavior is already promote. This means that for example a call to DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON returns TypeWidenVector. From here legalization calls WidenVectorOperand() to process the STORE node and follows the call chain I have on my original email to FindMemType(). If my analysis is correct then your v316 STOREs are being broken into multiple o...

...arm -mcpu=cortex-a9 -relocation-model=pic -o vect3x.s it compiles. > When I use llc trunk or llc 3.1 it fails on an assert: > llc: /work1/tools/llvm/trunk/sources/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:703: void<unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `TLI.getTypeAction(*DAG.getContext(), Node->getValueType(i)) == TargetLowering::TypeLegal && "Unexpected illegal type!"' failed. > 0  libLLVM-3.2svn.so 0x00007fe073e4433f > 1  libLLVM-3.2svn.so 0x00007fe073e4654a > 2  libpthread.so.0   0x00007fe072d9d8f0 > 3  libc.so.6         0x0...