similar to: [LLVMdev] Custom Lowering of ARM zero-extending loads

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.

On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > Some things to consider: When the input to the zext is spilled, the reload can be folded into the zext on almost all targets, making the zext free. When the zext *isn't* folded into a load, what you're really looking for is a code placement pass which tries to put the zexts in non-redundant (and non-partially redundant) places. That

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Fabian Scheler > Sent: Wednesday, August 15, 2012 9:12 AM > To: LLVM Developers Mailing List > Subject: [LLVMdev] More Back-End Porting Troubles > > Hi LLVM-Folks, > > as mentioned in an earlier post >

Hi, The target I am working on does not support i8 loading: it supports only 32 bit aligned loads. I had to custom lower i8 load so that only i32 loads are generated. My issue is the following: In a very specific case, the lowering stage generates the following pattern where the load is a i32 load: (and (load x), 255) This pattern is somehow converted by the DAG combiner back to: (zextload x,

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, first of all: thanks for your kind, very helpful and unbelievable fast response! >> as mentioned in an earlier post >> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051677.html) I >> am currently working on a Back-End for the TriCore processor. >> Currently, I am struggling as LLVM could not select zext and load, for >> instance, so some of the testcases

On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: > > On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > >> Some things to consider: When the input to the zext is spilled, the reload can be folded into the zext on almost all targets, making the zext free. When the zext *isn't* folded into a load, what you're really looking for is a code placement pass which

On Mon, Jul 18, 2011 at 6:35 PM, Damien Vincent <damien.llvm at gmail.com> wrote: > >   Hi, > > The target I am working on does not support i8 loading: it supports only 32 > bit aligned loads. > I had to custom lower i8 load so that only i32 loads are generated. > > My issue is the following: > In a very specific case, the lowering stage generates the following

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 Aug 18, 2010, at 11:22 AM, Chris Lattner wrote: > > On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: > >> >> On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: >> >>> Some things to consider: When the input to the zext is spilled, the reload can be folded into the zext on almost all targets, making the zext free. When the zext *isn't*

> On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Amara, > >> On Nov 10, 2017, at 9:12 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine

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

Hi, I'm quite puzzled by a little bit of code in the DAGCombiner where it merges loads in MergeConsecutiveStores. Two 16bit loads have been merged to one 32bit load, and two 16bit stores have been combined to one 32bit store. And then the code goes like this: // Replace one of the loads with the new load. LoadSDNode *Ld = cast<LoadSDNode>(LoadNodes[0].MemNode);

On Sep 10, 2013, at 8:59 AM, Robert Lytton <robert at xmos.com> wrote: > 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

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

Thanks for the suggestions Vedant. Synthetic debug info is an interesting idea that sounds worthwhile. Could this be implemented as a “wrapper” pass that automatically decorates debug info before and after a specific pass run in opt (or pipeline of passes)? It might be useful to be able to easily enable this for a wide range of tests without having to manually modify each run line, perhaps as an

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 Nov 10, 2008, at 1:20 PM, Daniel M Gessel wrote: > I've been running into two issues with load/store handling: > > (1) is that tablegen doesn't seem to handle the two predicates that > get attached to my instructions. The first is the predicate in > TargetSelectionDAG.td, identifying a load node as, say, extloadi8. The > second is my identification of the load as

I've been running into two issues with load/store handling: (1) is that tablegen doesn't seem to handle the two predicates that get attached to my instructions. The first is the predicate in TargetSelectionDAG.td, identifying a load node as, say, extloadi8. The second is my identification of the load as having a particular address space (need different instructions for different

Hi Andrew, Thank you for the suggestion. I've looked at CodeGenPrepare.cpp and MoveExtToFormExtLoad() is never run. I also notice that the ARM target produces the same additional register usage (copy) and zero extending (of the copy). (See the usage of r3 &r5 and also r12 & r4 in attached file arm-strcspn.s, my understanding is that 'ldrb' is zero extending.) Here is a