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

[Sanjoy Das via llvm-dev]

On Tue, Feb 23, 2016 at 3:34 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 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.

But we also have more aggressive opts like IPSCCP that don't fall in
either category.

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

Yes, I think I see what you are going for (what I thought was (2)/(3)
is really just (3) in your scheme).  Practically, I don't think it is
useful to differentiate between (1) and (2).  To get (2)-like
behavior, the frontend can always emit a function definition without
any pre-defined attributes; annotated with (1)'s linkage type
(available_externally or linkonce_odr).

-- Sanjoy