← Home ← Back to /g/

Thread 106196795

27 posts 10 images /g/
Anonymous No.106196795 >>106197193 >>106197266 >>106197289 >>106205202 >>106205717 >>106206133
Peak Compiler Performance
You might not like it, but this is what peak compiler performance looks like.
Anonymous No.106197193 >>106205769 >>106205898
>>106196795 (OP)
so result of (int)isEven() not important?
Anonymous No.106197266 >>106197355
>>106196795 (OP)
what kind of FP retard write it like this?
Anonymous No.106197289 >>106197915 >>106205202
>>106196795 (OP)
LLVM's magic, I guess.
Anonymous No.106197355 >>106197744 >>106197915
>>106197266
It seems like a pattern-based optimization, which suggests they considered it common enough to implement directly into the compiler.
Anonymous No.106197744
>>106197355
It would make sense to optimize all recurrences to closed form expressions. This is a useful optimization in general. Then this iseven would fall out of that.
Anonymous No.106197915 >>106198057 >>106198877 >>106201593 >>106205202
>>106197289
>>106197355
Compiler retard here
It's induction variable simplification after tail call elimination.
The compiler converts the self-call into something like this during tail-call elimination:
bool isEven(unsigned int a)
{
bool res = true;
while(true)
{
if(a == 0)
{
return res;
}
a = a - 1;
res = !res;
}
}

Or, lowered:
bool isEven(unsigned int a)
{
bool res = true;

_start:
if(a == 0)
{
return res;
}
a = a - 1;
res = res ^ true;
goto _start;
}

Since the only definition of a within the loop are of the form "a = a - 1" it can be treated as an induction variable, and so the compiler can determine the number of loop iterations are equivalent to the value of a. from that you can derive the value of res in terms of a as a closed form and after that the loop can easily be eliminated.
Heavy hitter for this in LLVM is rewriteLoopExitValues: https://llvm.org/doxygen/LoopUtils_8cpp_source.html#l01549 it's called by the induction variable elimination pass. The variable is represented with a SCEV (SCalar EVolution) model, defined here: https://llvm.org/doxygen/ScalarEvolution_8cpp_source.html. Compiler's able to pretty quickly calculate the final value using this. Won't pretend to understand the code but you can read it if you want. We end up with:
bool isEven(unsigned int a) {
return (a & 1) == 0;
}

which compiles as shown
Anonymous No.106198057
>>106197915
>Since the only definition of a within the loop are of the form "a = a - 1" it can be treated as an induction variable, and so the compiler can determine the number of loop iterations are equivalent to the value of a. from that you can derive the value of res in terms of a as a closed form and after that the loop can easily be eliminated.
it require the formula: [do i times res = !res ] => [do i % 2 times res = !res]
Anonymous No.106198877 >>106199619 >>106203290
>>106197915
Thanks anon.
I still have yet to read my dragon book...
Is there any good book/resource you could recommend that actually looks at modern optimisation techniques?
Anonymous No.106199619 >>106199716 >>106208439
>>106198877
>optimizing isEven()
only braindead FPtards have imagination to write it non optimized
Anonymous No.106199716 >>106199935
>>106199619
i don't think anyone would write code like that it is just really cool to see what compilers can do. Stop with the negativity nigga
Anonymous No.106199935
>>106199716
shitup, AI slut
Anonymous No.106201560
whoa
that's kinda neat
compiler are smart
Anonymous No.106201593
>>106197915
makes sense, otherwise the tree would go forever
once you have the loop counter const it is straight forward
Anonymous No.106203290 >>106208439
>>106198877
Advanced Compiler Design and Implementation by Muchnick is the classic
Principles of Program Analysis is also good for the math backing however it's incredibly dense and requires a good theoretical background.
Read the SSA book. https://pfalcon.github.io/ssabook/latest/
Skip the lexing/parsing chapters in Dragon and start at Ch 6 if you're interested in optimization.
Anonymous No.106205202
>>106196795 (OP)
>>106197289
>>106197915
Damn, this shit is dumb
When would you ever not see the pattern as a human and avoid it in the first place?
Anonymous No.106205504
damn bro fr ong it's so cool how compiler removes your dogshit code and replaces it with what you should've written to begin with: i & 1.
Anonymous No.106205687
i love sufficiently smart compilers
Anonymous No.106205717
>>106196795 (OP)
Next I'll inline this function and fold it for known constants
Anonymous No.106205769
>>106197193
explain
Anonymous No.106205898
>>106197193
the power of UB
Anonymous No.106206133
>>106196795 (OP)
Functional programming and its consequences have been a disaster for the human race
Anonymous No.106206370 >>106206398 >>106206454
this is retarded. this isn't optimization. this is different program that may (or may not) produce same output
Anonymous No.106206398
>>106206370
when does it not produce the same output?
Anonymous No.106206454
>>106206370
>t. doesn’t low level programming
Anonymous No.106208406
>he doesn't tip his compiler developer
Anonymous No.106208439
>>106199619
I'm sure you're able to think of a situation where such optimisations would be very useful.

>>106203290
Thanks anon.
>Skip the lexing/parsing chapters in Dragon and start at Ch 6 if you're interested in optimization.
My main interest is optimisation but lexing/parsing is of course still part of compilers so I will still work through them. After I finish EOPL of course.