https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111020
Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amylaar at gcc dot gnu.org
--- Comment #6 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
(In reply to H. Peter Anvin from comment #5)
> 2. It seems like it almost would require an implementation-specific
> performance model. Now, one can validly argue that by setting the cost of
> unimplemented instructions to a (near-)infinite value such instructions
> should never be generated even if they are "enabled". That might also be a
> possible avenue for achieving this.
Yes, that makes it possible to implement the interface without actually having
a dedicated mask table. However, you still have the headache of how to get
code generation to use this effectively. A lot of code generation strategies
are basically canned solution that a skilled assembler programmer has devised;
you can theoretically use the superoptimizer to find linear sequences for
arbitrary instruction sets, but the compilation time cost and the limit to
linear sequences makes this impractical.
Therefore, as you want to co-develop architecture and software, you likely also
have to hack the compiler to make effective use of your architecture.
FWIW, 'infinite' cost seems unnecessarily high, considering you could make your
assembler replace missing instructions with function calls, and these functions
can get linked from a library. So you have a finite cost per-call for the call
site size (static instruction count) & time (dynamic instruction count), and a
one-time size cost per-object for each function used. Such a library and
assembler modification could be prepared for specific extensions that you want
to deconstruct, and then used flexibly.
