ro added inline comments.
================
Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350
return A->getValue();
+ if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+ return "v9";
----------------
ro wrote:
> efriedma wrote:
> > ro wrote:
> > > brad wrote:
> > > > ro wrote:
> > > > > efriedma wrote:
> > > > > > Do we want to make sparc and sparcel behave differently here?
> > > > > The only thing about little-endian SPARC is that UltraSPARC CPUs can
> > > > > be run in little-endian mode, presumably to ease a Windows NT port
> > > > > that never materialized.
> > > > >
> > > > > I could barely find any info on sparcel: the triplet isn't in
> > > > > `config.guess`, there's very little else about such CPUs and
> > > > > certainly no specification or even an ABI. That's why I tend to leave
> > > > > sparcel-specific code alone unless someone who knows these beasts
> > > > > tells me otherwise.
> > > > >
> > > > > What I can say for certain that Solaris never ran on little-endian
> > > > > SPARC.
> > > > "The Sparcle is an experimental 32-bit microprocessor chip developed in
> > > > 1992 by a consortium of MIT, LSI Corporation, and Sun Microsystems. It
> > > > was an evolution Sun's SPARC RISC architecture with features geared
> > > > towards "large-scale multiprocessing".[1] The chip was manufactured by
> > > > LSI."
> > > >
> > > > https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/sparcle-micro-final.pdf
> > > >
> > > > From what little I can find I believe this prototype CPU / system was
> > > > based on Linux.
> > > Ah, thanks. So this predates Solaris 2.0 (also released in 1992). But
> > > even if not, current Solaris 11 is SPARC V9-only.
> > >
> > > However, if this is the only implementation, this bears the question why
> > > support for such an experimental CPU almost 30 years old still lives in
> > > LLVM. It comes with a cost, if only for reasoning what needs and needs
> > > not to be done to the V8el code.
> > The sparcv9 manual says the CPU has a little-endian mode; I assume that
> > means all sparcv9 chips support it. If nobody actually does that in
> > practice, though, we should drop the sparcel target.
> Right. However, that's a privileged operation AFAIU and non of the OSes I
> know about (Solaris, Linux, the BSDs) run in little-endian mode. Besides, it
> would be weird to restrict oneself to the sparcv8 insns if one were using
> that v9 facility. On top of all that, gcc doesn't support the little-endian
> mode at all.
Seems we missed something, though:
[[https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5a6e0e311&appId=PPGMS]]
states (p.18):
```
6.3.5. Endianness
The Leon processors are both working in little endian same as the SHAVE
processors. No extra requirements are needed to ensure endianess consistency.
```
Judging from that, Myriad is the primary user of sparcel these days. So unless
we can get rid of that, too, sparcel will have to stay.
The point of no available documentation remains, though.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D86621/new/
https://reviews.llvm.org/D86621
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
