similar to: [LLVMdev] [cfe-dev] Inlining and virtualization in Clang/LLVM

On Wed, Oct 3, 2012 at 12:01 PM, Matthieu Monrocq <matthieu.monrocq at gmail.com> wrote: > On Sun, Sep 30, 2012 at 5:04 PM, David Blaikie <dblaikie at gmail.com> wrote: >> I'm not sure whether this is the exact problem at hand in your example, >> but one of the major hurdles llvm suffers when trying to devirtualize >> is the second point you made: it

On Thu, Oct 4, 2012 at 7:37 AM, Nick Lewycky <nlewycky at google.com> wrote: > On 3 October 2012 13:30, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Wed, Oct 3, 2012 at 12:01 PM, Matthieu Monrocq >> <matthieu.monrocq at gmail.com> wrote: >> > On Sun, Sep 30, 2012 at 5:04 PM, David Blaikie <dblaikie at gmail.com> >> > wrote:

On Sun, Sep 30, 2012 at 5:04 PM, David Blaikie <dblaikie at gmail.com> wrote: > I'm not sure whether this is the exact problem at hand in your example, > but one of the major hurdles llvm suffers when trying to devirtualize > is the second point you made: it doesn't see the invariance of the > table pointer post construction. In your specific example the > constructors

On 3 October 2012 13:30, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Oct 3, 2012 at 12:01 PM, Matthieu Monrocq > <matthieu.monrocq at gmail.com> wrote: > > On Sun, Sep 30, 2012 at 5:04 PM, David Blaikie <dblaikie at gmail.com> > wrote: > >> I'm not sure whether this is the exact problem at hand in your example, > >> but one of the

On Thu, Oct 4, 2012 at 7:23 PM, Matthieu Monrocq <matthieu.monrocq at gmail.com> wrote: > On Thu, Oct 4, 2012 at 7:37 AM, Nick Lewycky <nlewycky at google.com> wrote: >> On 3 October 2012 13:30, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> On Wed, Oct 3, 2012 at 12:01 PM, Matthieu Monrocq >>> <matthieu.monrocq at gmail.com> wrote:

Hello, at the moment the devirtualization of calls is performed in Clang (as far as I understand) whilst inlining and constant propagation are the optimizer's (LLVM) job. It is probably necessary for Clang to perform "some" devirtualization (the meaning of `final` is not known to LLVM), however all the stuff to determine what the dynamic type of a variable is seems redundant with

2017-04-01 15:59 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>: > > > 2017-03-31 23:20 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > >> Hi Piotr, >> >> On March 31, 2017 at 1:07:12 PM, Piotr Padlewski >> (piotr.padlewski at gmail.com) wrote: >> > [snip] >> > Do I understand it correctly, that it is legal to

On Dec 8, 2011, at 10:03 PM, Nick Lewycky wrote: > Noalias returns, nocapture, SCC refinement, linkonce_odr and > available_externally were added with the goal of making devirtualization > in LLVM happen, but as orthogonal independent optimizations. I think > LLVM should continue with this design. If you want to implement a single > substantial optimization pass, I would suggest

Hello all, Our compilers class has been using LLVM, and a partner and I decided to implement devirtualization of virtual C++ calls in LLVM as a class project. We quickly realized that existing debug metadata generated by Clang didn't give us enough info to (precisely) implement this, and as such have already begun modifying Clang to insert such metadata. However, for devirtualization we also

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

On Tue, Feb 03, 2015 at 04:03:45PM -0800, Sean Silva wrote: > One other thing: if this can be used for control-flow integrity, I assume > it has to have good knowledge of the available indirect call targets. Could > we also use this information for devirtualization? I would expect so. If a bitset contains only one element, we should be able to teach the lowering pass to simply test that

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

Right now, I don't see any way to declare that a pointer value within a function does not alias any pointer not based on it. Basically, I would like to be able to apply "noalias" to an instruction/virtual reg the same way that noalias is applied to function arguments. A few weeks ago when discussing devirtualization possibilities in C++, it turned out that while you can assume that

On 9 May 2013 19:13, John McCall <rjmccall at apple.com> wrote: > On May 9, 2013, at 6:34 PM, Nick Lewycky <nlewycky at google.com> wrote: > > I'm looking into how we can improve devirtualization in clang, and there > a language in C++ feature I'd like to take advantage of which would let us > perform elimination of more vptr loads. In this code: > > >

Hello, While instrumenting LLVM IR in ThreadSanitizer (race detector), I need to distinguish between a store to vtable pointer (vptr) and any other regular store. This special treatment should be limited to class DTORs, so I should also know when a function is a DTOR. Rationale: need to distinguish benign and harmful races on vptr (

On Sun, Nov 14, 2010 at 11:45 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Sun, Nov 14, 2010 at 11:17 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> To fix that and compile C++ correctly while aggressively >> devirtualizing it, we would need to apply "noalias" to the result of >> placement-new in all cases, even when placement-new

> On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Hi folks, > > here is a link to the proposal that we've been working on lately: > https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing

Hi folks, here is a link to the proposal that we've been working on lately: https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBt vjWUod2SujZVEo/edit?usp=sharing But for the record, I also paste it here. Feedback will be really appreciated!

On Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote: > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need to distinguish between a store to vtable pointer (vptr) and any other regular store. > This special treatment should be limited to class DTORs, so I should also know when a function is a DTOR. > Rationale: need to distinguish benign and

Following a question on StackOverflow [1], I was wondering if for big allocations, LLVM would "delay" the allocation or rather perform it upfront. The following code was thus submitted to the LLVM Try Out page: void doSomething(char*,char*); void function(bool b) { char b1[1 * 1024]; if( b ) { char b2[1 * 1024]; doSomething(b1, b2); } else { char