[llvm-dev] Infinite loops with no side effects

[Hal Finkel via llvm-dev]

On 10/27/2017 07:01 PM, Dan Gohman wrote:
>
>
> On Fri, Oct 27, 2017 at 1:12 PM, Reid Kleckner <rnk at google.com 
> <mailto:rnk at google.com>> wrote:
>
>     On Fri, Oct 27, 2017 at 1:08 PM, Hal Finkel <hfinkel at anl.gov
>     <mailto:hfinkel at anl.gov>> wrote:
>
>         On 10/27/2017 02:51 PM, Reid Kleckner wrote:
>
>>         Personally, I don't like the side effect intrinsic.
>
>         Understood. I also don't like the fact that it will clutter
>         the IR in many cases.
>
>>         It will pollute all the IR generated by non-C frontends. What
>>         most of these frontends really want is just a switch to
>>         disable a targeted set of optimizations.
>>
>>         One thing I like about the function attribute idea is that
>>         it's conservatively correct to discard it when doing
>>         cross-language inlining. It just becomes something that
>>         C-family frontends need to remember to add to enable their
>>         special-case language rules, rather than something that non-C
>>         languages need to think about. Similar to the 'access',
>>         builtin vs nonbuiltin discussion happening in parallel, the
>>         attribute enables the optimization, rather than inhibiting it.
>
>         As I said below, a function attribute is insufficient. It
>         needs to be something we can mark per loop. This is needed to
>         correctly model C. The sideeffect intrinsic is the best
>         proposal I've seen so far.
>
>
>     Maybe we should do both? If the intrinsic is a special case, that
>     seems fine. It's cheap.
>
>
> As I understand it, part of the function attribute proposal is to 
> change the default semantics of LLVM IR to have defined behavior on 
> infinite loops, and then add an attribute opting into potential-UB. So 
> if we do that, then the role of @llvm.sideeffect becomes a little 
> subtle -- it'd be a way for a frontend for a language like C to opt 
> into potential-UB for a function, but then opt out for individual 
> loops in that function. Is that what you're proposing? If so, I'm ok 
> taking that route.

That's my understanding of the proposal.

  -Hal

>
> Dan
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171027/6ae1f25c/attachment.html>