[llvm-dev] Move InlineCost.cpp out of Analysis?

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Xinliang David Li" <davidxl at google.com>
> To: "Chandler Carruth" <chandlerc at gmail.com>
> Cc: "Hal Finkel" <hfinkel at anl.gov>, "via llvm-dev"
> <llvm-dev at lists.llvm.org>, "Mehdi Amini" <mehdi.amini at apple.com>
> Sent: Monday, April 18, 2016 6:38:32 PM
> Subject: Re: [llvm-dev] Move InlineCost.cpp out of Analysis?

> On Mon, Apr 18, 2016 at 3:59 PM, Chandler Carruth <
> chandlerc at gmail.com > wrote:

> > On Mon, Apr 18, 2016 at 3:45 PM Xinliang David Li <
> > davidxl at google.com > wrote:
> 

> > > On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth <
> > > chandlerc at gmail.com > wrote:
> > 
> 

> > > > On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel < hfinkel at anl.gov >
> > > > wrote:
> > > 
> > 
> 

> > > > > > From: "Xinliang David Li" < davidxl at google.com >
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <
> > > > > > mehdi.amini at apple.com
> > > > > > > wrote:
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > In the current case at stake: the issue is that we can't
> > > > > > > make
> > > > > > > the
> > > > > > > Analysis library using anything from the ProfileData
> > > > > > > library.
> > > > > > > Conceptually there is a problem IMO.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > Yes -- this is a very good point.
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > Independent of anything else, +1.
> > > > 
> > > 
> > 
> 

> > > > The design of ProfileData and reading profile information in
> > > > the
> > > > entire middle end had a really fundamental invariant that folks
> > > > seem
> > > > to have lost track of:
> > > 
> > 
> 
> > > Not sure about what you mean by 'lost track of'.
> > 
> 
> > I mean that we used to hold to these invariants but I think
> > recently
> > the code has started to not follow them as closely.
> 

> > > > a) There is exactly *one* way to get at profile information
> > > > from
> > > > general analyses and transforms: a dedicated analysis pass that
> > > > manages access to the profile info.
> > > 
> > 
> 
> > > This is not the case as of today.
> > 
> 
> > Again, my whole comment was that these are no longer being
> > correctly
> > followed.
> 

> > > BPI is a dedicated analysis pass to manage branch probability
> > > profile
> > > information, but this pass is only used in limited situations
> > > (e.g,
> > > for BFI, profile update in jump-threading etc) -- using it it
> > > requires more memory as well as incremental update interfaces.
> > > Many
> > > transformation passes simply skip it and directly access the meta
> > > data in IR.
> > 
> 
> > Can you be more specific?
> 

> > BPI and BFI are used in *many* places, and on an initial inspection
> > almost everywhere that accesses MD_prof directly appears to do so
> > in
> > order to *set* or *update* the profile information without doing
> > detailed analysis on it. Which seems fine with my outline of the
> > invariants?
> 

> See my reply to Hal.

> > > > Now, the original design only accounted for profile information
> > > > *within* a function body, clearly it needs to be extended to
> > > > support
> > > > intraprocedural information.
> > > 
> > 
> 
> > > Not sure what you mean. Profile data in general does not extend
> > > to
> > > IPA (we will reopen discussion on that soon), but profile summary
> > > is
> > > 'invariant'/readonly data, which should be available to IPA
> > > already.
> > 
> 
> > I don't know what you mean by "invariant" or readonly data here. I
> > think that whether or not the profile information is mutated
> > shouldn't influence the design invariants I described above.
> 
> I do not disagree with this. What I was saying is that the
> information can be made available to IPA in some form due to its
> readonly nature.
Can you please clarify what information you view as readonly? I can understand function entry counts being readonly, but branch information within a function seems mutable. Is this also what you're talking about? 

-Hal 

> David

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160418/907791eb/attachment.html>