[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20362fe79d494bd59471a9c0f002b2ef@AcuMS.aculab.com>
Date: Sat, 7 Dec 2024 21:00:41 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Martin Uecker' <muecker@...g.de>, Linus Torvalds
<torvalds@...ux-foundation.org>, Vincent Mailhol <vincent.mailhol@...il.com>
CC: "w@....eu" <w@....eu>, Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers
<ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>, Justin Stitt
<justinstitt@...gle.com>, Yury Norov <yury.norov@...il.com>, Rasmus Villemoes
<linux@...musvillemoes.dk>, Kees Cook <kees@...nel.org>, "Gustavo A. R.
Silva" <gustavoars@...nel.org>, Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Rodrigo Vivi
<rodrigo.vivi@...el.com>, Tvrtko Ursulin <tursulin@...ulin.net>, David Airlie
<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Suzuki K Poulose
<suzuki.poulose@....com>, Mike Leach <mike.leach@...aro.org>, James Clark
<james.clark@...aro.org>, Alexander Shishkin
<alexander.shishkin@...ux.intel.com>, Rikard Falkeborn
<rikard.falkeborn@...il.com>, "linux-sparse@...r.kernel.org"
<linux-sparse@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "llvm@...ts.linux.dev"
<llvm@...ts.linux.dev>, "linux-hardening@...r.kernel.org"
<linux-hardening@...r.kernel.org>, "intel-gfx@...ts.freedesktop.org"
<intel-gfx@...ts.freedesktop.org>, "dri-devel@...ts.freedesktop.org"
<dri-devel@...ts.freedesktop.org>, "coresight@...ts.linaro.org"
<coresight@...ts.linaro.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 02/10] compiler.h: add is_const() as a replacement of
__is_constexpr()
From: Martin Uecker
> Sent: 07 December 2024 19:52
...
> > Of course, often the compiler *does* have helper builtins, but we
> > can't use them, because they aren't *quite* the right thing. Like that
> > "__builtin_constant_p()" not actually working for some situations
> > where we absolutely need not just a constant value, but a constant
> > _expression_ due to C parsing rules.
In many cases the C language says 'constant integer expression'
but is reality something that passes __builtin_constant_p()
is likely to be fine - because the actual value isn't needed
until late on in the compilation.
...
> > If there is one feature of C I would have liked it is "allow inline
> > functions and statement expressions with constant arguments as
> > constant expressions". Other languages have done that, and it really
> > does help. And yes, it means that you have to basically have a
> > language interpreter in the compiler (you do want to allow loop
> > constructions etc), but it really is very useful.
It the output needs to be a constant the loop would have to be unrollable.
In those cases the result will be 'constant enough' for __builtin_constant_p()
and the compiler is actually already capable doing it.
...
> > At one point I literally was thinking I'd do 'sparse' as a
> > pre-processor for kernel code, in order to have extended language
> > facilities like that.
You could use m4 :-) and make it entirely unreadable.
> There exist proposals along those lines for C2Y.
>
> From a more near-term solution, I wonder if making it possible (or
> easier) to return integer constant expressions from statement
> expressions and allowing a restricted form of statement expressions
> at file scope would help?
It would help a lot if a #define that just used local variables
to avoid arguments being re-expanded and for CSE could still
generate a constant value.
Does need to be a #define - to get token pasting and 'stringify'.
Although you would need something for reporting detected errors,
and builtin compiler support for const_true() for the detection
itself.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists