search for: steinbrink

> On Mar 1, 2015, at 7:53 AM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > > On 2015.02.28 18:17:27 -0800, Philip Reames wrote: >>> On Feb 28, 2015, at 3:01 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >>> 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: >>>...

> On Feb 28, 2015, at 3:01 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > > [This time without dropping the list, sorry] > > 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: > >>>> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >>&g...

[This time without dropping the list, sorry] 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: >> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >> >>> On 2015.02.28 14:23:02 -0800, Philip Reames wrote: >>>> On 02/28/2015 10:04 AM, Björn Steinbrink wrote: >>>> Hi, >>>> >>>>> On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >>>>&...

> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > >> On 2015.02.28 14:23:02 -0800, Philip Reames wrote: >>> On 02/28/2015 10:04 AM, Björn Steinbrink wrote: >>> Hi, >>> >>>> On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >>>> ----- Original Message...

Hi, in r176827 the optimization that turns invokes with empty landing pads into plain calls was disabled for invocations of function with the "uwtable" attribute. But given this code: struct S { ~S() {}; }; void blackbox(); __attribute__((__noinline__)) void inner() { blackbox(); } int foo() { S s; inner(); return 0; } int bar() {

2017-01-31 16:59 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: > > > On Tue, Jan 31, 2017 at 3:09 AM, Björn Steinbrink <bsteinbr at gmail.com> > wrote: > >> Hi Sanjay, >> >> 2017-01-30 22:22 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: >> >>> My minimal patch idea is to ease the restriction in ShouldChangeType >>> because i1 is special. I tried the...

On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > Hi, > > On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >> ----- Original Message ----- >>> From: "Philip Reames" <listmail at philipreames.com> >>>> 6. Use the lifetime.start/lifetime.end and >>>> invariant.start/invariant.en...

On 2015.02.28 14:23:02 -0800, Philip Reames wrote: > On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > >Hi, > > > >On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: > >>----- Original Message ----- > >>>From: "Philip Reames" <listmail at philipreames.com> > >>>>6. Use the lifetime.start/lifetime.end and > >>>&gt...

Hi, AFAICT there are two places where zext instructions may get folded into PHI nodes. One is FoldPHIArgZextsIntoPHI and the other is the more generic FoldPHIArgOpIntoPHI. Now, the former only handles PHIs with more than 2 incoming values, while the latter only handles casts where the source type is legal. This means that for an PHI node with two incoming i8 values, both resulting from `zext i1

...gt; > I'm not sure yet, but there's a chance that change might induce problems > (infinite loops) with this: > https://github.com/llvm-mirror/llvm/blob/master/lib/Transfor > ms/InstCombine/InstCombineSimplifyDemanded.cpp#L374 > > > On Sun, Jan 29, 2017 at 3:09 PM, Björn Steinbrink via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> AFAICT there are two places where zext instructions may get folded into >> PHI nodes. One is FoldPHIArgZextsIntoPHI and the other is the more generic >> FoldPHIArgOpIntoPHI. Now, the former...

On Tue, Jan 31, 2017 at 3:09 AM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > Hi Sanjay, > > 2017-01-30 22:22 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: > >> My minimal patch idea is to ease the restriction in ShouldChangeType >> because i1 is special. I tried the patch below, and it works on the...

...lutely identical dbg.declares and the assert in addFragmentOffset() blows. Who's at fault? There is also an existing testcase that checks that there _are_ indeed two dbg.declares to a single alloca: Transforms/Inline/alloca-dbgdeclare-merge.ll Regards, Mikael On 09/19/2017 02:27 PM, Björn Steinbrink via llvm-dev wrote: > Hi, > > I'm hitting an assertion "overlapping or duplicate fragments" in the > DWARF codegen in addFragmentOffset(). This originates from a > duplicated dbg.declare intrinsic, declaring the same fragment twice. > The duplicated call was generat...

Hi Sanjay, 2017-01-30 22:22 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: > My minimal patch idea is to ease the restriction in ShouldChangeType > because i1 is special. I tried the patch below, and it works on the > example...and nothing in 'make check' failed. :) > Yeah, that would work for me as well, I just wasn't sure about the implications that has.

...from -/// a smaller to a larger illegal type. +/// a smaller to a larger illegal type. i1 is always treated as a legal type. bool InstCombiner::ShouldChangeType(Type *From, Type *To) const { assert(From->isIntegerTy() && To->isIntegerTy()); On Mon, Jan 30, 2017 at 1:22 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > Hi Sanjay, > > unfortunately that patch does not help in my case. Here's the IR that > fails to get fully optimized: > > target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" > target triple = "x86_64-unkn...

Hi, I'm hitting an assertion "overlapping or duplicate fragments" in the DWARF codegen in addFragmentOffset(). This originates from a duplicated dbg.declare intrinsic, declaring the same fragment twice. The duplicated call was generated by the jump threading pass. I have a patch (see below) that removes simply such duplicates, but I'm not sure whether that is the right

Hi, MemDep caches results for local queries and provides means to invalidate them by keeping reverse maps. Unfortunately, it also caches results that represent non-local dependencies, for which there are no reverse map entries, and thus those entries can not be invalidated. This is a problem when an optimization turns a non-local dependency into a local one.

Hi, I’d like to run clang with some optimization passes (-reassociate, -simplifycfg, -dce ) But in the end I need to dump the llvm IR (no link to assembly generation). I didn’t find any way to do that. I found out that passes are run via opt, but opt generates bc code, and I want IR. Any help will be welcome Thanks, Régis -------------- next part

Hi all, in Rust we have a bug report about about a missed optimization which one would expect CallSlot optimization to handle: https://github.com/rust-lang/rust/issues/48533 The IR looks like this: define void @bar(%S* noalias nocapture sret dereferenceable(16), void (%S*)* nocapture nonnull) unnamed_addr #0 { %3 = alloca %S, align 8 %4 = bitcast %S* %3 to i8* call void

Hi, On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Philip Reames" <listmail at philipreames.com> > > > 6. Use the lifetime.start/lifetime.end and > > > invariant.start/invariant.end intrinsics where possible > > Do you find these help in practice? The few experiments I ran were > > neutral at best

...not be duplicating dbg.declares, only dbg.values. -- adrian > > There is also an existing testcase that checks that there _are_ indeed two dbg.declares to a single alloca: Transforms/Inline/alloca-dbgdeclare-merge.ll > > Regards, > Mikael > > On 09/19/2017 02:27 PM, Björn Steinbrink via llvm-dev wrote: >> Hi, >> I'm hitting an assertion "overlapping or duplicate fragments" in the >> DWARF codegen in addFragmentOffset(). This originates from a >> duplicated dbg.declare intrinsic, declaring the same fragment twice. >> The duplicated ca...