Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Will It Optimize? See how well you can anticipate gcc's optimizer (2010)

ridiculousfish.com

Post reply on HN
Print view View original

1–10 of 34 posts

Re: Will It Optimize? See how well you can anticipate gcc's optimizer (2010)

#2

Post by LeafStorm »

This reminds me of something my assembly instructor said in class once (paraphrased):

"Once, I was interested in finding out how a C compiler would handle the div instruction. So, I opened up my editor, and wrote this C program:

    void main () {
        printf("%f", 14.0 / 3.0);
    }
I compiled it, and took a look at the generated assembly. How many div instructions do you think it used?

[Various guesses, mostly "one."]

The correct answer is "zero." The compiler figured it out at compile time, and put a constant in instead. So, I decided to put it in a function:

    float divide (float a, float b) {
        return a / b;
    }
    
    void main () {
        printf("%f", divide(a, b));
    }
Guess what happened next.

[Various guesses.]

The f--king compiler optimized it out again!"

Re: Will It Optimize? See how well you can anticipate gcc's optimizer (2010)

#3

Post by praptak »

I did some similar experiments myself a long time ago. Something mildly surprising for me at that time was that this got optimized to a single roll instruction:

    uint32_t roll(uint32_t const x) {
        return (x > 17);
    }
I haven't managed to make GCC generate a non-constant roll (i.e. (x > (32-c)) ), probably because it couldn't infer that c is in the [0,31] range.

Re: Will It Optimize? See how well you can anticipate gcc's optimizer (2010)

#4

Post by JshWright »

LeafStorm wrote: post #2

This reminds me of something my assembly instructor said in class once (paraphrased): "Once, I was interested in finding out how a C compiler would handle the div instruction. So, I opened up my editor, and wrote this C program: void main () { printf("%f", 14.0 / 3.0); } I compiled it, and took a look at the generated assembly. How many div instructions do you think it used? [Various guesses, mostly "one."] The corre…

I don't spend a lot of time looking at complier outputs, but the optimization is quite obvious in the first case. I don't have a clue how it would optimize it out in the second case though...

Re: Will It Optimize? See how well you can anticipate gcc's optimizer (2010)

#5

Post by nemetroid »

JshWright wrote: post #4
LeafStorm wrote: post #2

This reminds me of something my assembly instructor said in class once (paraphrased): "Once, I was interested in finding out how a C compiler would handle the div instruction. So, I opened up my editor, and wrote this C program: void main () { printf("%f", 14.0 / 3.0); } I compiled it, and took a look at the generated assembly. How many div instructions do you think it used? [Various guesses, mostly "one."] The corre…

I don't spend a lot of time looking at complier outputs, but the optimization is quite obvious in the first case. I don't have a clue how it would optimize it out in the second case though...

I think LeafStorm meant to put some constants in the divide call.

Re: Will It Optimize? See how well you can anticipate gcc's optimizer (2010)

#6

Post by praptak »

JshWright wrote: post #4
LeafStorm wrote: post #2

This reminds me of something my assembly instructor said in class once (paraphrased): "Once, I was interested in finding out how a C compiler would handle the div instruction. So, I opened up my editor, and wrote this C program: void main () { printf("%f", 14.0 / 3.0); } I compiled it, and took a look at the generated assembly. How many div instructions do you think it used? [Various guesses, mostly "one."] The corre…

I don't spend a lot of time looking at complier outputs, but the optimization is quite obvious in the first case. I don't have a clue how it would optimize it out in the second case though...

I believe the second case is quite obvious too, with function inlining (assuming that GP post just forgot to define a and b as constants.)

Re: Will It Optimize? See how well you can anticipate gcc's optimizer (2010)

#8

Post by a1k0n »

octo_t wrote: post #7

I am surprised at number 3, I would have thought that it would be optimised to x Edit: No. 5 explains why.

Not really; there's no rounding problem with x random aside: gcc usually uses the LEA instruction for this sort of thing, which lets you compute any combination of {1,2,4,8} * x + y + n in one cycle where x and y are registers and n is a constant number. So even with the LEA instruction you can use either lea eax, [eax*2] or lea eax, [eax+eax] to compute this. And so on. I think add eax, eax is most likely what it does though.

Re: Will It Optimize? See how well you can anticipate gcc's optimizer (2010)

#10

Post by Jabbles »

praptak wrote: post #3

I did some similar experiments myself a long time ago. Something mildly surprising for me at that time was that this got optimized to a single roll instruction: uint32_t roll(uint32_t const x) { return (x > 17); } I haven't managed to make GCC generate a non-constant roll (i.e. (x > (32-c)) ), probably because it couldn't infer that c is in the [0,31] range.

If c were outside that range, the result would be undefined, and the compiler would not need to consider that possibility.
Post reply on HN