On 05/10/2017 04:24 AM, Jonathan Wakely wrote:
Just because there's already one way to do something doesn't mean
better ways to do it are bad.
I'm only speaking out of jealousy being that most of my recent work has
been in C.
hadn't gone so far as to investigate using this new attribute on functions
since we already have __attribute__((const)). I haven't used this before so
maybe I'm not aware of something that makes it unusable for such cases?
Which of course raises the question if __attribute__((const)) would work out
since it's only currently used on function declarations (and pointers to
function declarations, but I don't fully understand what that is doing in
handle_const_attribute).
__attribute__((const)) is not a substitute for constexpr, it's not
even in the same ballpark. It says the function doesn't touch global
memory, it doesn't mean its return value is a constant expression, so
you can't do:
int f() __attribute__((const));
int f() { return 1; }
int i[f()];
I don't think __attribute__((const)) is useful for your goal.
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification (that I'm aware
of) for a "compile-time constant", but the concept is very important.
So just because some expression is a compile-time constant doesn't mean
we morph into a "constant expression" (as per the spec), even with
__attribute__((const)).
Perhaps I can separate this project into two stages: a const/constprop
and a constexpr. The first stage behaves as little more than a
collection of optimizer hints, extra warnings/errors and fixes to some
missed optimization opportunities, while the second implements a
constexpr for C. The first stage should lay a lot of the framework for
the second, but the second probably deserves a formal specification (and
I will certainly have to read up on changes in C++14 and 17 that I'm
behind on). I can state the rationale for the "const" or "constprop"
portion of this, but before adding a constexpr to C, I think a good
rationale should be written up and examined as well. I am in support of
this as I've encountered many areas where I saw it could be useful --
use in combination with GCC ({ statement expressions }) particularly
comes to mind.
I still have a lot to learn about the cgraph and I know next to nothing
about how profile guided optimization works, but an ideal implementation
of a const/constprop attribute should include a mechanism (perhaps via
-fopt-info?) to inform the programmer when it turns out that their
optimization hint don't look like such a good idea. :)
I appreciate everybody's feedback! Thoughts?
Also, still a bit new to GCC, am I missing any formal steps that should
be taken prior to pursuing such changes?
Thanks,
Daniel