Commit Graph

8 Commits

Author SHA1 Message Date
Rainer Orth 76e85ae268 [clang][Sparc] Default to -mcpu=v9 for Sparc V8 on Solaris
As reported in Bug 42535, `clang` doesn't inline atomic ops on 32-bit
Sparc, unlike `gcc` on Solaris.  In a 1-stage build with `gcc`, only two
testcases are affected (currently `XFAIL`ed), while in a 2-stage build more
than 100 tests `FAIL` due to this issue.

The reason for this `gcc`/`clang` difference is that `gcc` on 32-bit
Solaris/SPARC defaults to `-mpcu=v9` where atomic ops are supported, unlike
with `clang`'s default of `-mcpu=v8`.  This patch changes `clang` to use
`-mcpu=v9` on 32-bit Solaris/SPARC, too.

Doing so uncovered two bugs:

`clang -m32 -mcpu=v9` chokes with any Solaris system headers included:

  /usr/include/sys/isa_defs.h:461:2: error: "Both _ILP32 and _LP64 are defined"
  #error "Both _ILP32 and _LP64 are defined"

While `clang` currently defines `__sparcv9` in a 32-bit `-mcpu=v9`
compilation, neither `gcc` nor Studio `cc` do.  In fact, the Studio 12.6
`cc(1)` man page clearly states:

            These predefinitions are valid in all modes:
  [...]
               __sparcv8 (SPARC)
               __sparcv9 (SPARC -m64)

At the same time, the patch defines `__GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248]`
for a 32-bit Sparc compilation with any V9 cpu.  I've also changed
`MaxAtomicInlineWidth` for V9, matching what `gcc` does and the Oracle
Developer Studio 12.6: C User's Guide documents (Ch. 3, Support for Atomic
Types, 3.1 Size and Alignment of Atomic C Types).

The two testcases that had been `XFAIL`ed for Bug 42535 are un-`XFAIL`ed
again.

Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D86621
2020-09-11 09:53:19 +02:00
Brad Smith 5fe171321c [Sparc] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros on SPARCv9 2020-08-11 00:04:24 -04:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Daniel Cederman 8cc53aecad [Sparc] Add floating-point register names
Reviewers: jyknight

Reviewed By: jyknight

Subscribers: eraman, fedor.sergeev, jrtc27, cfe-commits

Differential Revision: https://reviews.llvm.org/D47137

llvm-svn: 333510
2018-05-30 06:02:18 +00:00
Erich Keane e44bdb3f70 Add Rest of Targets Support to ValidCPUList (enabling march notes)
A followup to: https://reviews.llvm.org/D42978

Most of the rest of the Targets were pretty rote, so this
patch knocks them all out at once. 

Differential Revision: https://reviews.llvm.org/D43057

llvm-svn: 324676
2018-02-08 23:16:55 +00:00
Walter Lee 637aafc451 [Myriad] Define __ma2x5x and __ma2x8x
Summary: Add architecture defines for ma2x5x and ma2x8x.

Reviewers: jyknight

Subscribers: fedor.sergeev, MartinO

Differential Revision: https://reviews.llvm.org/D42882

llvm-svn: 324420
2018-02-06 22:39:47 +00:00
Walter Lee fc7f8f25f3 Add support for Myriad ma2x8x series of CPUs
Summary:
Also:
- Add support for some older Myriad CPUs that were missing.
- Fix some incorrect compiler defines for exisitng CPUs.

Reviewers: jyknight

Subscribers: fedor.sergeev

Differential Revision: https://reviews.llvm.org/D37551

llvm-svn: 314706
2017-10-02 18:50:57 +00:00
Erich Keane ebba592682 Break up Targets.cpp into a header/impl pair per target type[NFCI]
Targets.cpp is getting unwieldy, and even minor changes cause the entire thing 
to cause recompilation for everyone. This patch bites the bullet and breaks 
it up into a number of files.

I tended to keep function definitions in the class declaration unless it 
caused additional includes to be necessary. In those cases, I pulled it 
over into the .cpp file. Content is copy/paste for the most part, 
besides includes/format/etc.


Differential Revision: https://reviews.llvm.org/D35701

llvm-svn: 308791
2017-07-21 22:37:03 +00:00