similar to: [LLVMdev] Why does "uwtable" prevent optimizing Invoke -> Call?

Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] Why does "uwtable" prevent optimizing Invoke -> Call?"

2015 Mar 01
2
[LLVMdev] RFC: PerfGuide for frontend authors
> 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 2:30 PM, Björn
2015 Mar 01
2
[LLVMdev] RFC: PerfGuide for frontend authors
> 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: >>>> >>>>> On 2015.02.28
2015 Feb 28
0
[LLVMdev] RFC: PerfGuide for frontend authors
[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, >>>>
2015 Feb 28
2
[LLVMdev] RFC: PerfGuide for frontend authors
> 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 ----- >>>>> From: "Philip
2017 Jan 31
1
Folding zext from i1 into PHI nodes with only zwo incoming values.
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
2017 Jan 31
2
Folding zext from i1 into PHI nodes with only zwo incoming values.
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.
2015 Aug 28
2
get llvm IR after a clang optimization pass.
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
2017 Jan 31
0
Folding zext from i1 into PHI nodes with only zwo incoming values.
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 >> example...and nothing in 'make
2015 Feb 28
2
[LLVMdev] RFC: PerfGuide for frontend authors
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.end intrinsics where possible >>> Do you find these
2015 Feb 28
0
[LLVMdev] RFC: PerfGuide for frontend authors
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 >
2017 Jan 30
3
Folding zext from i1 into PHI nodes with only zwo incoming values.
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-unknown-linux-gnu" define fastcc zeroext i1 @testfunc(i8** noalias nocapture readonly dereferenceable(8)) unnamed_addr { entry-block: %1 = load i8*, i8**
2015 Oct 05
2
Swift to IR, generates wrong IR
Hi, 2015-10-05 11:49 GMT+02:00 Rinaldini Julien via llvm-dev <llvm-dev at lists.llvm.org>: > Sorry, the error is (the previous one was from Apple’s lli): > > Documents/strong.codes/code/build/obfuscator-llvm/bin/opt: test.ll:57:203: error: expected comma after getelementptr's type > @_METACLASS_DATA__TtC4test13TipCalculator = private constant { i32, i32, i32, i32, i8*, i8*,
2015 Aug 31
2
alloca combining, not (yet) possible ?
Caldarale, Charles R schrieb: > You have not provided us with the declaration for f(). Unless its argument is marked with the nocapture attribute, the compilation of g() cannot assume that f() has not retained a pointer to the x struct and is using it in the second call. > thanks a lot for the input. Yes, I forgot to that. The C function declaration would have been void f( struct a_b
2017 Jan 29
3
Folding zext from i1 into PHI nodes with only zwo incoming values.
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
2017 Sep 19
3
Jump Threading duplicates dbg.declare intrinsics for fragments, bug?
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
2017 Sep 19
0
Jump Threading duplicates dbg.declare intrinsics for fragments, bug?
Hi Björn, I don't have any answers, just more confusion. Hopefully someone else can bring some light to this. I'm also interested in dbg.declares and what the rules are regarding them since it's not very clear to me at the moment. A similar fix as yours was made for duplicate non-fragment dbg.declares in r305244 and there is a bit of discussion about it in
2018 Jan 26
1
MemDep: Invalidating NonLocal result cache entries?
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.
2017 Jan 30
0
Folding zext from i1 into PHI nodes with only zwo incoming values.
Hi Björn and Daniel, FoldPHIArgOpIntoPHI() is for unary ops (casts), but it calls FoldPHIArgBinOpIntoPHI() for binops which takes care of almost everything else? 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. :) Index:
2015 Feb 28
0
[LLVMdev] RFC: PerfGuide for frontend authors
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
2018 Mar 05
1
Allow CallSlot optimization for throwing functions for sret arguments
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