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

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Chandler Carruth" <chandlerc at google.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Friday, February 26, 2016 10:44:45 PM
> Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
> 
> ----- 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.

Although, as David just pointed out, PGO can help :-)

 -Hal

> 
> Thanks again,
> Hal
> 
> > My concern
> > is that it will be a substantial amount of work and require a
> > reasonable amount of testing and experimentation.
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory