similar to: [LLVMdev] DAGCombiner::ReduceLoadWidth bug?

Hi JP, > 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,

On 7/19/10 10:36 AM, Duncan Sands wrote: > Hi JP, > > >> 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

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.

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, I'm curious if you can

Hi Eli, On 07/27/2011 04:59 PM, Eli Friedman wrote: > On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson > <johnso87 at crhc.illinois.edu> wrote: >> Hi All, >> I'm writing a backend for a target which only supports 4-byte, >> 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and >> STORE nodes in TargetISelLowering.cpp to take advantage of

On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi All, >     I'm writing a backend for a target which only supports 4-byte, > 4-byte-aligned loads and stores.  I custom-lower all {*EXT}LOAD and > STORE nodes in TargetISelLowering.cpp to take advantage of all alignment > information available to the backend, rather than treat each

Hi All, I'm writing a backend for a target which only supports 4-byte, 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and STORE nodes in TargetISelLowering.cpp to take advantage of all alignment information available to the backend, rather than treat each load and store conservatively, which takes O(10) instructions. My target's allowsUnalignedMemoryOperations()

On Wed, Jul 27, 2011 at 3:50 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi Eli, > > On 07/27/2011 04:59 PM, Eli Friedman wrote: >> >> On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson >> <johnso87 at crhc.illinois.edu>  wrote: >>> >>> Hi All, >>>     I'm writing a backend for a target which only supports 4-byte,

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

On Thu, Mar 5, 2015 at 4:19 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Thanks for the reply: > > So should LLVM continue to assume 8-bit byte addressing? It would be nice, > not only to us but potential future machines, to have a permanent fix to > this assumption? This sounds reasonable yes? > > Marking them as Custom in XXXISelLowering still produces error, the

I got bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk: SDValue DAGCombiner::visitSTORE(SDNode *N) { [...] // If this is a store of a bit convert, store the input value if the // resultant store does not need a higher alignment than the original. if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && ST->isUnindexed()) {

I agree, that doesn't look right. It looks like this is what was intended: Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp =================================================================== --- lib/CodeGen/SelectionDAG/DAGCombiner.cpp (revision 65000) +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp (working copy) @@ -4903,9 +4903,9 @@ // resultant store does not need a higher alignment than

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

On Wednesday 18 February 2009 21:43, Dan Gohman wrote: > I agree, that doesn't look right. It looks like this > is what was intended: > > Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp > =================================================================== > --- lib/CodeGen/SelectionDAG/DAGCombiner.cpp (revision 65000) > +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp

On Wed, Mar 4, 2015 at 10:49 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> Yes, it is breaking during the legalize phase, depending on which >> TargetLowering callback method we use. For example, Custom will let it >> through to instructions selection, which it breaks at the

On 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote: > So I have a test case where: > > %20 = fmul nnan arcp float %15, %19 > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > is being contracted in DAG to fmad. Is this correct since the fmul has > no reassoc or contract fast math flag? By having the reassoc and contract flags on fadd, the frontend is

On Wed, Mar 4, 2015 at 11:43 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ahmed, > > Yes, we do not have an 8 bit type and do not support 8 bit loads/extloads. > > For your first post, I imagine that anything that the DAGCombiner does it > could undo EXCEPT deciding to opt to a type that is not allowed, No, I think the SelectionDAG legalization should be able to

On 22.08.2018 13:29, Ryan Taylor wrote: > The example starts as SPIR-V with the NoContraction decoration flag on > the fmul. > > I think what you are saying seems valid in that if the user had put the > flag on the fadd instead of the fmul it would not contract and so in > this example the user needs to put the NoContraction on the fadd though > I'm not sure

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

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