Finkel, Hal J. via llvm-dev
2016-Apr-19 00:09 UTC
[llvm-dev] Move InlineCost.cpp out of Analysis?
Sent from my Verizon Wireless 4G LTE DROID On Apr 18, 2016 6:48 PM, Xinliang David Li <xinliangli at gmail.com<mailto:xinliangli at gmail.com>> wrote:> > > > On Mon, Apr 18, 2016 at 4:43 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> ________________________________ >>> >>> From: "Xinliang David Li" <davidxl at google.com<mailto:davidxl at google.com>> >>> To: "Chandler Carruth" <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> >>> Cc: "Hal Finkel" <hfinkel at anl.gov<mailto:hfinkel at anl.gov>>, "via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>, "Mehdi Amini" <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> >>> Sent: Monday, April 18, 2016 6:38:32 PM >>> Subject: Re: [llvm-dev] Move InlineCost.cpp<http://InlineCost.cpp> out of Analysis? >>> >>> >>> >>> On Mon, Apr 18, 2016 at 3:59 PM, Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> wrote: >>>> >>>> On Mon, Apr 18, 2016 at 3:45 PM Xinliang David Li <davidxl at google.com<mailto:davidxl at google.com>> wrote: >>>>> >>>>> On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> wrote: >>>>>> >>>>>> On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>>> >>>>>>>> From: "Xinliang David Li" <davidxl at google.com<mailto:davidxl at google.com>> >>>>>>>> >>>>>>>> On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com<mailto: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 actually it is immutable -- i.e, no need for update. > >> >> I can understand function entry counts being readonly, > > > > Function entry counts are actually mutable -- inlining, cloning etc will need to update the entry count of the callee instance.Ah, good point. -Hal> >> >> but branch information within a function seems mutable. Is this also what you're talking about? > > > > Basically profile summary is program level information which won't be modified after it is created/read . > > David > >> >> >> -Hal >>> >>> >>> David >>> >> >> >> >> -- >> Hal Finkel >> Assistant Computational Scientist >> Leadership Computing Facility >> Argonne National Laboratory >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160419/770d168b/attachment.html>