Jump to page: 1 2
Thread overview
[Issue 22277] removing strongly pure function calls is an incorrect optimization
Sep 04, 2021
Dlang Bot
Sep 06, 2021
RazvanN
Sep 14, 2021
Max Samukha
Sep 15, 2021
Luís Ferreira
Sep 15, 2021
Max Samukha
Sep 15, 2021
João Lourenço
Sep 22, 2021
Max Samukha
Oct 28, 2021
Ate Eskola
Oct 28, 2021
Dennis
Oct 28, 2021
Ate Eskola
Nov 04, 2021
timon.gehr@gmx.ch
Nov 04, 2021
Ate Eskola
Nov 04, 2021
timon.gehr@gmx.ch
Nov 13, 2021
Dlang Bot
September 04, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #1 from Dlang Bot <dlang-bot@dlang.rocks> ---
@dkorpel created dlang/dmd pull request #13047 "Fix issue 22277 - removing strongly pure function calls is an incorrect optimization" fixing this issue:

- fix issue 22277 - removing strongly pure function calls is an incorrect optimization

https://github.com/dlang/dmd/pull/13047

--
September 06, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #2 from RazvanN <razvan.nitu1305@gmail.com> ---
I agree that this is a problem, but if this is fixed, why do we even have `pure` anymore? I think that the fix should be the other way around: asserts should be forbidden in pure functions (except if the function is @noreturn).

--
September 13, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com

--- Comment #3 from Andrei Alexandrescu <andrei@erdani.com> ---
This has been discussed a number of times in the past. One proposal was that `void` pure functions must always be called - the compiler must assume since they're `void` and pure (a contradiction) then they do something surreptitious and must not be elided.

--
September 14, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

Max Samukha <maxsamukha@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxsamukha@gmail.com

--- Comment #4 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Andrei Alexandrescu from comment #3)
> This has been discussed a number of times in the past. One proposal was that `void` pure functions must always be called - the compiler must assume since they're `void` and pure (a contradiction) then they do something surreptitious and must not be elided.

Could you explain why void and pure is a contradiction?

--
September 14, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

--- Comment #5 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to Max Samukha from comment #4)
> (In reply to Andrei Alexandrescu from comment #3)
> > This has been discussed a number of times in the past. One proposal was that `void` pure functions must always be called - the compiler must assume since they're `void` and pure (a contradiction) then they do something surreptitious and must not be elided.
> 
> Could you explain why void and pure is a contradiction?

`void` implies "all of my work is done via side effects" and pure implies "there is no side effect". In D we have the relaxation of weak purity that makes things less clear cut. In the case of `free` in the example the parameter is `immutable` which makes the function strongly pure; a strongly pure function that returns `void` has no way to effect anything within the definition of the language.

--
September 15, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

Luís Ferreira <lsferreira169@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lsferreira169@gmail.com

--- Comment #6 from Luís Ferreira <lsferreira169@gmail.com> ---
Fake pure functions are a special case here, but I agree that functions that halt the program with `assert(0)` is an issue here.

--
September 15, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

--- Comment #7 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Andrei Alexandrescu from comment #5)

> > 
> > Could you explain why void and pure is a contradiction?
> 
> `void` implies "all of my work is done via side effects"

I am not sure this premise is true. A function returning 'void' may do no work at all or do work without observable side effects. I need to think more about this, thank you.

> and pure implies
> "there is no side effect". In D we have the relaxation of weak purity that
> makes things less clear cut. In the case of `free` in the example the
> parameter is `immutable` which makes the function strongly pure; a strongly
> pure function that returns `void` has no way to effect anything within the
> definition of the language.

Yes, I am familiar with D's concepts of purity.

--
September 15, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

João Lourenço <jlourenco5691@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlourenco5691@gmail.com

--- Comment #8 from João Lourenço <jlourenco5691@gmail.com> ---
> I am not sure this premise is true. A function returning 'void' may do no work at all or do work without observable side effects. I need to think more about this, thank you.

If the function is strongly pure that statement is correct. To do some work, then it needs to be impure, or in the case of D, weakly pure. An example is all the pure void functions that mess around with values of `this`.

--
September 22, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

--- Comment #9 from Max Samukha <maxsamukha@gmail.com> ---


(In reply to João Lourenço from comment #8)
> > I am not sure this premise is true. A function returning 'void' may do no work at all or do work without observable side effects. I need to think more about this, thank you.
> 
> If the function is strongly pure that statement is correct. To do some work, then it needs to be impure, or in the case of D, weakly pure. An example is all the pure void functions that mess around with values of `this`.

It's not correct at least in one case: when the function doesn't do work at all. 'void foo() {}' is a strongly pure function returning the value of the unit type. And it's not even useless - it would've found its use in generic code if D's unit type wasn't broken in other respects.

Whether encapsulated side effects qualify to be called "work", I don't know.

--
October 28, 2021
https://issues.dlang.org/show_bug.cgi?id=22277

Ate Eskola <Ajieskola@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Ajieskola@gmail.com
           Severity|normal                      |critical

--- Comment #10 from Ate Eskola <Ajieskola@gmail.com> ---
I think the compiler is allowed to elide a `free` call implemented like that. First, you're compiling in release mode, debug statements are supposed to be skipped even if the function is called. Second, `debug` statements are not considered to be side effects that require executing the function - that's what allows them to reside in `pure`!. They are required to be executed only if the surrounding scope is executed.

But the `panic` and `assertPositive` functions ought to be executed. If you had consecutive calls to `assertPositive` with the same argument, the compiler is free to remove the tailing calls, but not the first one. And that ought to happen regardless of the return value type.

Increasing severity, as this thing may silently add bugs to the compiled code.

--
« First   ‹ Prev
1 2