search for: isloadextleg

...ing 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 &gt...

...t'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 as far as I can see, which i...

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

...4), zext from i8> because the instruction is simply not supported by the backend (that's the initial reason for implementing the custom lowering !) How come the DAG combiner converts my lowering back to an i8 loading ? Looking at the DAGCombiner.cpp code, this transformation is done because isLoadExtLegal returns true in the case of custom lowering of load which does not seem logical to me (do you have an explanation for this ?). Well, I assume I didn't do sth the right way... Can you point a mistake in my reasoning ? Thank you ! Damien -------------- next part -------------- An HTML at...

...;m wondering if there is: >> >> a) A way to turn off this optimization in DAGCombine if your target >> doesn't support LD2 natively > > This. > > I think you're talking about DAGCombiner::ReduceLoadWidth... and the > "if (LegalOperations&& !TLI.isLoadExtLegal(ExtType, ExtVT))" is > supposed to ensure that the transformation in question is safe. That > said, IIRC I fixed a bug there recently; are you using trunk? Perfect! I'm using 2.8 for now (am hoping to roll forward to trunk and stay there in a month or two), and 2.8 only had tha...

...objections to replace EVT with MVT in these cases? For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAction, getLoadExtAction, isLoadExtLegal, getTruncStoreAction, isTruncStoreLegal, getIndexedLoadAction, getIndexedStoreAction, getCondCodeAction, getTypeToPromoteTo, addRegisterClass Regards, Patrik Hägglund -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

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 issue we are having is this:...

...ause the instruction is simply not supported by the backend (that's the > initial reason for implementing the custom lowering !) > > How come the DAG combiner converts my lowering back to an i8 loading ? > Looking at the DAGCombiner.cpp code, this transformation is done because > isLoadExtLegal returns true in the case of custom lowering of load which > does not seem logical to me (do you have an explanation for this ?). > > Well, I assume I didn't do sth the right way... Can you point a mistake in > my reasoning ? Looks like a bug to me too. :) r135462 should fix it....

...t;> >>> a) A way to turn off this optimization in DAGCombine if your target >>> doesn't support LD2 natively >> >> This. >> >> I think you're talking about DAGCombiner::ReduceLoadWidth... and the >> "if (LegalOperations&&  !TLI.isLoadExtLegal(ExtType, ExtVT))" is >> supposed to ensure that the transformation in question is safe.  That >> said, IIRC I fixed a bug there recently; are you using trunk? > > Perfect!  I'm using 2.8 for now (am hoping to roll forward to trunk and stay > there in a month or two),...

...t* want a > ZEXTLOAD i16.  I'm wondering if there is: > > a) A way to turn off this optimization in DAGCombine if your target > doesn't support LD2 natively This. I think you're talking about DAGCombiner::ReduceLoadWidth... and the "if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT))" is supposed to ensure that the transformation in question is safe. That said, IIRC I fixed a bug there recently; are you using trunk? -Eli

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()

...Bougacha <ahmed.bougacha at gmail.com> wrote: > On Tue, Mar 3, 2015 at 10:35 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm curious about this code in ReduceLoadWidth (and in DAGCombiner in > > general): > > > > if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT)) > > return SDValue(); > > > > 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 issue we are having is...

...EVT with MVT in these cases? > > For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: > > getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAction, getLoadExtAction, isLoadExtLegal, getTruncStoreAction, isTruncStoreLegal, getIndexedLoadAction, getIndexedStoreAction, getCondCodeAction, getTypeToPromoteTo, addRegisterClass > Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the cod...

...be converted into a "call" to a software routine, specifically RTLIB I have the code set for "custom" ISD:FP_EXTEND to make the subroutine call, but the FP_EXTEND never gets invoked because the DAG conversion changes this to a load extension. I have seen a few things about TLI:isLoadExtLegal, that I need to track down. But I wanted to check on the best way to make sure a set of floating-point concepts are left as calls for my target. Is there a way to explain to the DAG conversion system prior to the target lowering, that it should above some target-specific. For example, since I...

Hi, A bit more information. I believe my problem lies with the fact that the load is left as 'anyext from i8'. On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load! If BB#1 were to force the load to a "zext from i8" would this information be available in BB#2? BB#1: 0x268c1b0: i32 = Register %vreg1 [ID=3] 0x2689d80:

Hi, Within a basic block I can remove unnecessary register copies + zero sign extensions of unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes. ...But not between basic blocks. The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2. The second block then does a unnecessary zext to vreg2. What I want is the 2nd block to use the original

...s to see what they do but can't see what I am missing. > > Help please! > Thank you > > Robert The instruction selector only operates within a block. An IR CodeGenPrepare pass runs first and attempts to hoist the zext into the load’s block if it sees a legal zextload pattern (isLoadExtLegal). I’m not sure why the zero_extend isn’t hoisted in your case. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/91fc2903/attachment.html>

...t; > >> On Tue, Mar 3, 2015 at 10:35 AM, Ryan Taylor <ryta1203 at gmail.com> > wrote: > >> > I'm curious about this code in ReduceLoadWidth (and in DAGCombiner in > >> > general): > >> > > >> > if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT)) > >> > return SDValue(); > >> > > >> > 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 > >> > m...

...objections to replace EVT with MVT in these cases? For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAction, getLoadExtAction, isLoadExtLegal, getTruncStoreAction, isTruncStoreLegal, getIndexedLoadAction, getIndexedStoreAction, getCondCodeAction, getTypeToPromoteTo, addRegisterClass Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code gene...