similar to: Load combine pass

One of the arguments for doing this earlier is inline cost perception of the original pattern. Reading i32/i64 by bytes look much more expensive than it is and can prevent inlining of interesting function. Inhibiting other optimizations concern can be addressed by careful selection of the pattern we’d like to match. I limit the transformation to the case when all the individual have no uses other

> On 29 Sep 2016, at 03:23, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Artur, > > Artur Pilipenko via llvm-dev wrote: > > One of the arguments for doing this earlier is inline cost > > perception of the original pattern. Reading i32/i64 by bytes look much > > more expensive than it is and can prevent inlining of interesting > >

Hi, Can I ask what is the status of load widening. It seems there is no load widening on IR at all. // Paweł On Wed, Oct 5, 2016 at 1:49 PM Artur Pilipenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Philip and I talked about this is person. Given the fact that load > widening in presence of atomics is irreversible transformation we agreed > that we don't want to do

Ok, thanks. Are there any plans to reintroduce it on the IR level? I'm not confident this is strictly necessary, but in some cases not having load widening ends up really bad. Like in the case where vectorizer tries to do something about it: https://godbolt.org/z/60RuEw https://bugs.llvm.org/show_bug.cgi?id=42708 At the current state I'm forced to use memset() to express uint64 load from

If we do load combining at the IR level, one thing we'll need to give some thought to is atomicity.  Combining two atomic loads into a wider (legal) atomic load is not a reversible transformation given our current specification. I've been thinking about a concept I've been tentatively calling "element wise atomicity" which would make this a reversible transform by

> On 29 Sep 2016, at 21:01, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Artur, > > Artur Pilipenko wrote: > > > BTW, do we really need to emit an atomic load if all the individual > > components are bytes? > > Depends -- do you mean at the at the hardware level or at the IR > level? > > If you mean at the IR level, then I

On 28 Sep 2016, at 16:50, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > At this point, my general view is that widening transformations of any kind should be done very late. Ideally, this is something the backend would do, but doing it as a CGP like fixup pass over the IR is also reasonable. I’m really glad to see that this is gone in GVN - it will reduce our

On 29 Sep 2016, at 01:25, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi David, > > David Chisnall via llvm-dev wrote: > > On 28 Sep 2016, at 16:50, Philip Reames via llvm-dev<llvm-dev at lists.llvm.org> wrote: > >> At this point, my general view is that widening transformations of any kind should be done very late. Ideally, this is

On 10/03/2011 09:36 PM, Villmow, Micah wrote: > One of the projects I am working on with others is to make LLVM-IR endian agnostic. > > > > So, I am sending out this proposal for feedback to the LLVM community. I’ve attached > > pretty version of the proposal in PDF format and pasted a 80-column safe text version > > below. > > > > A second smaller

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Shixiong Xu" <shixiong at cadence.com> > Cc: llvm-dev at lists.llvm.org > Sent: Thursday, August 18, 2016 11:05:35 AM > Subject: Re: [llvm-dev] Cost model is missing in InstCombiner > +David M. > > On Aug 17, 2016, at 3:48 AM, Shixiong Xu

On Wed, Oct 19, 2016 at 4:52 AM Nuno Lopes <nuno.lopes at ist.utl.pt> wrote: > > I'm still digesting the proposal in its entirety, but one point I want > to call out here: > > > >> On Tue, Oct 18, 2016 at 1:39 PM Friedman, Eli via llvm-dev wrote: > >> Instcombine currently transforms "memcpy(dst, src, 4)" to "load i32 src; > >>

Hello, We've just got a bug report from Mozilla folks about AddressSanitizer false positive with -O2. Turns out there is a conflict between load widening and AddressSanitizer. Simple reproducer: % cat load_widening.c && echo ========= && clang -O2 -c load_widening.c -flto && llvm-dis load_widening.o && cat load_widening.o.ll void init(char *); int foo() {

Hi, I think canEvaluateTruncated() in InstCombiner needs use cost model to decide whether perform optimization or not. Without cost model from TargetTransformInfo, aggressively optimizing IR in vector types according to the number of bits demanded may lead to scalarization of vector operations. For example, if the input IR is: %wide.load25 = load <32 x i8>, <32 x i8>* %231, align

Hi Joan, On Mon, 13 May 2019 at 18:01, Joan Lluch <joan.lluch at icloud.com> wrote: > After looking at it a bit further, I think this is a Clang thing. Clang issues “align 2” if the struct has at least one int (2 bytes), but also if the entire struct size is multiple of 2. For example a struct with 4 char members. In these cases the LLVM backend correctly creates word sized load/stores

On 12/16/11 12:24 PM, Kostya Serebryany wrote: > Hello, > > We've just got a bug report from Mozilla folks about AddressSanitizer > false positive with -O2. > Turns out there is a conflict between load widening and AddressSanitizer. > > Simple reproducer: > % cat load_widening.c&& echo =========&& clang -O2 -c load_widening.c -flto&&

"Rotem, Nadav" <nadav.rotem at intel.com> writes: > I can think of two ways to represent masks in x86: sparse and > packed. In the sparse method, the masks are kept in <4 x 32bit> > registers, which are mapped to xmm registers. This is the ‘native’ way > of using masks. This argues for the sparse representation, I think. > _Sparse_ After my discussion with

One of the projects I am working on with others is to make LLVM-IR endian agnostic. So, I am sending out this proposal for feedback to the LLVM community. I've attached pretty version of the proposal in PDF format and pasted a 80-column safe text version below. I'm looking forward to comments and feedback. Thanks, Micah Villmow Text of Proposal:

Hello, I started working on adding vector support for the SELECT and CMP instructions in the codegen (bugs: 3384, 1784, 2314).  Currently, the codegen scalarizes vector CMPs into multiple scalar CMPs.  It is easy to add similar scalarization support to the SELECT instruction.  However, using multiple scalar operations is slower than using vector operations. In LLVM, vector-compare operations

On Fri, Dec 16, 2011 at 12:19 PM, John Criswell <criswell at illinois.edu> wrote: > On 12/16/11 12:24 PM, Kostya Serebryany wrote: > > Hello, > > We've just got a bug report from Mozilla folks about AddressSanitizer false > positive with -O2. > Turns out there is a conflict between load widening and AddressSanitizer. > > Simple reproducer: > > % cat

On Fri, May 29, 2020 at 4:00 PM Richard Smith <richard at metafoo.co.uk> wrote: > > On Fri, 29 May 2020 at 11:06, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 28 May 2020, at 18:42, Bill Wendling wrote: >> >> > On Tue, May 26, 2020 at 7:49 PM James Y Knight via llvm-dev >> > <llvm-dev at lists.llvm.org> wrote: