Why is this call to a pure function with a string literal argument not optimized to a constant value?

I have a simple function which counts the letter t in a string:

#include <stdio.h>

#include <string.h>



static int count_t_letters(const char *t) {

    int r;



    r = 0;

    while(*t) {

        if(*t == 't') {

            ++r;

        }



        ++t;

    }



    return r;

}



int main() {

    printf("%i", count_t_letters("test"));

}

here's the optimization I was expecting:

int main() {

    printf("%i", 2);

}

Why is this simple function not optimized like I expected in neither gcc nor clang? (godbolt)

What I figured out so far:

Simple functions with integer pointer arguments are optimized to a constant
(godbolt)

Using C++ with a constexpr enables this optimization (godbolt)

Clang is able to do such an optimization if there is no ++t after the if (godbolt)

edited Jan 1 at 10:43

asked Dec 31 '18 at 15:15

Julius

433211

2

like expected Is there a standard saying something about expected?

– tilz0R
Dec 31 '18 at 15:32

5

This is not a language-lawyer question. It is related to quality of implementation of one compiler, not to the C language.

– Peter
Dec 31 '18 at 15:36

1

...although strlen with a literal argument is likely to be reduced to a constant.

– rici
Dec 31 '18 at 16:31

8

interesting... if you a normal loop over with strlen and index access then it is optimized away by both gcc and clang: godbolt.org/z/9CCOBz

– bolov
Dec 31 '18 at 17:00

1

@phuclv even marking if as such (__attribute__((pure))) doesn't affect the codegen, at least for gcc.

– Matteo Italia
Jan 3 at 6:25

|
show 6 more comments

I have a simple function which counts the letter t in a string:

#include <stdio.h>

#include <string.h>



static int count_t_letters(const char *t) {

    int r;



    r = 0;

    while(*t) {

        if(*t == 't') {

            ++r;

        }



        ++t;

    }



    return r;

}



int main() {

    printf("%i", count_t_letters("test"));

}

here's the optimization I was expecting:

int main() {

    printf("%i", 2);

}

Why is this simple function not optimized like I expected in neither gcc nor clang? (godbolt)

What I figured out so far:

Simple functions with integer pointer arguments are optimized to a constant
(godbolt)

Using C++ with a constexpr enables this optimization (godbolt)

Clang is able to do such an optimization if there is no ++t after the if (godbolt)

edited Jan 1 at 10:43

asked Dec 31 '18 at 15:15

Julius

433211

2

like expected Is there a standard saying something about expected?

– tilz0R
Dec 31 '18 at 15:32

5

This is not a language-lawyer question. It is related to quality of implementation of one compiler, not to the C language.

– Peter
Dec 31 '18 at 15:36

1

...although strlen with a literal argument is likely to be reduced to a constant.

– rici
Dec 31 '18 at 16:31

8

interesting... if you a normal loop over with strlen and index access then it is optimized away by both gcc and clang: godbolt.org/z/9CCOBz

– bolov
Dec 31 '18 at 17:00

1

@phuclv even marking if as such (__attribute__((pure))) doesn't affect the codegen, at least for gcc.

– Matteo Italia
Jan 3 at 6:25

|
show 6 more comments

I have a simple function which counts the letter t in a string:

#include <stdio.h>

#include <string.h>



static int count_t_letters(const char *t) {

    int r;



    r = 0;

    while(*t) {

        if(*t == 't') {

            ++r;

        }



        ++t;

    }



    return r;

}



int main() {

    printf("%i", count_t_letters("test"));

}

here's the optimization I was expecting:

int main() {

    printf("%i", 2);

}

Why is this simple function not optimized like I expected in neither gcc nor clang? (godbolt)

What I figured out so far:

Simple functions with integer pointer arguments are optimized to a constant
(godbolt)

Using C++ with a constexpr enables this optimization (godbolt)

Clang is able to do such an optimization if there is no ++t after the if (godbolt)

edited Jan 1 at 10:43

asked Dec 31 '18 at 15:15

Julius

433211

I have a simple function which counts the letter t in a string:

#include <stdio.h>

#include <string.h>



static int count_t_letters(const char *t) {

    int r;



    r = 0;

    while(*t) {

        if(*t == 't') {

            ++r;

        }



        ++t;

    }



    return r;

}



int main() {

    printf("%i", count_t_letters("test"));

}

here's the optimization I was expecting:

int main() {

    printf("%i", 2);

}

Why is this simple function not optimized like I expected in neither gcc nor clang? (godbolt)

What I figured out so far:

Simple functions with integer pointer arguments are optimized to a constant
(godbolt)

Using C++ with a constexpr enables this optimization (godbolt)

Clang is able to do such an optimization if there is no ++t after the if (godbolt)

c gcc clang compiler-optimization c11

edited Jan 1 at 10:43

asked Dec 31 '18 at 15:15

Julius

433211

edited Jan 1 at 10:43

asked Dec 31 '18 at 15:15

Julius

433211

edited Jan 1 at 10:43

asked Dec 31 '18 at 15:15

Julius

433211

asked Dec 31 '18 at 15:15

Julius

433211

asked Dec 31 '18 at 15:15

Julius

433211

2

like expected Is there a standard saying something about expected?

– tilz0R
Dec 31 '18 at 15:32

5

This is not a language-lawyer question. It is related to quality of implementation of one compiler, not to the C language.

– Peter
Dec 31 '18 at 15:36

1

...although strlen with a literal argument is likely to be reduced to a constant.

– rici
Dec 31 '18 at 16:31

8

interesting... if you a normal loop over with strlen and index access then it is optimized away by both gcc and clang: godbolt.org/z/9CCOBz

– bolov
Dec 31 '18 at 17:00

1

@phuclv even marking if as such (__attribute__((pure))) doesn't affect the codegen, at least for gcc.

– Matteo Italia
Jan 3 at 6:25

|
show 6 more comments

2

like expected Is there a standard saying something about expected?

– tilz0R
Dec 31 '18 at 15:32

5

This is not a language-lawyer question. It is related to quality of implementation of one compiler, not to the C language.

– Peter
Dec 31 '18 at 15:36

1

...although strlen with a literal argument is likely to be reduced to a constant.

– rici
Dec 31 '18 at 16:31

8

interesting... if you a normal loop over with strlen and index access then it is optimized away by both gcc and clang: godbolt.org/z/9CCOBz

– bolov
Dec 31 '18 at 17:00

1

@phuclv even marking if as such (__attribute__((pure))) doesn't affect the codegen, at least for gcc.

– Matteo Italia
Jan 3 at 6:25

like expected Is there a standard saying something about expected?

– tilz0R
Dec 31 '18 at 15:32

This is not a language-lawyer question. It is related to quality of implementation of one compiler, not to the C language.

– Peter
Dec 31 '18 at 15:36

...although strlen with a literal argument is likely to be reduced to a constant.

– rici
Dec 31 '18 at 16:31

interesting... if you a normal loop over with strlen and index access then it is optimized away by both gcc and clang: godbolt.org/z/9CCOBz

– bolov
Dec 31 '18 at 17:00

@phuclv even marking if as such (__attribute__((pure))) doesn't affect the codegen, at least for gcc.

– Matteo Italia
Jan 3 at 6:25

|
show 6 more comments

1 Answer
1

active

oldest

votes

Because you're creating side effects by modifying the pointer.

If instead of incrementing t you simply use a normal index int and increment that instead, then gcc has no trouble optimizing it as you desire.

Modifying the pointer has side effects.

Another way, simply make a copy of the pointer, and modify the copy. Again it optimizes.

answered Jan 2 at 23:18

RubyPanther

113

There's no conceptual difference between incrementing the pointer and incrementing an index - both are local variables, whose modifications aren't seen anywhere outside the function.

– Matteo Italia
Jan 2 at 23:32

2

Can you give a godbolt link demonstrating that "make a copy of the point, and modify the copy" optimizes this way? I can't reproduce that.

– Rob Napier
Jan 3 at 0:13

Thanks for your answer! Could you elaborate on those side effects? Somehow I can't figure out any way to make this optimization to happen through a copied pointer (godbolt - tested gcc and clang)

– Julius
Jan 3 at 9:22

That site's javascript doesn't let me paste out from there, so that isn't useful to me. If you make a gist at github though I'd be happy to compile it in gcc to verify.

– RubyPanther
Jan 4 at 5:19

I tested in gcc before posting my answer, I have no idea about clang optimizations. I agree with Matteo that there isn't a conceptual difference; rather, the compiler implementation is such that it doesn't do the work to tell that it is the same. Only when you isolate the changes to the function's stack frame does is it confident that the pointer doesn't get changed somewhere else.

– RubyPanther
Jan 4 at 5:23

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53988910%2fwhy-is-this-call-to-a-pure-function-with-a-string-literal-argument-not-optimized%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

Because you're creating side effects by modifying the pointer.

If instead of incrementing t you simply use a normal index int and increment that instead, then gcc has no trouble optimizing it as you desire.

Modifying the pointer has side effects.

Another way, simply make a copy of the pointer, and modify the copy. Again it optimizes.

answered Jan 2 at 23:18

RubyPanther

113

There's no conceptual difference between incrementing the pointer and incrementing an index - both are local variables, whose modifications aren't seen anywhere outside the function.

– Matteo Italia
Jan 2 at 23:32

2

Can you give a godbolt link demonstrating that "make a copy of the point, and modify the copy" optimizes this way? I can't reproduce that.

– Rob Napier
Jan 3 at 0:13

Thanks for your answer! Could you elaborate on those side effects? Somehow I can't figure out any way to make this optimization to happen through a copied pointer (godbolt - tested gcc and clang)

– Julius
Jan 3 at 9:22

That site's javascript doesn't let me paste out from there, so that isn't useful to me. If you make a gist at github though I'd be happy to compile it in gcc to verify.

– RubyPanther
Jan 4 at 5:19

I tested in gcc before posting my answer, I have no idea about clang optimizations. I agree with Matteo that there isn't a conceptual difference; rather, the compiler implementation is such that it doesn't do the work to tell that it is the same. Only when you isolate the changes to the function's stack frame does is it confident that the pointer doesn't get changed somewhere else.

– RubyPanther
Jan 4 at 5:23

add a comment |

Because you're creating side effects by modifying the pointer.

If instead of incrementing t you simply use a normal index int and increment that instead, then gcc has no trouble optimizing it as you desire.

Modifying the pointer has side effects.

Another way, simply make a copy of the pointer, and modify the copy. Again it optimizes.

answered Jan 2 at 23:18

RubyPanther

113

There's no conceptual difference between incrementing the pointer and incrementing an index - both are local variables, whose modifications aren't seen anywhere outside the function.

– Matteo Italia
Jan 2 at 23:32

2

Can you give a godbolt link demonstrating that "make a copy of the point, and modify the copy" optimizes this way? I can't reproduce that.

– Rob Napier
Jan 3 at 0:13

Thanks for your answer! Could you elaborate on those side effects? Somehow I can't figure out any way to make this optimization to happen through a copied pointer (godbolt - tested gcc and clang)

– Julius
Jan 3 at 9:22

That site's javascript doesn't let me paste out from there, so that isn't useful to me. If you make a gist at github though I'd be happy to compile it in gcc to verify.

– RubyPanther
Jan 4 at 5:19

I tested in gcc before posting my answer, I have no idea about clang optimizations. I agree with Matteo that there isn't a conceptual difference; rather, the compiler implementation is such that it doesn't do the work to tell that it is the same. Only when you isolate the changes to the function's stack frame does is it confident that the pointer doesn't get changed somewhere else.

– RubyPanther
Jan 4 at 5:23

add a comment |

Because you're creating side effects by modifying the pointer.

If instead of incrementing t you simply use a normal index int and increment that instead, then gcc has no trouble optimizing it as you desire.

Modifying the pointer has side effects.

Another way, simply make a copy of the pointer, and modify the copy. Again it optimizes.

answered Jan 2 at 23:18

RubyPanther

113

Because you're creating side effects by modifying the pointer.

If instead of incrementing t you simply use a normal index int and increment that instead, then gcc has no trouble optimizing it as you desire.

Modifying the pointer has side effects.

Another way, simply make a copy of the pointer, and modify the copy. Again it optimizes.

answered Jan 2 at 23:18

RubyPanther

113

answered Jan 2 at 23:18

RubyPanther

113

answered Jan 2 at 23:18

RubyPanther

113

answered Jan 2 at 23:18

RubyPanther

113

There's no conceptual difference between incrementing the pointer and incrementing an index - both are local variables, whose modifications aren't seen anywhere outside the function.

– Matteo Italia
Jan 2 at 23:32

2

Can you give a godbolt link demonstrating that "make a copy of the point, and modify the copy" optimizes this way? I can't reproduce that.

– Rob Napier
Jan 3 at 0:13

Thanks for your answer! Could you elaborate on those side effects? Somehow I can't figure out any way to make this optimization to happen through a copied pointer (godbolt - tested gcc and clang)

– Julius
Jan 3 at 9:22

That site's javascript doesn't let me paste out from there, so that isn't useful to me. If you make a gist at github though I'd be happy to compile it in gcc to verify.

– RubyPanther
Jan 4 at 5:19

I tested in gcc before posting my answer, I have no idea about clang optimizations. I agree with Matteo that there isn't a conceptual difference; rather, the compiler implementation is such that it doesn't do the work to tell that it is the same. Only when you isolate the changes to the function's stack frame does is it confident that the pointer doesn't get changed somewhere else.

– RubyPanther
Jan 4 at 5:23

add a comment |

There's no conceptual difference between incrementing the pointer and incrementing an index - both are local variables, whose modifications aren't seen anywhere outside the function.

– Matteo Italia
Jan 2 at 23:32

2

Can you give a godbolt link demonstrating that "make a copy of the point, and modify the copy" optimizes this way? I can't reproduce that.

– Rob Napier
Jan 3 at 0:13

Thanks for your answer! Could you elaborate on those side effects? Somehow I can't figure out any way to make this optimization to happen through a copied pointer (godbolt - tested gcc and clang)

– Julius
Jan 3 at 9:22

That site's javascript doesn't let me paste out from there, so that isn't useful to me. If you make a gist at github though I'd be happy to compile it in gcc to verify.

– RubyPanther
Jan 4 at 5:19

I tested in gcc before posting my answer, I have no idea about clang optimizations. I agree with Matteo that there isn't a conceptual difference; rather, the compiler implementation is such that it doesn't do the work to tell that it is the same. Only when you isolate the changes to the function's stack frame does is it confident that the pointer doesn't get changed somewhere else.

– RubyPanther
Jan 4 at 5:23

There's no conceptual difference between incrementing the pointer and incrementing an index - both are local variables, whose modifications aren't seen anywhere outside the function.

– Matteo Italia
Jan 2 at 23:32

Can you give a godbolt link demonstrating that "make a copy of the point, and modify the copy" optimizes this way? I can't reproduce that.

– Rob Napier
Jan 3 at 0:13

Thanks for your answer! Could you elaborate on those side effects? Somehow I can't figure out any way to make this optimization to happen through a copied pointer (godbolt - tested gcc and clang)

– Julius
Jan 3 at 9:22

That site's javascript doesn't let me paste out from there, so that isn't useful to me. If you make a gist at github though I'd be happy to compile it in gcc to verify.

– RubyPanther
Jan 4 at 5:19

I tested in gcc before posting my answer, I have no idea about clang optimizations. I agree with Matteo that there isn't a conceptual difference; rather, the compiler implementation is such that it doesn't do the work to tell that it is the same. Only when you isolate the changes to the function's stack frame does is it confident that the pointer doesn't get changed somewhere else.

– RubyPanther
Jan 4 at 5:23

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu