Messages in this thread |  | | From | Linus Torvalds <> | Date | Thu, 5 Apr 2018 14:13:29 -0700 | Subject | Re: [GIT PULL] x86/build changes for v4.17 |
| |
On Thu, Apr 5, 2018 at 1:51 PM, James Y Knight <jyknight@google.com> wrote: > > I had actually meant that the __builtin_constant_p **itself** had to be a > constant expression, not that its *argument* must be an I-C-E for > __builtin_constant_p to return true.
I actually really wish that were true, and that it would always be considered an ICE.
But it's not, as you also found out.
This exact problem is why we had to come up with that crazy alternative test for an actual integer constant expression.
> Which means that __builtin_constant_p(v) was _not_ evaluated as an integer > constant expression by GCC. Instead, it was left as an expression. And, the > stack frame being only 24 bytes indicates that the __bcp eventually > evaluated to true.
Yeah.
The best of all worlds would be that __builtin_constant_p() would itself always evaluate as an integer constant expression, but the expression inside of it could be expanded as if it was not.
I realize that that can be very inconvenient for a compiler, since the two are basically done at different points in the evaluation, but it's the nicest semantics for the user.
But since gcc doesn't actually provide those semantics, clearly clang doesn't have to either.
I claim that it *could* be done right, though, if you happened to care about giving the best possible quality end result to the user.
Instead of doing the integer constant expression testing early (before inlining etc), you do it later, but you carry along a bit in the expression that says "was this expression actually _syntactically_ an I-C-E?"
And btw, I hate how stupid gcc is about "constant size arrays but acts as a VLA because it wasn't an integer-constant-expression size" things.
Your code generation example really is a sad sad example of it. A good optimizer should have generated the same code even if the stupid array again syntactically was VLA, because it damn well isn't in reality.
So if you get really excited about this, and decide that clang can do much better than gcc, I can only salute you!
Linus
|  |