llvm dev - Oct 2017 - Infinite loops with no side effects

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171027/fb29ab78/attachment.html>

On 10/27/2017 03:12 PM, Reid Kleckner 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.
Okay.

  -Hal

-- 
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/a8da6103/attachment.html>

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>

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>

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>