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

[Hal Finkel via llvm-dev]

----- 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.

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