search for: vsetcc

...11:14 PM, Eli Friedman wrote: > Testcase (compile with clang >= r76726): > #include <emmintrin.h> > __m128i a(__m128 a, __m128 b) { return a==a & b==b; } > > CodeGen ends up scalarizing the comparison, which is really bad, and > AFAIK different from what we did before vsetcc was removed. The ideal > code is a single cmpordps, although I don't think clang ever generated > that for this construct. Ok, we were missing this specific case because of some instcombine xforms that were only applying to scalars, not vectors. I tweaked them to cover vectors and...

...etTypeAction(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?] Maybe, for example, after the ScanOperands part of DAGTypeLegalizer::run, if we need to reanalyze, we should actually run ScanOperands again instead of starting with the result-type processing? Thanks in advance, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Arg...

if (N0.getOpcode() == ISD::SETCC && (LegalOperations || (!LegalOperations && VT.isPow2VectorType()))) But the comment right after it is: // sext(setcc) -> sext_in_reg(vsetcc) for vectors. // Only do this before legalize for now. if (VT.isVector() && !LegalOperations) { So, these optimizations are never safe in the general case if we can't guarantee that TLI.getSetCCResultType() returns a valid type. From: Rotem, Nadav [mailto:nadav.rotem at intel....

We no longer have vsetcc, so the comment is wrong. The code looks incorrect. The fact that a vector is power-of-two does not guarantee anything about its legality. For example <128 x i64> would pass the condition in the code below, and die on most targets. From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sen...

...etTypeAction(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?] > If I understand your description correctly, the type" <v4i1> setcc ..." is split into "<v2i1> setcc ..." because of the v4f32 operands, but later on we decide to widen <v2i1> back to <v4i1> because we legalize the result ? Can you declare...

...gt; 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?] > > > > > If I understand your description correctly, the type" <v4i1> setcc > ..." is split into "<v2i1> setcc ..." because of the v4f32 operands, > but later on we decide to widen <v2i1> back to <v4i1> because we > le...

...etTypeAction(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?] > > Maybe, for example, after the ScanOperands part of DAGTypeLegalizer::run, if we need to reanalyze, we should actually run ScanOperands again instead of starting with the result-type processing? > > Thanks in advance, > Hal >

Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From:

...ter DAGCombines. + case ISD::ZERO_EXTEND: + case ISD::ANY_EXTEND: + case ISD::TRUNCATE: + // These don't need handling: they can't generate libcalls. + // FIXME: But it might be nice for optimization to handle them. + break; + case ISD::SIGN_EXTEND: + case ISD::VSETCC: + // FIXME: Needs handling; could concievably generate a libcall, although + // it would be unusual + break; + case ISD::ADD: + case ISD::SUB: + case ISD::MUL: + case ISD::SDIV: + case ISD::UDIV: + case ISD::SREM: + case ISD::UREM: + case ISD::FADD: + case...

I'm running into lots of problems with this call back. Mostly the problem occurs because this callback is used before types are legalized. However, the code generator does not have a 1-1 correspondence between all LLVM types and the codegen types. This leads to problems when getSetCCResultType is passed in an invalid type, but has a valid LLVM type attached to it. An example is <3 x

...+ case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could potentially be unrolled to + // illegal types. Leaving them around can also help optimization. + break; + case ISD::VSETCC: + // FIXME: Needs handling; could be unrolled + break; + case ISD::ADD: + case ISD::SUB: + case ISD::MUL: + case ISD::SDIV: + case ISD::UDIV: + case ISD::SREM: + case ISD::UREM: + case ISD::FADD: + case ISD::FSUB: + case ISD::FMUL: + case ISD::FDIV: +...

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

...------------------===// + +#include "llvm/CodeGen/SelectionDAG.h" +#include "llvm/Target/TargetLowering.h" +using namespace llvm; + +namespace { +class VectorLegalizer { + SelectionDAG& DAG; + TargetLowering& TLI; + SDValue UnrollVectorOp(SDValue Op); + SDValue UnrollVSETCC(SDValue Op); + SDValue ExpandFNEG(SDValue Op); + SDValue PromoteVectorOp(SDValue Op); + + public: + bool Run(); + VectorLegalizer(SelectionDAG& dag) : + DAG(dag), TLI(dag.getTargetLoweringInfo()) {} +}; + +bool VectorLegalizer::Run() { + bool Changed = false; + + // The vector legal...