Re: Optimisation possibilities: current, future and enhancements

Am Thu, 25 Aug 2016 11:45:40 + schrieb Cauterite : > - if a function is pure and called with constexpr parameters, the > compiler could potentially execute that call in the CTFE engine > (automatically), as part of the constant-folding phase I guess. > Such a technique

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 19:51:02 UTC, Patrick Schluter wrote: On Friday, 26 August 2016 at 14:03:13 UTC, Meta wrote: On Friday, 26 August 2016 at 10:51:15 UTC, Johan Engelen wrote: On Thursday, 25 August 2016 at 14:42:28 UTC, Basile B. wrote: I'll add * create temporaries based on the

Re: Optimisation possibilities: current, future and enhancements

On 08/26/2016 10:48 PM, Patrick Schluter wrote: the function getN() is pure (but not const). How is it not const? It doesn't alter the object. setN is the non-const one.

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 20:35:13 UTC, ag0aep6g wrote: On 08/26/2016 10:09 PM, Patrick Schluter wrote: Yes. The optimisation of removing the second call is only possible if there is no access using the this pointer. The call to setN() (or any member function using the mutable this

Re: Optimisation possibilities: current, future and enhancements

On 08/26/2016 10:09 PM, Patrick Schluter wrote: Yes. The optimisation of removing the second call is only possible if there is no access using the this pointer. The call to setN() (or any member function using the mutable this pointer), will mandate the compiler to call getN() again. If setN

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 19:58:47 UTC, ag0aep6g wrote: On 08/26/2016 09:51 PM, Patrick Schluter wrote: On Friday, 26 August 2016 at 14:03:13 UTC, Meta wrote: [...] class Test { int n; void setN(int val) pure { n = val; } int getN() const pure {

Re: Optimisation possibilities: current, future and enhancements

On 08/26/2016 09:51 PM, Patrick Schluter wrote: On Friday, 26 August 2016 at 14:03:13 UTC, Meta wrote: [...] class Test { int n; void setN(int val) pure { n = val; } int getN() const pure { return n; } } getN() is not pure, simple as that (and an

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 17:52:36 UTC, Meta wrote: On Friday, 26 August 2016 at 14:12:24 UTC, Basile B. wrote: That's another story. Of course the optimization pass for this should check that **ALL** the calls to Test in a sub program (or in this scope if you want) are const... Which is

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 14:03:13 UTC, Meta wrote: On Friday, 26 August 2016 at 10:51:15 UTC, Johan Engelen wrote: On Thursday, 25 August 2016 at 14:42:28 UTC, Basile B. wrote: I'll add * create temporaries based on the const function attribute. Struct method constness (as in your

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 14:12:24 UTC, Basile B. wrote: On Friday, 26 August 2016 at 14:03:13 UTC, Meta wrote: On Friday, 26 August 2016 at 10:51:15 UTC, Johan Engelen wrote: On Thursday, 25 August 2016 at 14:42:28 UTC, Basile B. wrote: I'll add * create temporaries based on the const

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 14:12:24 UTC, Basile B. wrote: That's another story. Of course the optimization pass for this should check that **ALL** the calls to Test in a sub program (or in this scope if you want) are const... Which is not the case here. My point is that getN is strongly

Re: Optimisation possibilities: current, future and enhancements

On Fri, 26 Aug 2016 10:32:55 +, kink wrote: > Inlining and subsequent constant folding are only available if the > callee isn't an external. The optimizations being discussed are a result of purity guarantees that have nothing to do with inlining. The example showed constant folding as a

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 14:03:13 UTC, Meta wrote: On Friday, 26 August 2016 at 10:51:15 UTC, Johan Engelen wrote: On Thursday, 25 August 2016 at 14:42:28 UTC, Basile B. wrote: I'll add * create temporaries based on the const function attribute. Struct method constness (as in your

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 10:51:15 UTC, Johan Engelen wrote: On Thursday, 25 August 2016 at 14:42:28 UTC, Basile B. wrote: I'll add * create temporaries based on the const function attribute. Struct method constness (as in your example) does not mean that the return value is constant

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 14:42:28 UTC, Basile B. wrote: I'll add * create temporaries based on the const function attribute. Struct method constness (as in your example) does not mean that the return value is constant when calling it twice in a row. As pointed out by others, the

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 09:30:52 UTC, Timon Gehr wrote: Better performance is better even when it is not the primary concern. It's not the compiler's business to judge coding style It's free to choose not to implement complex optimizations just so that people get super duper performance

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 08:44:54 UTC, kink wrote: On Friday, 26 August 2016 at 05:50:52 UTC, Basile B. wrote: On Thursday, 25 August 2016 at 22:37:13 UTC, kinke wrote: On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote: From my perspective, the problem with this example isn't

Re: Optimisation possibilities: current, future and enhancements

On 26.08.2016 10:44, kink wrote: On Friday, 26 August 2016 at 05:50:52 UTC, Basile B. wrote: On Thursday, 25 August 2016 at 22:37:13 UTC, kinke wrote: On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote: From my perspective, the problem with this example isn't missed optimization

Re: Optimisation possibilities: current, future and enhancements

On Friday, 26 August 2016 at 05:50:52 UTC, Basile B. wrote: On Thursday, 25 August 2016 at 22:37:13 UTC, kinke wrote: On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote: From my perspective, the problem with this example isn't missed optimization potential. It's the code itself. Why

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 22:37:13 UTC, kinke wrote: On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote: From my perspective, the problem with this example isn't missed optimization potential. It's the code itself. Why waste implementation efforts for such optimizations, if that

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote: The problem here that the example is bad with too agressive optimizations because the CALLs are eliminated despite of no inlining. [...] int use(const(Foo) foo) { return foo.foo() + foo.foo(); } From my perspective, the

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 18:09:14 UTC, Cecil Ward wrote: On Thursday, 25 August 2016 at 18:07:14 UTC, Cecil Ward wrote: On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote: [...] I think that here the optimisation is only because LDC can “see” the text of the method. When

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 18:17:21 UTC, Cecil Ward wrote: On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: * special values of objects such zero, and one, so that that (x ⊛ zero) ≡ x, and that (zero ⊛ x) ≡ x (Should of course read (x ⊛ zero) ≡ zero, and that (one

Re: Optimisation possibilities: current, future and enhancements

On 08/25/2016 08:15 PM, Basile B. wrote: Here's a better code to illustrate the idea: °° interface Foo { int foo() const; } int use(const(Foo) foo) { return foo.foo() + foo.foo(); } °° And I'd expect this asm for a 'const optimization' in

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote: I found it hard to believe LDC generates such crappy code when Yes that's right, there was an error in my script! What I've posted is actually the asm without -O. Sure, Foo.foo() and use() could return a constant, but otherwise it

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: ... A useful phrase I saw today: “declaration of intent given by the programmer to the compiler”. Particular dream wish-list items of mine: some kind of mechanism that could express possible operator properties, classes

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote: I found it hard to believe LDC generates such crappy code when optimizing. These are my results using LDC master on Win64 (`ldc2 -O -release -output-s`): struct Foo { immutable _u = 8; int foo() const { return 8 *

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 18:07:14 UTC, Cecil Ward wrote: On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote: [...] I think that here the optimisation is only because LDC can “see” the text of the method. When expansion is not possible, that would be the real test. (Assuming

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 14:42:28 UTC, Basile B. wrote: On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: [...] I'll add * create temporaries based on the const function attribute. I don't know why but I believed that it was already the case. After disassembling a short

Re: Optimisation possibilities: current, future and enhancements

I found it hard to believe LDC generates such crappy code when optimizing. These are my results using LDC master on Win64 (`ldc2 -O -release -output-s`): struct Foo { immutable _u = 8; int foo() const { return 8 * _u; } } int use(ref const(Foo) foo) { return

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: I'm wondering if there are more opportunities in D for increased optimization in compilers that have not been mined yet. I'm specifically interested in the possibilities of D over and above what is possible in C and C++ because of

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: * Non-return-function marking, first in GCC and then in C itself. (iirc. And in C++?) Maybe it could be implemented as int blah() out(result) { assert(0); } body { } instead of marking the function itself.

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 12:27:20 UTC, Cecil Ward wrote: When I said GCC/LLVM I meant GDC(GNU D Compiler)/LDC(LLVM D Compiler). I might have caused some confusion there.

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 11:55:08 UTC, Cauterite wrote: On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: * the GCC "__builtin_expect()" Instead of adding individual micro-optimisation features like this, I'd be more interested in the potential for profile-guided

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: * the GCC "__builtin_expect()" Instead of adding individual micro-optimisation features like this, I'd be more interested in the potential for profile-guided optimisation (which *ideally* can make these micro-optimisation

Re: Optimisation possibilities: current, future and enhancements

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: I long for the day we ditch signalling NaNs — they would surely prevent `-ffast-math` from being effective. I have a couple more ideas, here's one of them: - if a function is pure and called with constexpr parameters, the