https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88626
--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > The __builtin_constant_p call itself is "free" but whether guarded code is > "free" isn't easy to determine. I guess what you want is the computation > of "b" which is only used when it is constant is considered "free"? Yes. The computation of b should be free, and also the estimated size of the function should be at most the max of the 2 branches, not the sum, since only one will remain. One possible pessimistic definition (I am not saying we should do it, just trying to define some goal) would be, for the purpose of estimating the size: replace all __builtin_constant_p with false, simplify/DCE, and look at the size of the result. Of course we would actually inline the original function with __builtin_constant_p, the reduced one is only to get an upper bound on the size, with the assumption that when __builtin_constant_p returns true, things are always better (smaller & faster). > Confirmed for that. Not sure how easy to implement though. Running some modified DCE pass may not be too hard, although doing that just to improve the size estimation with __builtin_constant_p for inlining might be overkill... Maybe a heuristic that gives a "bonus" for inlining a function that contains __builtin_constant_p (only if the argument looks like it depends on the function parameters?) would be easier? I don't know if we have something like that yet.
