[llvm-dev] Infinite loops with no side effects

[Dan Gohman via llvm-dev]

On Fri, Oct 27, 2017 at 1:12 PM, Reid Kleckner <rnk at google.com> wrote:

> On Fri, Oct 27, 2017 at 1:08 PM, Hal Finkel <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.

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