Re: [GIT PULL] x86/build changes for v4.17

From: Linus Torvalds <torvalds@linux-foundation.org>
To: James Y Knight <jyknight@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Chandler Carruth <chandlerc@google.com>,
	Stephen Hines <srhines@google.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Kees Cook <keescook@google.com>,
	Guenter Roeck <groeck@chromium.org>,
	Greg Hackmann <ghackmann@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [GIT PULL] x86/build changes for v4.17
Date: Thu, 5 Apr 2018 14:13:29 -0700	[thread overview]
Message-ID: <CA+55aFz3PUE1mSM+yFeb55ca3EZAYHHqTyHjktiW1FVfK-tP9A@mail.gmail.com> (raw)
In-Reply-To: <CAA2zVHrF+teb3SwigH_sDqkWfKDg4itq4TkefYXUXw2RF9+4qw@mail.gmail.com>

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