[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")

[Chandler Carruth via llvm-dev]

On Fri, Feb 26, 2016 at 8:44 PM Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Chandler Carruth" <chandlerc at google.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" <
> listmail at philipreames.com>, "Duncan P. N. Exon Smith"
> > <dexonsmith at apple.com>, "Xinliang David Li" <xinliangli at gmail.com>,
> "Sanjoy Das" <sanjoy at playingwithpointers.com>
> > Sent: Friday, February 26, 2016 10:30:13 PM
> > Subject: Re: [llvm-dev] Possible soundness issue with
> available_externally (split from "RFC: Add guard intrinsics")
> >
> >
> >
> >
> > On Fri, Feb 26, 2016 at 8:15 PM Hal Finkel < hfinkel at anl.gov > wrote:
> >
> >
> >
> > Can you explain your concerns about reliability? My idea is that we
> > have a kind of delayed-name comdat section attribute that says that
> > the name of the comdat section into which the function will be
> > placed will be based on the hash of the contents (which should
> > probably be the pre-isel IR-level contexts plus perhaps the other
> > state that might affect backend optimization). Maybe just using the
> > MI-level function contents will work too. It seems like this should
> > be "perfect". I don't see the circumstances why function definitions
> > optimized under identical optimization settings should differ in
> > this sense.
> >
> >
> >
> > Ok, let's consider Sanjoy's latest post.
> >
>
> Indeed, a great example. His point is well taken, this is not strictly
> related to optimization level.
>
> >
> > I think we could end up with this routine in N different modules with
> > slightly different amounts of information in each. Each of these in
> > turn could cause us to deduce a slightly different set of
> > attributes, and thus compute a different hash.
> >
> > Now, certainly, there are a small number of variants here. Two, maybe
> > three. But this could in the worst case cause us to have two copies
> > of a *huge* number of functions.
> >
> > My concern here is not that this is a *theoretically* hard problem to
> > solve. I think there are good techniques to handle this.
>
> It seems like, by definition, the information necessary to control the
> number of variants is not locally available. Controlling this by some
> global setting (opt for size vs. opt for speed) seems easy. Otherwise, I
> don't understand what you're thinking.
>

I'm not speaking of controlling the variants, but of choosing appropriate
thresholds for the potential size growth.

And yes, one input would obviously PGO, but there are others I suspect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160227/cbd9cf42/attachment.html>