similar to: RFC: We should stop merging allocas in the inliner

The existing lifetime start/end is not very well defined (by spec, or by code) in what it means, so you could have nested lifetime markers if you wanted. If you made the spec well-defined, they would be meaningful (for loops, etc). There are a number of open bugs/complaints about lifetime markers and the fact that the scope is not well defined (the spec says "This intrinsic indicates that

On Thu, Aug 4, 2016 at 9:56 AM Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Aug 4, 2016, at 9:48 AM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Thu, Aug 4, 2016 at 9:44 AM Joerg Sonnenberger via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Mon, Aug 01, 2016 at 04:47:49AM +0000,

FYI, I ran some initial measurements just for sanity on the test-suite on x86-64: Total stack frame size: 13362520 -> 13365864 (+0.02%) Average stack frame size: 581.814 -> 581.96 (+0.02%) Average compile time: 5.71178 -> 5.67256 (within noise) Number of functions is exactly the same, so no trivially visible inlining decision changes. I've spot checked a few of the functions that

On Thu, Aug 4, 2016 at 9:44 AM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Aug 01, 2016 at 04:47:49AM +0000, Chandler Carruth via llvm-dev > wrote: > > Chris added alloca merging in the inliner a looooong time ago, 2009. The > > reason he added it was because at the time we didn't do stack coloring > and > > without it we had

Sorry I missed these comments in my first read through David. On Mon, Aug 1, 2016 at 1:06 AM Xinliang David Li via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Jul 31, 2016 at 9:47 PM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Thoughts? The code changes are easy and mechanical. My plan would be: >> > > There is one

Here are some comments. It seems to me there are 2 (mostly separate) aspects: 1. Teaching clang how to do domination / post-domination analysis, so that the lifetime information (alloca/dealloca, or lifetime markers) can be set in the right locations in the IR. Such an analysis should be able to understand the language scopes, as well as labels / gotos and EH. The results of this analysis

The LRM (http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic) essentially states that: - ptr is dead before a call to "lifetime.start size, ptr" - ptr is dead after a call to "lifetime.end size, ptr" This is all good and fine, and the expected use case is that all "lifetime.end size, ptr" markers are matched with a preceding "lifetime.start

On Wed, Nov 5, 2014 at 10:01 AM, Philip Reames <listmail at philipreames.com> wrote: > Would one of you mind taking a step back and explaining what you believe > the "stack colouring problem" to be? I'm familiar with the general meaning > of the term and even some of LLVM's implementation; I'm just not sure what > specific issue you're referring to.

Sanitizer passes really should not run before the inliner. For example, ASan moves all allocas into a "mega-alloca" to obtain fixed frame layout for reporting purposes. It also inserts a fake stack check in the function prologue which will get duplicated (but will probably still work) after inlining. MSan removes readnone/readonly from all functions because they all update shadow which

Hello, I am a student at UFMG, Brazil, and I'm currently choosing my final undergraduate project. I will be working under Professor Fernando Pereira (on cc), and we were thinking about tackling Code Generator Improvement number 2 (at http://llvm.org/OpenProjects.html). How is the status on this project? Is it still open? Thanks for your time, Thiago Martins. -------------- next part

On Mon, Aug 19, 2013 at 10:06 PM, Andrew Trick <atrick at apple.com> wrote: > Metadata is a better approach because it doesn’t interfere with > optimizations that are free to ignore it. > But in practice, they aren't going to be free to ignore it. If you have metadata which encodes an invariant (in the most general sense, lifetime instrinsics currently encode an invariant,

On Wed, Nov 5, 2014 at 11:17 AM, Philip Reames <listmail at philipreames.com> wrote: > > On 11/05/2014 10:54 AM, Reid Kleckner wrote: > > This seems fine to me. The optimizer can (soundly) conclude that %p is >> dead after the "lifetime.end" (for the two instructions), and dead before >> the "lifetime.start" (for the *single* instruction in

Thanks all. David why do you say it is particularly bad IR (other than not having gone through SROA). Is it the multiple blocks for early returns? That is how I'm supporting early returns in the middle of a basic block. I couldn't find any other way. On Sun, Apr 5, 2015 at 6:24 AM, David Jones <djones at xtreme-eda.com> wrote: > Data point: > > I use (rarely) alloca in

Hi, In my llvm code I want to create some function calls. The function prototype is as follows: int memoize ( char *function_name, int *int_params, unsigned num_ints, double *double_params, unsigned num_doubles) In order to create these calls I do the following for example: %88 = alloca [7 x i8] store volatile [7 x i8] c"ORACLE\00", [7 x i8]*

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

On Sat, Mar 28, 2020 at 2:20 PM Eli Friedman <efriedma at quicinc.com> wrote: > This would specifically be for cases where we try to rewrite the > signature? I would assume we should forbid rewriting the signature of a > call with an operand bundle. And once some optimization drops the bundle > and preallocated marking, to allow such rewriting, the signature doesn’t > need

Hi @all, I hit a problem with Polly-generated code which llvm.org/PR32251 . The problem is how @llvm.lifetime.start is placed after Polly transformed the code. Basically Polly transformed llvm.lifetime.start(&var) [...] llvm.lifetime.end(&var) into if (c) { llvm.lifetime.start(&var) } [...] llvm.lifetime.end(&var) now the llvm.lifetime.end is

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: 04 November 2014 17:16 > To: Arnaud De Grandmaison > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] lifetime.start/end clarification > > ----- Original Message ----- > > From: "Arnaud A. de Grandmaison" <arnaud.degrandmaison at arm.com> > > To:

So, in hacking on mem2reg I noticed that it doesn't actually implement optimizations enabled by lifetime markers. I thought I might take a stab at teaching it about them, but I'm left with some questions about the semantics. Much of this may have been hash out when they were added, and if so I'll appreciate your help educating me, and maybe we can come up with improved documentation to

On 5/14/20 5:33 AM, Arthur Eubanks via llvm-dev wrote: > > Is it the case that with the legacy PM there is no inlining at > either -O2 or -O3 and with newPM there is? Or is there something else > going on? > Legacy PM inlines at -O2/-O3, new PM inlines at -O1/-O2/-O3. These > cases where inlining occurs also coincide with the test failure. I > agree that inlining itself