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

[Sanjoy Das via llvm-dev]

The "introduce a side exit intrinsic" part of the plan is out for
review: http://reviews.llvm.org/D17732  (it does not require us to
solve the issue with linkage / interposability).

I decided to not call it a side_exit, since "side exit" can be
confused to mean "side exit from a superblock".

On Tue, Feb 23, 2016 at 3:59 PM, Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
> 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



-- 
Sanjoy Das
http://playingwithpointers.com