> This patch serie adds support for the SPARC M8 processor to GCC. > The SPARC M8 processor implements the Oracle SPARC Architecture 2017.
Thanks for the contribution! > The first four patches are preparatory work: > > - bmask* instructions are put in their own instruction type. It makes > little sense to have them in the same category than array > instructions. > > - Similarly, VIS compare instructions are put in their own instruction > type. This is to better accommodate subtypes, which are not quite > the same than the subtypes of `visl' instructions. > > - The introduction of a new `subtype' insn attribute in sparc.md > avoids the need for adjusting the instruction scheduler DFAs for > previous cpu models every time a new cpu is introduced. > > - The full set of SPARC instructions used in sparc.md, and their > position in the type/subtype hierarchy, is documented in a comment. > This eases the modification of the DFA schedulers, and the addition > of new cpus. > > - The M7 DFA scheduler is reworked: > > + To use the new type/subtype hierarchy. > + The v3pipe insn attribute is no longer needed. > + More accurate latencies for instructions. > + The C4 core pipeline is documented in a comment in niagara7.md. S4 core I presume? > The next three patches introduce M8 support proper: > > - Support for -mcpu=m8 (we are thus suggesting to abandon the niagaraN > denomination for M8 and later processors.) If this mirrors the established practice, no objections by me. > - Support for a new VIS level, VIS4B, covering the new VIS > instructions introduced in OSA2017 and implemented in the M8. Also > built-ins. > > Note that no new VIS level was formally introduced in OSA2017, even > if many new VIS instructions were added to the spec. We introduced > VIS4B for coherence (like availability of builtins and visintrin.h > depending on the value of __VIS__) and avoided using VIS5 in case it > is introduced in future versions of the Oracle SPARC Architecture. This sounds sensible indeed. > - A M8 DFA scheduler: > > + Also based on the new type/subtype hierarchy. > + The functional units in the C5 core are explicitly documented in a > comment in m8.md. S5 core I presume? > See the individual patch descriptions for more information and > associated ChangeLog entries. > > After this serie gets integrated upstream we will be contributing more > support for M8 capabilities, such as support for using the new > misaligned load/store instructions for memory accesses known to be > misaligned at compile-time. > > Note that full binutils support for M8 was upstreamed in May 19. > > Bootstrapped and tested in sparc64-linux-gnu. No regressions. > Bootstrapped and tested in sparc-sun-solaris2.12. No regressions. OK for mainline and 7 branch (I can do the backport to the branch). -- Eric Botcazou
