search for: legalizevectorops

...ons; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) +++ lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) @@ -0,0 +1,243 @@ +//===-- LegalizeVectorOps.cpp - Implement SelectionDAG::LegalizeVectors ---===//...

...ith this patch, but does > the approach look sane? New version with a few minor changes and fixed-up comments; the previous version had some comments with inaccurate statements, which might be confusing for reviewing. -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) +++ lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) @@ -0,0 +1,239 @@ +//===-- LegalizeVectorOps.cpp - Implement SelectionDAG::LegalizeVectors ---===//...

If you mark VSELECT as 'expand' then it will be expanded to a sequence of AND/OR/XOR, which is pretty efficient (found in LegalizeVectorOps.cpp ExpandVSELECT). On Oct 11, 2012, at 11:05 AM, Jim Grosbach <grosbach at apple.com> wrote: > Seems reasonable to me. Plain 'SELECT' is already marked expand for vector types. I bet that just didn't get updates when VSELECT was introduced. > > -Jim > > On Oct...

...to a terribly complex bug: PR18773. r198863 - Fixed old typo in ScalarEvolution, that caused wrong SCEVs zext operation. Owen Anderson: r200201 - Fix for PR18102. r200202 - Additional fix for 200201: due to dependence on bitwidth test was moved to X86 directory. r200705 - Expand vector bswap in LegalizeVectorOps r205738 - Put a limit on ScheduleDAGSDNodes::ClusterNeighboringLoads to avoid blowing up compile time. Evan Cheng: r200028 - InstCombine: Don't try to use aggregate elements of ConstantExprs. r199351 - BasicAA: We need to check both access sizes when comparing a gep and an r198290 - BasicAA...

Paul Melis wrote: > Hi, > > Óscar Fuentes wrote: >> Chuck Robey <chuckr at telenix.org> writes: >> >> >>>> Just checked that the makefiles generated by cmake work with `make' on >>>> FreeBSD 7.2 x86. The build fails while building `opt' because libdl is >>>> missing. >>>> >>> They

Hello, We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from the ARM backend. Would there be any potential harm by marking VSELECT as Expand on ARM targets with NEON? Adding this seems to fix the following PR's: http://llvm.org/bugs/show_bug.cgi?id=13831 http://llvm.org/bugs/show_bug.cgi?id=13961 Thanks! Pete

Seems reasonable to me. Plain 'SELECT' is already marked expand for vector types. I bet that just didn't get updates when VSELECT was introduced. -Jim On Oct 11, 2012, at 10:25 AM, Peter Couperus <peter.couperus at st.com> wrote: > Hello, > > We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from

Hi, Óscar Fuentes wrote: > Chuck Robey <chuckr at telenix.org> writes: > > >>> Just checked that the makefiles generated by cmake work with `make' on >>> FreeBSD 7.2 x86. The build fails while building `opt' because libdl is >>> missing. >>> >> They absolutely do work, even on FreeBSD-current( I run that here), >>

...k.h.hagglund at ericsson.com> Date: Tue Dec 4 16:15:55 2012 +0100 Change TargetLowering::getTruncStoreAction to take MVTs, instead of EVTs. include/llvm/Target/TargetLowering.h | 11 +++++------ lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | 3 ++- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp | 4 ++-- 3 files changed, 9 insertions(+), 9 deletions(-) commit 6e468d9ec25353935c96c78a717e48cb6ace6206 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 16:28:34 2012 +0100 Change TargetLowering::getCondCodeAction to take an MVT, instead of EVT....

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT = Op.getValueType(); assert(Op.getNode()->getNumValue...

...er way around": BSD make on a Gentoo Linux system building LLVM from CMake-generated makefiles: 23:15|melis at juggle2:~/c/llvm-svn> svn up U include/llvm/Analysis/ScalarEvolution.h U tools/bugpoint/CrashDebugger.cpp U lib/Analysis/ScalarEvolution.cpp U lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp U lib/CodeGen/SelectionDAG/LegalizeDAG.cpp U lib/Target/ARM/ARMBuildAttrs.h U lib/Target/X86/README.txt U lib/Transforms/Scalar/IndVarSimplify.cpp Updated to revision 72399. 23:15|melis at juggle2:~/c/llvm-svn> cd ../llvm-svn-build/ 23:16|melis at juggle2:~/c/llvm-svn-build> c...

Hi Richard, > > I did… It originates from an icmp ne <2x i8>, zero initializer followed by a sext of the result 2x i1 to 2x i8. When we visit the SIGN_EXTEND, we generate the ISD::SELECT even though the selector and both operands are vectors. > It sounds like a bug in the dag combine optimization. If you send me the line number I will take a look. >> We should probably

...Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 21:26 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT = Op.getValueType(); assert(Op.getNode()->getNumValue...

...: Monday, July 30, 2012 21:26 > To: Rotem, Nadav; Developers Mailing List > Subject: RE: Vector promotion broken for <2 x [i8|i16]> > > Hrmm.... PromoteVectorOp doesn't seem to follow this at all. > http://llvm.org/svn/llvm- > project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp > SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { > // Vector "promotion" is basically just bitcasting and doing the > operation > // in a different type. For example, x86 promotes ISD::AND on v2i32 > to > // v1i64. > EVT VT = Op.getValueType(); &g...

...ht thing to do. VT.isVector() ? ISD::VSELECT : ISD::SELECT in lieu of the fixed ISD::SELECT seems to do the trick for me. Except that it sometimes hits the assert in ExpandVSELECT… Okay. Which assertion in ExpandVSELECT fail ? Maybe our assumptions there are incorrect. The assert at line 676 of LegalizeVectorOps.cpp… the Mask (operand 0) type is an i32, but Op1 is an i8. The subsequent assert comes in ExpandVSELECT, which expects (for no good reason as far as I can tell) that the "mask" (really the 'selector') and the operands will be the same width, rather than trying to make them the...

...: Monday, July 30, 2012 21:26 > To: Rotem, Nadav; Developers Mailing List > Subject: RE: Vector promotion broken for <2 x [i8|i16]> > > Hrmm.... PromoteVectorOp doesn't seem to follow this at all. > http://llvm.org/svn/llvm- > project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp > SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { > // Vector "promotion" is basically just bitcasting and doing the > operation > // in a different type. For example, x86 promotes ISD::AND on v2i32 > to > // v1i64. > EVT VT = Op.getValueType();...

On Mar 8, 2013, at 2:29 PM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>> wrote: Hi Richard, visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… ISD::SELECT should be used for

I don't know how your target architecture looks like, but I suspect that <4 x i8> should not be legalized to <1 x i32>. I think that what you are seeing is that <4 x i8> is first split into <2 x i8>, and later promoted to <2 x i32>. At the moment different targets can only affect type-legalization by declaring different legal types. A number of us discussed the

Sorry, <4 x i8> should convert to a <1 x i32>. What currently is happening is that it is returning a <2 x i32> because <1 x i32> does not exist. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Monday, July 30, 2012 10:51 AM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken

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