search for: instcombineloadstorealloca

...2) elements, I can not extract its last element. Given this restriction I feel we have a bug here (uint64_t is passed as a unsigned). This cant happen because of the if (NumElements > 1024) guard, but its a bug anyways. https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L634 Thanks, -Xin

...nd a way to keep it while removing the ptrtoint-s that are unnecessary, and doing clean-up in SROA is a straightforward way to achieve that. What does everybody think? Thanks, Alexey [1] combineLoadToOperationType() https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L556 [2] [LLVMdev] RFC: Missing canonicalization in LLVM http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200702/cf9a8129/attachment.html&g...

...at will happen is: > %shr = lshr i16, %x, 129 > store i16 %shr, i16* @y > > will get transformed into: > store i16 undef, i16* @y > > Then we will delete the store of undef using the following: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp?revision=234601&view=markup#l978 > > >> Thanks. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >...

...accessed directly via an `addrspacecast` to `addrspace(0)`. It seems to me that this sort of optimisation is only valid if it is guaranteed that the two address spaces alias for the given target triple (which for SPIR, they do not). This particular optimisation is coming from lines ~290-300 of InstCombineLoadStoreAlloca.cpp, although I suspect this isn’t the only case where this might happen. Adding a check to only perform this replacement if the two address spaces are equal fixes the issue for me, but this is probably too conservative since many targets with flat address spaces will probably benefit from this op...

For example: unsigned int x, y; void foo() { y = x >> 129; } Where int is a 16bit type, the .ll is producing only 'ret void' at O3. At O0 the .ll looks fine but then llc gets rid of it an simply returns. I'm just curious what the reasoning is for this? It isn't trying to set y to anything at all. Thanks. -------------- next part -------------- An HTML attachment was

...nt() to determine the alignment of the merged constant. * lib/Transforms/Vectorize/BBVectorize.cpp - Depending on what options are set this pass avoids vectorization if it would introduce loads and store of less than the alignment returned by getPreferredAlignment(). * lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp - getPrefTypeAlignment() is used to explictly set the alignment of allocas with unspecified alignment. Also instcombine tries to enforce preferred alignment for loads and stores if possible. Does it seem reasonable to change these to use ABI alignment? -- Richard Osborne | XMOS http://www...

...timisation is only valid if it is guaranteed that the two address spaces alias for the given target triple (which for SPIR, they do not). > > I’m not sure “alias” is the right consideration here. > >> >> >> This particular optimisation is coming from lines ~290-300 of InstCombineLoadStoreAlloca.cpp, although I suspect this isn’t the only case where this might happen. >> >> Adding a check to only perform this replacement if the two address spaces are equal fixes the issue for me, but this is probably too conservative since many targets with flat address spaces will probably be...

...ing clean-up in >> SROA is a straightforward way to achieve that. >> >> What does everybody think? >> >> Thanks, >> Alexey >> >> [1] combineLoadToOperationType() >> https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L556 >> [2] [LLVMdev] RFC: Missing canonicalization in LLVM >> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >&...

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, "Jingyue Wu" <jingyue at google.com> > Sent: Wednesday, July 1, 2015 2:27:59 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > >

...ze/BBVectorize.cpp - Depending on what options are set this pass avoids vectorization if it would introduce loads and store of less than the alignment returned by getPreferredAlignment(). I can't comment on this specifically, but this also sounds wrong. Hal? > * lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp - getPrefTypeAlignment() is used to explictly set the alignment of allocas with unspecified alignment. Also instcombine tries to enforce preferred alignment for loads and stores if possible. This case is more interesting to me - the idea here is that instcombine is trying to expose alignment...

...oads because this might cause prevent vector-aligned loads from being generated. In theory we could always form the unaligned loads and let the legalizer break them up as necessary, but this often leads to suboptimal code generation for various reasons. > > > * lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp - > > getPrefTypeAlignment() is used to explictly set the alignment of > > allocas with unspecified alignment. Also instcombine tries to > > enforce preferred alignment for loads and stores if possible. > > > This case is more interesting to me - the idea here is th...

...t the two address spaces alias for the given target triple (which for SPIR, they do not). >>> >>> I’m not sure “alias” is the right consideration here. >>> >>>> >>>> >>>> This particular optimisation is coming from lines ~290-300 of InstCombineLoadStoreAlloca.cpp, although I suspect this isn’t the only case where this might happen. >>>> >>>> Adding a check to only perform this replacement if the two address spaces are equal fixes the issue for me, but this is probably too conservative since many targets with flat address spaces...

On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow (e.g. the maximum preferred alignment across all

On 06/09/12 20:24, Chris Lattner wrote: > On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com> wrote: > >> I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code

...ining psub as instruction is fine. :) > Regarding the instcombine, it should be very easy to keep loads and stores of pointers as pointer typed in instcombine. Likely just a missing case in the code I added/touched there. That's really good. :) I found that combineLoadToOperationType from InstCombineLoadStoreAlloca was responsible for the transformation. I can upload a patch for that if ok. Best Regards, Juneyoung Lee On Mon, Jan 14, 2019 at 5:36 PM Chandler Carruth <chandlerc at gmail.com> wrote: > While I'm very interested in the end result here, I have some questions > that don't see...

...Regarding the instcombine, it should be very easy to keep loads and >> stores of pointers as pointer typed in instcombine. Likely just a missing >> case in the code I added/touched there. >> >> That's really good. :) I found that combineLoadToOperationType from >> InstCombineLoadStoreAlloca was responsible for the transformation. >> I can upload a patch for that if ok. >> >> Best Regards, >> Juneyoung Lee >> >> On Mon, Jan 14, 2019 at 5:36 PM Chandler Carruth <chandlerc at gmail.com> >> wrote: >> >>> While I'm very int...

> glibc does accept patches...or are you talking about two separate instances of this problem, both in glibc and something else? I originally saw this in a benchmark (which it may be possible to get changed) and only afterward found the glibc idiom. The most recent glibc code is a bit more complicated than I represented below. If you look up obstack.h you can see what’s there now.

Hello all, This is a proposal for reducing # of ptrtoint/inttoptr casts which are not written by programmers but rather generated by LLVM passes. Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, the output IR contains 22,771 inttoptr instructions. However, when compiling it with -O0, there are only 1048

...r.cpp for Release+Asserts build llvm[3]: Compiling DwarfExpression.cpp for Release+Asserts build llvm[3]: Compiling LoopUnswitch.cpp for Release+Asserts build llvm[3]: Compiling DwarfFile.cpp for Release+Asserts build llvm[3]: Compiling X86WinEHState.cpp for Release+Asserts build llvm[3]: Compiling InstCombineLoadStoreAlloca.cpp for Release+Asserts build llvm[3]: Compiling DwarfStringPool.cpp for Release+Asserts build llvm[3]: Compiling LowerAtomic.cpp for Release+Asserts build llvm[3]: Building Release+Asserts Archive Library libLLVMX86CodeGen.a make[4]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Targ...