search for: islegaladdressingmode

Dear all, From what I can gather, there is currently no way for loop strength reduction to target pre- and post-increment addressing modes. This is because the target hook `isLegalAddressingMode` in TargetTransformInfo.h doesn’t allow for pre- and post-increment. There is in fact a comment to that effect on the function prototype: “TODO: handle pre/postinc as well” (see http://llvm.org/docs/doxygen/html/TargetTransformInfo_8h_source.html line 310). So I was wondering: is there a way to wo...

Hi, We wrote an optimization that eliminates common sub-expressions in a group of similar GEPs for the NVPTX backend. It speeds up some of our benchmarks by up to 20%, which convinces us to try to upstream it. Here's a brief description of why we wrote this optimization, what we did, and how we did it. Loops in CUDA programs are often extensively unrolled by programmers and compilers,

Hi All, I have a question regarding LLVM backend. I appreciate a lot if anyone can provide some hints. My work here is to avoid base+index address mode for X86 target, to allow base-register only or index-register only address mode. For example, "mov (%rsi), %rbx" is allowed, but "mov (%rsi, %rax), %rbx" is not allowed. I understand LLVM backend is a complex system. Can any

----- Original Message ----- > From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> > To: llvmdev at cs.uiuc.edu > Sent: Monday, November 26, 2012 1:40:24 PM > Subject: [LLVMdev] LSR pass > > > > > > Hi, > > > > I would like some help regarding the LSR pass. It seems that it likes > to duplicate address calculations as in the

..."smartly" recognizes ptx doesn't support any addressing mode that can fold this GEP (This addressing mode issue is worth another thread, and one of my colleagues is working on that). > > - To make this target independent, I think you just need to insert some > calls to TLI.isLegalAddressingMode (or equivalently, > TTI.isLegalAddressingMode) just to make sure that the offsets you're > creating are legal on the target. This will essentially be a noop for > NVPTX, but will matter for other targets. > Ack'ed > > Thanks for posting this, > Hal > > ----- Or...

Hi, The target supports indexing by register or immediate. Multiplications are not supported by any load / store instructions. Would it be possible to make LSR aware of this? Thanks, Jonas Paulsson -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Saturday, December 01, 2012 5:59 AM To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LSR pass

...track down the reason for the difference in output > generated by > opt. The difference is caused when the target triple specified in the > test-case > is not a supported target for opt/clang/llvm. In this case, opt doesn't thow > an > error and hence, later in LSR the NoTTI::isLegalAddressingMode is called > which > results in the different output. > > The clang-native-arm build-bot builds clang with ARM being the only > supported > target[1]. This is the reason the failure occured only on this build-bot. > The > problem can be reproduced on x86-hosted clang, if you...

I come across a situation that I am having a hard time to understand. When I compile the following code : char *tst( char *dest, const char *src, unsigned int len ) { for (int i=0 ; i<len ; i++) { dest[i] = src[i]; } return dest; } Clang generates this for the ‘for’ body: for.body: ; preds = %for.cond %arrayidx = getelementptr inbounds i8,

...tly on the understanding of the problem, but I got stuck at a more concrete problem. It seems to me that there’s no way to instruct LLVM to adopt a more costly result for the first form, as it would be necessary for my architecture, unless I’m missing something (?). (As a side note: I implemented “isLegalAddressingMode”, but it turned to be virtually identical to the default one except for the smaller immediate sizes, so I think it doesn’t make much difference. Post/Pre increment addressing mode is not supported in my architecture so this is reflected, and I haven’t either added the setIndexedLoadAction calls to...

...or the difference in output >> generated by >> opt. The difference is caused when the target triple specified in the >> test-case >> is not a supported target for opt/clang/llvm. In this case, opt doesn't thow >> an >> error and hence, later in LSR the NoTTI::isLegalAddressingMode is called >> which >> results in the different output. >> >> The clang-native-arm build-bot builds clang with ARM being the only >> supported >> target[1]. This is the reason the failure occured only on this build-bot. >> The >> problem can be reprod...

...release consistent and processor consistent loads in ARMv8.3-A. [r310575](http://reviews.llvm.org/rL310575). * A basic RISCVAsmParser has landed. [r310363](http://reviews.llvm.org/rL310363). * The TargetTransformInfo::isFoldableMemAccess hook has been removed, as its functionality is subsumed by isLegalAddressingMode. [r310463](http://reviews.llvm.org/rL310463). * The AArch64 and ARM backends gained assembler support for the ARMv8.2a dot product instructions. (Question to my readers: Given Arm's recent rebranding, should that be Armv8.2a or armv8.2a instead?). [r310480](http://reviews.llvm.org/rL310480), [...

...it is? After extra formulas are generated, some of them can contain constants that were not in the code before and thus may require an instruction to put them into a register, yet for constants the SetupCost will be 0. On a similar note, are SCEVUnknowns presumed to already have a register? 3. isLegalAddressingMode There are many addressing modes that are legal on Hexagon, yet given a choice, some are preferable to others. LSR treats all of them as equivalent as long as a formula can be folded completely into it. Has anyone thought about making the cost of an addressing mode be more detailed? 4. RateFormu...

...oads. 21. Anton significantly improved 'switch' lowering, improving codegen for sparse switches that have dense subregions, and implemented support for the shift/and trick. 22. The code generator now has more accurate and general hooks for describing addressing modes ("isLegalAddressingMode") to optimizations like loop strength reduction and code sinking. 23. Dale and Evan contributed several improvements to the Loop Strength Reduction pass, and added support for sinking expressions across blocks to reduce register pressure. 24. Evan added support for tracking ph...

...pool loads. x. Anton significantly improved 'switch' lowering, improving codegen for sparse switches that have dense subregions, and implemented support for the shift/and trick. x. The code generator now has more accurate and general hooks for describing addressing modes ("isLegalAddressingMode") to optimizations like loop strength reduction and code sinking. x. Dale and Evan contributed several improvements to the Loop Strength Reduction pass, and added support for sinking expressions across blocks to reduce register pressure. x. Evan added support for tracking physreg s...