similar to: [ThinLTO] Making ThinLTO functions not fail hasExactDefinition (specifically preventing it from being derefined)

Hi Charles, On Tue, Jul 11, 2017 at 12:27 PM, Davide Italiano <davide at freebsd.org> wrote: >> I'm working on adding interprocedural FunctionAttrs optimization >> (http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO >> so it does something similar to what LTO is doing >> (https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem

This email is just to summarize a bit of digging I did last night into our attribute inference.  Unfortunately, I'm not going to have time to implement any of the gaps I noticed, but I figured someone else out there might be interested. *Missing Attributes* argmemonly - influences AA, particularly relevant for libraries which wrap build in functions which are annotated, but don't

Maybe we could list some of these as a GSoC project? Seems like a self-contained task that can be simple as desired and as hard as the student wants it to be. Nuno -----Original Message----- From: Philip Reames via llvm-dev Sent: Friday, February 16, 2018 6:48 PM To: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote:

Sure, but is anyone willing to mentor?  I don't have time.  I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote: > Yes, I agree with you this sounds like a great GSoC. > > On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Maybe we could list some of these as a GSoC project?

On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote: > > This email is just to summarize a bit of digging I did last night into > our attribute inference.  Unfortunately, I'm not going to have time to > implement any of the gaps I noticed, but I figured someone else out > there might be interested. > > *Missing Attributes* > > argmemonly - influences AA,

Yes, I agree with you this sounds like a great GSoC. On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Maybe we could list some of these as a GSoC project? > Seems like a self-contained task that can be simple as desired and as hard > as the student wants it to be. > > Nuno > > -----Original Message----- From: Philip Reames

I can step in, if that's ok with you. Nuno -----Original Message----- From: Philip Reames Sent: Saturday, February 17, 2018 1:04 AM To: Davide Italiano ; Nuno Lopes Cc: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases Sure, but is anyone willing to mentor? I don't have time. I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote:

SGTM On 02/17/2018 03:52 PM, Nuno Lopes wrote: > I can step in, if that's ok with you. > Nuno > > -----Original Message----- From: Philip Reames > Sent: Saturday, February 17, 2018 1:04 AM > To: Davide Italiano ; Nuno Lopes > Cc: llvm-dev > Subject: Re: [llvm-dev] Missing attribute inference cases > > Sure, but is anyone willing to mentor?  I don't have

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Reid Kleckner" <rnk at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, November 29, 2016 11:34:56 AM > Subject: Re: [llvm-dev] RFC: Add an "interposible" linkage

As mentioned in the Updated ThinLTO RFC ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), I am sending the symbol linkage and renaming required by ThinLTO as a separate RFC. It is included below. I've also attached the doc in pdf form, since the formatting (especially for the table at the end) may not come through in the copied text below well. Thanks! Teresa ThinLTO

Hi, On Wed, Jul 26, 2017 at 12:54 PM, Sean Silva <chisophugis at gmail.com> wrote: > The way I interpret Quentin's statement is something like: > > - Inlining turns an interprocedural problem into an intraprocedural problem > - Outlining turns an intraprocedural problem into an interprocedural problem > > Insofar as our intraprocedural analyses and transformations are

Hi, On Wed, Jul 26, 2017 at 10:10 AM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > No, I mean in terms of enabling other optimizations in the pipeline like > vectorizer. Outliner does not expose any of that. I have not made a lot of effort to understand the full discussion here (so what I say below may be off-base), but I think there are some cases where

Hi, List, As you may know, BCC of android makes use of LLVM's major components. Its LTO actually selects some optimizations of LLVM. I found it can not only use "-functionattrs". I must first use -argpromotion first, or I end up this error: Pass 'Deduce function attributes' is not initialized. Verify if there is a pass dependency cycle. Required Passes: bcc:

The LLVMAddFunctionAttr and LLVMRemoveFunctionAttr are busted: they actually set the return value's attributes, not the function's attributes. There seems to be no C API for actually setting the function attributes. LLVMGetFunctionAttr, however, does correctly return the function attributes, not the return value's attributes. There is no C API for getting the return value

Nick Lewycky wrote: > I was sure that I remember "opt -functionattrs" being taught to do this, > but I just tried it out and it doesn't. This is a missed optz'n > opportunity, testcase: > > @x = constant i32 0 > define void @foo() { > load i32* @x > ret void > } > > is only marked readonly when it should be readnone. Could

Thanks for the answer Nick. Now you got me on a chase through FunctionAttrs.cpp trying to find out what analysis passes "... which answers no to everything", means. :-) Garrison On Sep 10, 2011, at 13:52, Nick Lewycky wrote: > Nick Lewycky wrote: >> I was sure that I remember "opt -functionattrs" being taught to do this, >> but I just tried it out and it

> > This scares me a little for linkonce -- there's a minor change to > semantics if the importing module would have linked against a > *different* definition of the same symbol -- but I'm not really > sure it matters much. > > This should not be an issue in practice as it exists non thinLTO compilations too. For instance changing the optimization level of one module

On 2009-06-29 11:16, Wenzhi Tao wrote: > Hi, all > > According to the document "LLVM Alias Analysis Infrastructure", I > evaluated the AA performance by using the paramenters '-basicaa -ds-aa > -anders-aa'. The source code 'test.c' is listed as follow: > [...] > The whole process: > > llvm-gcc -emit-llvm -O0 -c test.c -o test.bc > > opt

Apologies for delayed joining of this discussion, but I had a few notes from this thread that I really wanted to chime in about. River, I don't mean to put you on the spot, but I do want to start on a semantic issue. In several places in the thread you used the words "we" and "our" to imply that you're not alone in writing this (which is totally fine), but your

Hi all, Below is a proposal for refining the way we communicate between the ThinLTO link step (the combined indexing step) and the backend processes that do the actual importing and other summary-based optimizations in a distributed backend process. Mehdi, let me know if this addresses your concerns. Peter, PTAL from the standpoint of any summary extensions needed for CFI and make sure they can