[llvm-dev] RFC: Add guard intrinsics to LLVM

[Chandler Carruth via llvm-dev]

On Tue, Feb 23, 2016 at 3:07 PM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> On Tue, Feb 23, 2016 at 10:55 AM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
> >> Part of the challenge here is to specify the attribute in a way that
> >> allows inlining, but not IPA without inlining.  In fact, maybe it is
> >> best to not call it "interposable" at all?
> >
> >
> > Yea, this is something *very* different from interposable. GCC and other
> > compilers that work to support symbol interposition make specific
> efforts to
> > not inline them in specific ways (that frankly I don't fully understand,
> as
> > it doesn't seem to be always which is what the definition of interposable
> > indicates to me...).
>
> Sure, not calling it interposable is fine for me.  Credit where credit
> is due: Philip had warned me about this exact thing offline (that the
> term "interposable" is already taken).
>
> >> In other words, opt refined the semantics of @foo() (i.e. reduced the
> >> set of behaviors it may have) in ways that would make later
> >> optimizations invalid if we de-refine the implementation of @foo().
> >>
> >> Given this, I'd say we don't need a new attribute / linkage type, and
> >> can add our restriction to the available_externally linkage.
> >
> >
> > Interesting example, I agree it seems quite broken. Even more
> interesting, I
> > can't see anything we do in LLVM that prevents this from breaking
> > essentially everywhere. =[[[[[[
> >
> > link_once and link_once_odr at least seem equally broken because we don't
> > put the caller and callee into a single comdat or anything to ensure that
> > the optimized one is selected at link time.
> >
> > But there are also multiple different kinds of overriding we should think
> > about:
> >
> > 1) Can the definition get replaced at link time (or at runtime via an
> > interpreter) with a differently *optimized* variant stemming from the
> same
> > definition (thus it has the same behavior but not the same refinement).
> This
> > is the "ODR" guarantee in some linkages (and vaguely implied for
> > available_externally)
> >
> > 2) Can the definition get replaced at link time (or at runtime via an
> > interpreter) with a function that has fundamentally different behavior
> >
> > 3) To support replacing the definition, the call edge must be preserved.
>
> I'm working under context of a optimizer that does not know if its
> input has been previously optimized or if its input is "raw" IR.
> Realistically, I'd say deviating LLVM from this will be painful.
>

I'm not suggesting that either. I think there is a happy middle ground, but
I'm probably not explaining it very effectively, sorry. Lemme just try
again.

There are two conceptually separable aspects of IPO as it is commonly
performed within LLVM. One is to use attributes on a function to optimize
callers. The second is to use the definition of a function to deduce more
refined attributes.

This separation is what I was trying to draw attention to between (1) and
(2) above. My idea is that with (1) it remains fine to optimize callers
based on a function's attributes, but not to deduce more refined
attributes. But with (2) I don't think you can do either.

I think (3) differs from both (1) and (2) because in some cases the
restrictions only remain *if* the call edge remains. If you nuke (or
rename) the call edge, the restrictions go away completely. In other cases
though (my (3) example), the compiler is required to leave that exact call
edge in place.

Currently, we clearly don't actually separate these conceptual sides of
IPO. We have a very all-or-nothing approach instead. So maybe this
distinction isn't interesting. But hopefully it explains how I'm thinking
of it. And because frontends can often directly specify *some* attributes
that we know a-priori, it doesn't seem a vacuous distinction to me in
theory.

Does that explain things any better?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/d38d49ee/attachment.html>