Normally I sort of frown on compiler annotations for portability reasons. I after seeing hedley project https://nemequ.github.io/hedley/ it is certainly making me think there is a portable way to use them at least. If I remember right gcc ( maybe it was gcc 9 ) even has some flags you can turn on to have it make suggestions. I was thinking about exploring this option just to see if they made any real difference. I completely understand that adding a new project dependency is not a trivial thing. I'm wondering if the cppcheck developers have ever loked into this before or if cppcheck haa a stance against compiler annotations?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I wanted to see if any of the compiler suggestions would actually help before adding hedley. So I ran with the following warning flags turned on.
-Wsuggest-attribute=pure
-Wsuggest-attribute=const
-Wsuggest-attribute=noreturn
-Wsuggest-attribute=cold
-Wsuggest-final-types
-Wsuggest-final-methods
I first started to look at Wsuggest-final-types and Wsuggest-final-methods as that is a C++11 thing and wouldn't have the same implications as compiler attributes.
After applying the changes it lead to about a less than 0.2% increase in performance. In the few test that I ran it seemed the performance gains were very small yet consistent over long runs. So I went ahead and made a github pull request with just the changes of adding the C++11 term here https://github.com/danmar/cppcheck/pull/3773
By turning on the link time optimization and the Wsuggest-final-types and Wsuggest-final-methods gcc is able to tell you where adding the c++11 term final it is able to devirtualize an address at compile time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I went a head and canceled my Pull Request as adding the C++11 term final broke a lot of the unit test. For such a small performance gain I didn't think it was worth the headache.
Looking at the other Wsuggest of const, pure, cold and noreturn. The compiler has suggested 0 Cold and 0 noreturn functions. But 122 pure and 16 const functoins. This was based off of commit d928b57829eb6401f673fe0e272d28b5a5492ccf
I will attach both list of suggestions. As const has bigger compiler implications over pure I have started with const. In the const.txt list I have already looked at the 16 suggested const functions and have found 6 of the functions to be const.
I need to spend a little time in compiler explore or objdump to verify effect. Hasn't changed from what I remember. Also I need to see if these functions are on any of the hot paths.
I did some performance runs with the const attribute set and it showed no real difference in performance. As const allows the compiler to reuses a function return value vs just inlining it sometimes can lead to bigger performance gains. I will hold off looking in to the pure function suggested attribute as I find it is usually less worth the effort.
I had hoped there would be some performance gain and hadley would be a small foot print to be able to handle different compilers. I was once told that boost has something similar, but like I said I prefer a smaller foot prints. As of now I can't see a reason to add it in unless I could think of a way to hadley as some sort of library config that it could pass useful things on to cppcheck, but I'm not sure how useful that is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Normally I sort of frown on compiler annotations for portability reasons. I after seeing hedley project https://nemequ.github.io/hedley/ it is certainly making me think there is a portable way to use them at least. If I remember right gcc ( maybe it was gcc 9 ) even has some flags you can turn on to have it make suggestions. I was thinking about exploring this option just to see if they made any real difference. I completely understand that adding a new project dependency is not a trivial thing. I'm wondering if the cppcheck developers have ever loked into this before or if cppcheck haa a stance against compiler annotations?
I have not seen hedley before. I think it sounds good to use it. feel free to add it.
So I wanted to see if any of the compiler suggestions would actually help before adding hedley. So I ran with the following warning flags turned on.
-Wsuggest-attribute=pure
-Wsuggest-attribute=const
-Wsuggest-attribute=noreturn
-Wsuggest-attribute=cold
-Wsuggest-final-types
-Wsuggest-final-methods
I first started to look at Wsuggest-final-types and Wsuggest-final-methods as that is a C++11 thing and wouldn't have the same implications as compiler attributes.
After applying the changes it lead to about a less than 0.2% increase in performance. In the few test that I ran it seemed the performance gains were very small yet consistent over long runs. So I went ahead and made a github pull request with just the changes of adding the C++11 term here https://github.com/danmar/cppcheck/pull/3773
By turning on the link time optimization and the Wsuggest-final-types and Wsuggest-final-methods gcc is able to tell you where adding the c++11 term final it is able to devirtualize an address at compile time.
I went a head and canceled my Pull Request as adding the C++11 term final broke a lot of the unit test. For such a small performance gain I didn't think it was worth the headache.
Looking at the other Wsuggest of const, pure, cold and noreturn. The compiler has suggested 0 Cold and 0 noreturn functions. But 122 pure and 16 const functoins. This was based off of commit d928b57829eb6401f673fe0e272d28b5a5492ccf
I will attach both list of suggestions. As const has bigger compiler implications over pure I have started with const. In the const.txt list I have already looked at the 16 suggested const functions and have found 6 of the functions to be const.
I need to spend a little time in compiler explore or objdump to verify effect. Hasn't changed from what I remember. Also I need to see if these functions are on any of the hot paths.
I did some performance runs with the const attribute set and it showed no real difference in performance. As const allows the compiler to reuses a function return value vs just inlining it sometimes can lead to bigger performance gains. I will hold off looking in to the pure function suggested attribute as I find it is usually less worth the effort.
I had hoped there would be some performance gain and hadley would be a small foot print to be able to handle different compilers. I was once told that boost has something similar, but like I said I prefer a smaller foot prints. As of now I can't see a reason to add it in unless I could think of a way to hadley as some sort of library config that it could pass useful things on to cppcheck, but I'm not sure how useful that is.