[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 7:26 PM Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Chandler Carruth" <chandlerc at google.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>, "Sanjoy Das" <
> sanjoy at playingwithpointers.com>
> > 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>
> > Sent: Friday, February 26, 2016 9:01:48 PM
> > Subject: Re: [llvm-dev] Possible soundness issue with
> available_externally (split from "RFC: Add guard intrinsics")
> >
> >
> > I think this will have a much higher cost than my proposal to
> > constrain how we deduce function attributes (which still fixes
> > Sanjoy's latest example).
> >
> > Specifically, I think this will force us to constrain far too many
> > transformations for the sake of code size in functions that we won't
> > inline. Even if we were never going to deduce function attributes
> > for anything in the function (because its big and reads and writes
> > everything), we'll still have to constrain our transformations just
> > because we *might* later deduce a function attribute that triggers
> > these kinds of bugs.
> >
> > Essentially, you're proposing to limit intraprocedural optimization
> > to when we can successfully to interprocedural optimization
> > ("privatization"), where I'm suggesting we limit interprocedural
> > optimization to leave intraprocedural optimization unconstrained.
> > Given the ratio of our optimizations (almost all are intra, very few
> > are inter), I'm much more comfortable with the latter.
>
> This is a good point; we can certainly (easily) delay the privatization
> decision until we modify any IPA-level function information (at which point
> we can either reject the attribute change (when optimizing for code size),
> or keep it locally (when optimizing for speed). Ideally, you'd want to
> delay this even further (until you knew the attribute information was
> used), but I'm not sure that's practical.
>
> Actually, what if instead of actually privatizing, we moved the function
> into a different comdat section named after some hash of the function body?
> That way, if all versions are actually optimized identically, we'll still
> only end up with one copy in the final executable. If this is technically
> possible, it seems like the best kind of solution.
>

This is how I want to do a revamped function merging anyways and it would
fall out naturally of that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160227/ccac77f5/attachment.html>