similar to: [cfe-dev] [LLVMdev] Clang devirtualization proposal

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, cfe-dev at lists.llvm.org > Sent: Friday, August 7, 2015 7:35:57 PM > Subject: Re: [cfe-dev]

On Fri, Jul 31, 2015 at 6:18 PM, Reid Kleckner <rnk at google.com> wrote: > Consider this pseudo-IR and some possible transforms that I would expect to > be semantics preserving: > > void f(i32* readonly %a, i32* %b) { > llvm.assume(%a == %b) > store i32 42, i32* %b > } > ... > %p = alloca i32 > store i32 13, i32* %p > call f(i32* readonly %p,

On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail at philipreames.com> wrote: > > I'm wondering if there's a problematic interaction with CSE here. > Consider this example is pseudo LLVM IR: > v1 = load i64, %p, !invariant.group !Type1 > ; I called destructor/placement new for the same type, but that optimized > entirely away > p2 =

> I suspect #2 is the right design, mostly because I suspect most of the interesting and important inference cases are going to be cases where we can easily infer the stronger guarantee, and once inferred we will have much more freedom to optimize based on this stronger guarantee... Can't the stronger guarantee be represented in the existing system by either: * Adding 'readonly'

Sorry for the confusion, I pasted the code I fixed locally... Here is the code at top of the trunk: // load (select (cond, null, P)) -> load P if (Constant *C = dyn_cast<Constant>(SI->getOperand(1))) if (C->isNullValue()) { LI.setOperand(0, SI->getOperand(2)); return &LI; } So it is a bug? -----Original Message----- From:

Hi folks, this summer I will work with Richard Smith on clang devirtualization. Check out our proposal: https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing And modified LangRef http://reviews.llvm.org/D11399 You can also check out previous disscussion that was started before our proposal was ready -

Hi Sanjoy, These are both very interesting examples, and demonstrate that the problems extends beyond function attributes (encompassing dead-argument elimination, etc.). I'm beginning to think that the best solution, at least when optimizing for speed, is the one that David Li suggested: we need to internalize functions that have been optimized in certain ways (e.g. instructions with

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" <listmail at philipreames.com>, "Duncan P. N. Exon Smith" >

Hal Finkel wrote: > That summary needs unnecessarily broad. So far we've learned that: a) There are issues with atomics b) there are issues > with a safe-to-speculate attribute we don't yet have c) there might be issues with folding undefs independent of the > previous two items, but we thus-far lack a concrete example. We don't yet have enough information. I don't

I think this will have a much higher cost than my proposal to constrain how we deduce function attributes (which still fixes Sanjoy's latest example). Specifically, I think this will force us to constrain far too many transformations for the sake of code size in functions that we won't inline. Even if we were never going to deduce function attributes for anything in the function (because

Here's a fun spin on this same topic (I can't file a bug at this moment since llvm.org is down). Consider: define i32 @x(i32* %x, i1* %y) { entry: br label %loop loop: %v = phi i32 [ 0 , %entry ], [ %v.inc, %exit.inner ], [ %v, %loop ] %c = load volatile i1, i1* %y br i1 %c, label %exit.inner, label %loop exit.inner: %c1 = load volatile i1, i1* %y %x.val = load i32, i32*

Couple of other examples: void @foo(i32* %ptr) available_externally { %discard = load i32, i32* %ptr } void bar() { call @foo(i32* %x) } ==> void @foo(i32* %ptr) available_externally { } void bar() { call @foo(i32* %x) } ==> void @foo(i32* %ptr) available_externally { } void bar() { call @foo(i32* undef) ;; non optimized @foo will crash } ;;

On Sat, Jul 25, 2015 at 12:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi Piotr, > > Thanks for posting this! First, a question. When you say, regarding i8* > @llvm.invariant.group.barrier(i8*): > > "Required to handle destructors, placement new and std::launder. Call of > this function will be put on the end of each of this functions" > > I

I'm current facing an issue related to AliasSetTracker/LICM: the transitive closure of the alias sets is materially more conservative than individual aliasing queries and this conservatism leads to generally worse optimization in LICM. For instance, consider this module: declare i32 @only_reads() readonly declare void @escape(i32*, i32*, i32*) define void @f(i32 %count) { entry: %a =

Hi Piotr, Thanks for posting this! First, a question. When you say, regarding i8* @llvm.invariant.group.barrier(i8*): "Required to handle destructors, placement new and std::launder. Call of this function will be put on the end of each of this functions" I completely understand placement new and std::launder. I don't understand destructors, could you explain? Also, am I correct

This buildbot appears to have been failing for several weeks now ( http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/19490 ). Does anyone know/own/care about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Mon, Sep 28, 2015 at 11:17 PM Subject: buildbot failure in LLVM on clang-ppc64-elf-linux2 To: Aaron Ballman <aaron at

On 01/05/2017 01:20 PM, Sanjoy Das wrote: > Hi Hal, > > On Thu, Jan 5, 2017 at 11:10 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It is still only a function of its arguments, so it can be CSE'd. > That's a good example -- we can CSE it without worrying about the > memory state flowing in. > > In fact, if we have: > > *a =

A couple things I recall from implementing this in Phoenix: For LTO -- do your comdat folding as part of the up-front symbol resolution before invoking the backend (saves compile time too). Then have the linker ensure that the comdat from the LTO bundle is the winner in the final link step. That way during LTO you know which method body is going to be in the final image. May not be as easy in

Hi, Sorry for the hiatus, busy time at my university. :) After a false start and some (hopefully cogent) thought, I am now of the opinion that it will be better to have llvm natively support a somewhat different notion of parallel computation and have the frontend lower OpenMP directives (and possibly other such things) into the same. In short, I propose a intrinsic based approach which hinges

> On Dec 8, 2014, at 5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > >