On 11/10/25 1:49 PM, Segher Boessenkool wrote:
> We should not have a "Future" thing that stands in for any future stuff.
I don't know what you mean by this.
> The thing we _now_ call "Future" we will rename (probably to POWER12,
> but who knows!) soon enough. And then when we start doing stuff for
> what everyone assumes wil be called POWER13, we'll call that "Future"
> again, for the time being. We cannot suggest that POWER13 will have
> feature X, and Y execution units, and speed Z. Some people are afraid
> that if we (developers) state we have some goal, that customers will see
> that as something we promised them, and then maybe even sue us.
No argument there.
> There always is just one thing called Future, but it is a stand-in name
> for one particular name at all times, it never is nor will be a generic
> thing for "whatever shows up in the future". It is a workaround for
> big corporation bureaucracy, not a development strategy.
It is, but it's more than that. It can also act as a landing pad
for experimental backend work that may never go anywhere, like maybe
Mike adding support for a HW feature someone from the IBM GCC team
is thinking about and wondering "would this work and help?".
> If we had overlapping generations of development, we'd have a FUTURE2
> as well :-)
No, that was never how I envisioned -mcpu=future to work. And having
multiple -mcpu=future{,2,3,...} is just ugly! There should just be one
-mcpu=future option and if you're implementing things that will go into
Power12, Power13, ...., Power27 all at the same time, they should all
be enabled with -mcpu=future. Once the next PowerN cpu is announced,
then the you'd add the -mcpu=powerN option and switch those patterns,
etc. that are in PowerN to the new TARGET_POWERN, etc. tests, but don't
delete the -mcpu=future option itself, that should always exist.
The common case, all the code enabled by -mcpu=future would be changed
to be enabled by -mcpu=powerN and -mcpu=future would just end up being
an alias for powerN. However, if there is some PowerN+1, etc. code left,
then it still is enabled by -mcpu=future.
> But we never said that Power_(N+1) will have these features, or this
> speed, etc. :-)
Correct, code added to -mcpu-future is not a guarantee IBM will ever
ship a cpu with that support.
Peter
