search for: legaloperations

I'm curious about this code in ReduceLoadWidth (and in DAGCombiner in general): if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT)) return SDValue <http://llvm.org/docs/doxygen/html/classllvm_1_1SDValue.html>(); LegalOperations is false for the first pre-legalize pass and true for the post-legalize pass. The first pass is target-independent yes? So that makes sense. The...

1) It's crashing because LD1 is produced due to LegalOperations=false in pre-legalize pass. Then Legalization does not know how to handle it so it asserts on a default case. I don't know if it's a reasonable expectation or not but we do not have support for it. I have not tried overriding shouldReduceLoadWidth. 2) I see, that makes sense to some degree...

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 t...

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 tried breaks at different points so I don't t...

...n in the code below, and die on most targets. From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Friday, July 27, 2012 22:33 To: Rotem, Nadav; Developers Mailing List Subject: RE: TLI.getSetCCResultType() and/or MVT broken by design? 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 t...

...ncatingStore() && ST->isUnindexed()) { unsigned Align = ST->getAlignment(); MVT SVT = Value.getOperand(0).getValueType(); unsigned OrigAlign = TLI.getTargetData()-> getABITypeAlignment(SVT.getTypeForMVT()); if (Align <= OrigAlign && ((!LegalOperations && !ST->isVolatile()) || TLI.isOperationLegalOrCustom(ISD::STORE, SVT))) return DAG.getStore(Chain, N->getDebugLoc(), Value.getOperand(0), Ptr, ST->getSrcValue(), ST->getSrcValueOffset(), ST->isVolatile(), Or...

...unsigned OrigAlign = ST->getAlignment(); MVT SVT = Value.getOperand(0).getValueType(); - unsigned OrigAlign = TLI.getTargetData()-> + unsigned Align = TLI.getTargetData()-> getABITypeAlignment(SVT.getTypeForMVT()); if (Align <= OrigAlign && ((!LegalOperations && !ST->isVolatile()) || Does that look right to you? Dan On Wed, February 18, 2009 4:49 pm, David Greene wrote: > I got bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk: > > SDValue DAGCombiner::visitSTORE(SDNode *N) { > > [...] > > // If thi...

...s the best way to solve this problem? I take a look at the > DAG Optimizer and for this OR operation it calls > DAGCombiner::SimplifyBinOpWithSameOpcodeHands that folds (OP (aext > x), (aext y)) -> (aext (OP x, y)). No check if the new operation is > legal is performed. When LegalOperations is set, the DAG combiner must not create illegal operations. It is a bug if it does. I recently fixed this in the first if statement in SimplifyBinOpWithSameOpcodeHands(). Perhaps you could add a check to the second if statement and submit a patch? /jakob

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...

Hi all, i'm writing an back-end for a new research processor architecture and have problems with the DAG Combiner. The processor architecture supports i1 and i32 registers. 1-bit registers are mainly used as comparison result but basic operations like OR are not possible between i1 registers. So I wrote custom lowering for i1 OR operations and replaced it by (trunc (or (aext x), (aext

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:

...d to create nodes with illegal operations, but all types > must be legal. After operation legalization it is only allowed to > create fully legal nodes. > > Inside DAGCombine this is specified by two flags: > LegalTypes being true means that all nodes must have legal types. > LegalOperations being true means that all nodes must have legal > operations (as well as types: LegalTypes will also be true). > > So if LegalTypes is true and nonetheless a constant with an > illegal type is being created then that is a DAG combiner bug. > > Ciao, > > Duncan. > ________...

...+1251,10 @@ //===----------------------------------------------------------------------===// void DAGCombiner::Run(CombineLevel AtLevel) { + + if (OptLevel == CodeGenOpt::None) + return; + // set the instance variables, so that the various visit routines may use it. Level = AtLevel; LegalOperations = Level >= AfterLegalizeVectorOps; It would most likely break some CodeGen tests since it would have an impact on the code produced at /O0. In fact, I tried to run the CodeGen lit tests with this patch and got 25 new test failures on different targets. These tests would probably need to be upda...

...ion legalization it is allowed to create nodes with illegal operations, but all types must be legal. After operation legalization it is only allowed to create fully legal nodes. Inside DAGCombine this is specified by two flags: LegalTypes being true means that all nodes must have legal types. LegalOperations being true means that all nodes must have legal operations (as well as types: LegalTypes will also be true). So if LegalTypes is true and nonetheless a constant with an illegal type is being created then that is a DAG combiner bug. Ciao, Duncan.

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

...hing I'm missing? I think it's a bug. When running after type legalization, the DAG combiner should not introduce any illegal types. When running after operation legalization, the DAG combiner should not introduce any illegal operations. Consider this code from ReduceLoadWidth: if (LegalOperations && !TLI.isLoadExtLegal(ISD::SEXTLOAD, ExtVT)) return SDValue(); Here you see that it checks whether it is only allowed to produce legal operations, and bails out if it would create an illegal extending load. However the later logic in ReduceLoadWidth doesn't do any such checking...

...> On Mon, Aug 20, 2018 at 12:56 PM 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 || isCon...

...think it's a bug. When running after type legalization, the DAG combiner > should not introduce any illegal types. When running after operation > legalization, the DAG combiner should not introduce any illegal operations. > Consider this code from ReduceLoadWidth: > > if (LegalOperations&& !TLI.isLoadExtLegal(ISD::SEXTLOAD, ExtVT)) > return SDValue(); > > Here you see that it checks whether it is only allowed to produce legal > operations, and bails out if it would create an illegal extending load. > However the later logic in ReduceLoadWidth doesn...

DAGCombiner::ReduceLoadWidth() does the following: /// ReduceLoadWidth - If the result of a wider load is shifted to right of N /// bits and then truncated to a narrower type and where N is a multiple /// of number of bits of the narrower type, transform it to a narrower load /// from address + N / num of bits of new type. If the result is to be /// extended, also fold the extension to form a

...t;getAlignment(); > MVT SVT = Value.getOperand(0).getValueType(); > - unsigned OrigAlign = TLI.getTargetData()-> > + unsigned Align = TLI.getTargetData()-> > getABITypeAlignment(SVT.getTypeForMVT()); > if (Align <= OrigAlign && > ((!LegalOperations && !ST->isVolatile()) || > > Does that look right to you? Yes, and it fixes the problem. What's your opinion about how TargetData and X86Subtarget define ABI alignment for SSE registers? I think that's suspect too. It's too bad we can't specify separate ABI al...