Thanks for your feedback!
On 05/09/2017 04:36 AM, Florian Weimer wrote:
On 05/09/2017 01:36 AM, Daniel Santos wrote:
To further the usefulness of such techniques, I propose the addition
of a c-family attribute to declare a parameter, variable (and
possibly other declarations) as "constprop" or some similar word. The
purpose of the attribute is to:
1.) Emit a warning or error when the value is not optimized away, and
2.) Direct various optimization passes to prefer (or force) either
cloning or inlining of a function with such a parameter.
I think GCC used to treat C and C++ constant expressions this way in
the old days. That is, what was a constant expression depended to
some degree on the capabilities of the folder at least (and maybe the
optimizers). This wasn't such a great idea because it made behavior
inconsistent across architectures and GCC versions.
What optimizations are enabled also effects it. In 2012, I made a test
program and scripted it to run on GCC versions 3.4.6 to 4.7.0 to map out
what __builtin_constant_p() was able to resolve and put it all in a
database. Most of them started working between 4.2 and 4.4. I put it
into a spreadsheet for better analysis.
Anyway, I wasn't aware that it could vary across architectures. What I'm
doing so far is only in the tree and I'm doing the checks as we're
emitting RTL.
There are also thorny specification issues, like is an array whose
length is a constprop value a VLA or not?
This is probably a worthwhile thought. I wasn't actually thinking of
specification-breaking changes, so it would be a VLA and value declared
with __attribute__((constprop)) would just be like an optimization hint
(like __builtin_expect) that could also notify you when you're request
couldn't be fulfilled.
In the past, I have considered the merits of some type of
__builtin_constexpr() to do just that, returning a value that can be
treated as a C "constant expression" (as per the language spec.), to be
used as a static initializer or fixed-size array length specifier. The
lack of such a mechanism is why the Linux kernel still resorts to
compile-time checks using a negative-sized bitfields to signal failure
(http://elixir.free-electrons.com/linux/latest/source/include/linux/bug.h#L37).
I would have to do a lot more research to fully understand the issues
and implications of that.
If you are interested in metaprogramming techniques, you are probably
better off writing code generators or using a C++ subset.
Thanks,
Florian
Yeah, somehow I got myself interested in this unexploited avenue. It
seems that more progressive programmers are of the mindset to just use
C++, but system-level programmers tend to be wary of such magicks and
often shun "dead-code trickery".
Thanks,
Daniel
