[llvm-dev] Infinite loops with no side effects

[Reid Kleckner via llvm-dev]

On Fri, Oct 27, 2017 at 5:01 PM, Dan Gohman <sunfish at mozilla.com> wrote:

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

Yep!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171030/09ed3ef0/attachment.html>