search for: isoperationlegal

Hi Craig, protecting the transformation with: if (TLI.isTypeLegal(VT) && TLI.isOperationLegal(ISD::SUB, VT) && TLI.isOperationLegal(ISD::ADD, VT) && TLI.isOperationLegal(ISD::SHL, VT) && TLI.isOperationLegal(ISD::SRA, VT)) { shows the same result. Michael On 22.09.2017 07:19, Craig Topper wrote: > Is VT a legal type on Hexagon? It looks lik...

> Historically nodes marked "custom" were considered legal, so the > DAGCombiner would have been correct to generate it. Not sure how > that ever worked though. I think Dan split the isOperationLegal > method into isOperationLegal and isOperationLegalOrCustom for reasons > related to this kind of thing. I don't know whether the DAGCombiner > is now only supposed to produce legal non-custom nodes. In my understanding, "Custom" means that I'm in charge to build the nod...

...he > unreachable arises from inside TargetLowering::ReplaceNodeResults which > is not overwritten in the Hexagon backend. > > To avoid generating illegal code after all I queried TLI if all > generated operations are legal operations for the given vector type. > > if ( TLI.isOperationLegal(ISD::SUB, VT) > && TLI.isOperationLegal(ISD::ADD, VT) > && TLI.isOperationLegal(ISD::SHL, VT) > && TLI.isOperationLegal(ISD::SRA, VT)) { > > The Hexagon backend says happily: yes! Go ahead! > When it comes to HexagonDAGToDAGISel and the...

Hi Gabrielle, > > Historically nodes marked "custom" were considered legal, so the > > DAGCombiner would have been correct to generate it. Not sure how > > that ever worked though. I think Dan split the isOperationLegal > > method into isOperationLegal and isOperationLegalOrCustom for reasons > > related to this kind of thing. I don't know whether the DAGCombiner > > is now only supposed to produce legal non-custom nodes. > In my understanding, "Custom" means that I'm in cha...

...e with custom lowering where the unreachable arises from inside TargetLowering::ReplaceNodeResults which is not overwritten in the Hexagon backend. To avoid generating illegal code after all I queried TLI if all generated operations are legal operations for the given vector type. if ( TLI.isOperationLegal(ISD::SUB, VT) && TLI.isOperationLegal(ISD::ADD, VT) && TLI.isOperationLegal(ISD::SHL, VT) && TLI.isOperationLegal(ISD::SRA, VT)) { The Hexagon backend says happily: yes! Go ahead! When it comes to HexagonDAGToDAGISel and the type should be legalized no...

...to create illegal operations out of legal operations. > My questions: > 1) Is my understanding right? Historically nodes marked "custom" were considered legal, so the DAGCombiner would have been correct to generate it. Not sure how that ever worked though. I think Dan split the isOperationLegal method into isOperationLegal and isOperationLegalOrCustom for reasons related to this kind of thing. I don't know whether the DAGCombiner is now only supposed to produce legal non-custom nodes. > 2) Is there any bug report generated after the discussion below? I don't know, sorry. Ci...

...at multiply. Even the x86 diffs in lea-3.ll are regressions: -; LNX1-NEXT: leal (%rdi,%rdi,2), %eax +; LNX1-NEXT: leal (,%rdi,4), %eax +; LNX1-NEXT: subl %edi, %eax I suggest taking a smaller first step by limiting the patch to cases where the multiply is not a legal op for a target (TLI.isOperationLegal()). 3. Since the patch can cause a crash, that needs to be investigated first. I didn't look into it, but my guess for the Hexagon crash (and probably other targets) is that you're trying to create illegal ops after the DAG has been legalized. So that's another potential way to limit t...

Hello, In the combine 2 step (after legalization), in the DAGCombiner::visitBIT_CONVERT() method, the DAG combiner is replacing an FABS followed by a BIT_CONVERT, to a BIT_CONVERT followed by an AND 0x7FFFFFFFFFFFFFFF. Everything is 64 bit. On my target, FABS and BIT_CONVERT are legal in 64 bit, but AND in not legal in 64 bit (is declared custom). So the dag combiner is introducing illegal (not

I'm curious why the condition to fuse is this: // Floating-point multiply-add with intermediate rounding. bool HasFMAD = (LegalOperations && TLI.isOperationLegal(ISD::FMAD, VT)); static bool isContractable(SDNode *N) { SDNodeFlags F = N->getFlags(); return F.hasAllowContract() || F.hasAllowReassociation(); } bool CanFuse = Options.UnsafeFPMath || isContractable(N); bool AllowFusionGlobally = (Options.AllowFPOpFusion == FPOpFusion::Fast || CanFuse |...

...not to make the fmuladd -> fma translation. The relevant code is in > CodeGen/SelectionDAG/SelectionDAGBuilder.cpp: > > case Intrinsic::fmuladd: { > EVT VT = TLI.getValueType(I.getType()); > if (TM.Options.AllowFPOpFusion != FPOpFusion::Strict && > TLI.isOperationLegal(ISD::FMA, VT) && > TLI.isFMAFasterThanMulAndAdd(VT)){ > > [ use FMA ] > } else { > [ use MUL + ADD ] > } We've written a few TableGen patterns here locally to match FMA and added a predicate to say in effect TM.Options.AllowFPOpFusion !=...

...o the decision of whether or not to make the fmuladd -> fma translation. The relevant code is in CodeGen/SelectionDAG/SelectionDAGBuilder.cpp: case Intrinsic::fmuladd: { EVT VT = TLI.getValueType(I.getType()); if (TM.Options.AllowFPOpFusion != FPOpFusion::Strict && TLI.isOperationLegal(ISD::FMA, VT) && TLI.isFMAFasterThanMulAndAdd(VT)){ [ use FMA ] } else { [ use MUL + ADD ] } -Hal > > > Hope that helps, > Cameron > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev...

...rely, > > Vivek > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > Sounds to me like this combine is missing a TLI.isOperationLegal(ISD:: > LSHR) > > or similar check > > > I think for me, problem will still be there because shift operation is > legal on my target but it is able to shift only 1 bit at a time and that's > why I need to convert to loop. > -Vivek > > > > > -Matt > &...

...Ryan Taylor <ryta1203 at gmail.com > <mailto:ryta1203 at gmail.com>> wrote: > > I'm curious why the condition to fuse is this: > > // Floating-point multiply-add with intermediate rounding. >   bool HasFMAD = (LegalOperations && > TLI.isOperationLegal(ISD::FMAD, VT)); > > static bool isContractable(SDNode *N) { >   SDNodeFlags F = N->getFlags(); >   return F.hasAllowContract() || F.hasAllowReassociation(); > } > > bool CanFuse = Options.UnsafeFPMath || isContractable(N); > bool AllowFusionGl...

Hello LLVM Developers, I am working on an architecture which have one bit shift operation if barrel shiftier hardware is not present in such cases some DAGCombine optimizations reduces performance of certain benchmarks upto 5% for example consider follwing optimization: fold (select_cc seteq (and x, y), 0, 0, A) -> (and (shr (shl x)) A) Here it introduce 2 shift operations and when barrel

On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker <andrew.booker at arm.com>wrote: > The fmuladd intrinsic is described as saying that a multiply and > addition sequence can be fused into an fma instruction "if the code > generator determines that the fused expression would be legal and > efficient". (http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic) > >

...3 at gmail.com>>> wrote: > > > >     I'm curious why the condition to fuse is this: > > > >     // Floating-point multiply-add with intermediate rounding. > >        bool HasFMAD = (LegalOperations && > >     TLI.isOperationLegal(ISD::FMAD, VT)); > > > >     static bool isContractable(SDNode *N) { > >        SDNodeFlags F = N->getFlags(); > >        return F.hasAllowContract() || F.hasAllowReassociation(); > >     } > > > >     bool CanFuse = Op...

Duncan: DAGCombine is inserting an IllegalOperation after target-specific instruction legalization has occurred. I'm inserting the fabs and the bitconvert during instruction legalization; DAGCombine is converting the fabs/bitconvert to an 'and' on its second (third?) pass. -scooter On Jan 20, 2009, at 12:24 AM, Duncan Sands wrote: > On Tuesday 20 January 2009 07:52:37

...gt; >      >     I'm curious why the condition to fuse is this: > >      > > >      >     // Floating-point multiply-add with intermediate rounding. > >      >        bool HasFMAD = (LegalOperations && > >      >     TLI.isOperationLegal(ISD::FMAD, VT)); > >      > > >      >     static bool isContractable(SDNode *N) { > >      >        SDNodeFlags F = N->getFlags(); > >      >        return F.hasAllowContract() || > F.hasAllowReassociation(); > >      &gt...

...> >>> > I'm curious why the condition to fuse is this: >>> > >>> > // Floating-point multiply-add with intermediate rounding. >>> > bool HasFMAD = (LegalOperations && >>> > TLI.isOperationLegal(ISD::FMAD, VT)); >>> > >>> > static bool isContractable(SDNode *N) { >>> > SDNodeFlags F = N->getFlags(); >>> > return F.hasAllowContract() || F.hasAllowReassociation(); >>> > } >>&gt...

Pointer size on our target is 16-bits, and we have two 16-bit registers that can be used only to hold pointers (indirect addresses). All operations on the target are 8-bit operations, so it takes two 8-bit loads to load these pointer registers. We want LLVM to automatically expand all types to 8-bit values. The problem is that LLVM does not expand GlobalAddresses, which are 16-bit