search for: d24096

...r > On 28 Sep 2016, at 18:50, Philip Reames <listmail at philipreames.com> wrote: > > There's a bit of additional context worth adding here... > > Up until very recently, we had a form of widening implemented in GVN. We decided to remove this in https://reviews.llvm.org/D24096 precisely because its placement in the pass pipeline was inhibiting other optimizations. There's also a major problem with doing widening at the IR level which is that widening a pair of atomic loads into a single wider atomic load can not be undone. This creates a major pass ordering problem o...

...Philip Reames<listmail at philipreames.com> wrote: > >> > >> There's a bit of additional context worth adding here... > >> > >> Up until very recently, we had a form of widening implemented in GVN. We decided to remove this in https://reviews.llvm.org/D24096 precisely because its placement in the pass pipeline was inhibiting other optimizations. There's also a major problem with doing widening at the IR level which is that widening a pair of atomic loads into a single wider atomic load can not be undone. This creates a major pass ordering problem o...

...lipreames.com> >> wrote: >> >> >> >> There's a bit of additional context worth adding here... >> >> >> >> Up until very recently, we had a form of widening implemented in GVN. >> We decided to remove this in https://reviews.llvm.org/D24096 precisely >> because its placement in the pass pipeline was inhibiting other >> optimizations. There's also a major problem with doing widening at the IR >> level which is that widening a pair of atomic loads into a single wider >> atomic load can not be undone. This cre...

...>> There's a bit of additional context worth adding here... >>> >> >>> >> Up until very recently, we had a form of widening >>> implemented in GVN.  We decided to remove this in >>> https://reviews.llvm.org/D24096 >>> <https://reviews.llvm.org/D24096> precisely because its >>> placement in the pass pipeline was inhibiting other >>> optimizations. There's also a major problem with doing >>> widening at the IR level which is that wid...

...ames <listmail at philipreames.com> > wrote: > >> > >> There's a bit of additional context worth adding here... > >> > >> Up until very recently, we had a form of widening implemented in GVN. > We decided to remove this in https://reviews.llvm.org/D24096 precisely > because its placement in the pass pipeline was inhibiting other > optimizations. There's also a major problem with doing widening at the IR > level which is that widening a pair of atomic loads into a single wider > atomic load can not be undone. This creates a major pas...

Hi, I'm trying to optimize a pattern like this into a single i16 load: %1 = bitcast i16* %pData to i8* %2 = load i8, i8* %1, align 1 %3 = zext i8 %2 to i16 %4 = shl nuw i16 %3, 8 %5 = getelementptr inbounds i8, i8* %1, i16 1 %6 = load i8, i8* %5, align 1 %7 = zext i8 %6 to i16 %8 = shl nuw nsw i16 %7, 0 %9 = or i16 %8, %4 I came across load combine pass which is motivated

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

...lipreames.com> wrote: > >>>> > >>>> There's a bit of additional context worth adding here... > >>>> > >>>> Up until very recently, we had a form of widening implemented in GVN. We decided to remove this in https://reviews.llvm.org/D24096 precisely because its placement in the pass pipeline was inhibiting other optimizations. There's also a major problem with doing widening at the IR level which is that widening a pair of atomic loads into a single wider atomic load can not be undone. This creates a major pass ordering problem o...

On Wed, Nov 16, 2016 at 2:03 AM, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This is really great to see, as I’ve spent far too much of my life over > the past two years fighting with undocumented assumptions made by GVN. A > couple of quick questions about the new GVN, based on problems I’ve had > with the old one: > > Does it assume that it’s