For now only focus on the CPU type, will work on the CPU features part
later.
With the CPU handling in TargetParser, clang and llc/opt are able to
query common interfaces.
So we can set same default CPU and CPU features with same interfaces.
This patch adds the clang portion of an AIX-specific option to inform
the
compiler that it can use a faster access sequence for the local-dynamic
TLS model (formally named aix-small-local-dynamic-tls).
This patch mainly references Amy's work on small local-exec TLS support.
This patch disallows the use of the -maix-small-local-exec-tls and
-fno-data-sections options within clang, and also disallows the use of
the aix-small-local-exec-tls attribute with the -data-sections=false
option in llc.
This is because having data sections off when using the
aix-small-local-exec-tls feature is not ideal for performance. As the
small-local-exec-tls region is a limited resource, this space should not
used for variables that may be replaced.
Note, that on AIX, data sections is turned on by default, so this patch
makes it so that a diagnostic is emitted when users explicitly turn off
data sections while using the aix-small-local-exec-tls feature.
clang/lib/Driver/ToolChains/Clang.cpp has a lot of fragments like the following:
```
if (const Arg *A = Args.getLastArg(...)) {
if (Triple is xxx)
A->render(Args, CmdArgs);
else
D.Diag(diag::err_drv_unsupported_opt_for_target) << ...;
}
```
The problem is more apparent with a recent surge of AIX-specific options.
Introduce the TargetSpecific flag so that we can move the target-specific
options to ToolChains/*.cpp and ToolChains/Arch/*.cpp and overload the
warn_drv_unused_argument mechanism to give an err_drv_unsupported_opt_for_target
error.
Migrate -march=/-mcpu= and some AIX-specific options to use this simplified pattern.
Reviewed By: jansvoboda11
Differential Revision: https://reviews.llvm.org/D151590
Predefine __AMDGCN_CUMODE__ as 1 or 0 when compilation assumes CU or WGP modes.
If WGP mode is not supported, ignore -mno-cumode and emit a warning.
This is needed for implementing device functions like __smid
(312dff7b79/include/hip/amd_detail/amd_device_functions.h (L957))
Reviewed by: Matt Arsenault, Artem Belevich, Brian Sumner
Differential Revision: https://reviews.llvm.org/D145343
Clang -march= for ppc triples currently leads to an
-Wunused-command-line-argument warning but GCC rejects -march=.
error: unrecognized command-line option ‘-march=xxx’
Let's reject -march= as well similar to the Sparc change D130273.
Close https://github.com/llvm/llvm-project/issues/57587
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D145141
There are two ways of specifying a CPU on PowerPC:
power<N> and pwr<N>. Clang/LLVM traditionally
supports the latter and Clang replaces the former
with the latter when passing it to the back end for
the -mcpu= option. However, when the -mtune= option
was introduced, this replacement was not implemented for it.
This leaves us in an inconsistent state of accepting
both forms for -mcpu= and and only the latter for
-mtune=. Furthermore, it leaves us incompatible with
GCC which only understands the power<N> version for
both options.
This patch just adds the same handling for the long
names for -mtune= as already exists for -mcpu=.
Differential revision: https://reviews.llvm.org/D144967
Add a member function isPPC32SecurePlt() to determine whether Secure
PLT is used by the target 32-bit PowerPC operating environment.
Reviewed By: dim, maskray
Differential Revision: https://reviews.llvm.org/D144444
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
The ClangBuiltLinux project relies on `-mcpu=405`. Before https://reviews.llvm.org/D139720, `clang` treated `-mcpu=405` implicitly in the same way as `-mcpu=generic`, because `405` was an unknown value and `clang` did not validate unknown input values. https://reviews.llvm.org/D139720 added the validation of `-mcpu` input value, and `clang` now generates an error with `-mcpu=405`. For further details of the problem, see https://github.com/ClangBuiltLinux/linux/issues/1771.
This patch adds support of `-mcpu=405` explicitly, and treats it as an equivalent of `-mcpu=generic`.
Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D140080
Currently `ppc::getPPCTargetCPU` returns an empty string when it encounters an unknown value passed to `-mcpu`. This causes `clang` to ignore unknown `-mcpu` values silently.
This patch changes the behaviour of `ppc::getPPCTargetCPU` so that it passes the unknown option to the target info, so the target info can actually check if the CPU string is supported, and report an error when encountering unknown/unsupported CPU string.
Reviewed By: jamieschmeiser
Differential Revision: https://reviews.llvm.org/D139720
This compensates for 8f0c901c1a172313a32bc06a1fcface76cd1220f which enabled
-Wunused-command-line-argument for unimplemented -mtune= in the generic code.
Ignoring -mtune= appears to be longstanding and the error-free behavior in the
presence of -Werror is unfortunately relied on by the Linux kernel's arm and
powerpc ports. Ignore the warnings for the upcoming 15.0.0 branch and will
implement functionality to fill the test gap soon.
Link: https://github.com/ClangBuiltLinux/linux/issues/1674
Summary:
This patch simply adds support for the new CPU in anticipation of
Power10. There isn't really any functionality added so there are no
associated test cases at this time.
Reviewers: stefanp, nemanjai, amyk, hfinkel, power-llvm-team, #powerpc
Reviewed By: stefanp, nemanjai, amyk, #powerpc
Subscribers: NeHuang, steven.zhang, hiraditya, llvm-commits, wuzish, shchenz, cfe-commits, kbarton, echristo
Tags: #clang, #powerpc, #llvm
Differential Revision: https://reviews.llvm.org/D80020
Summary:
This patch simply adds support for the new CPU in anticipation of
Power10. There isn't really any functionality added so there are no
associated test cases at this time.
Reviewers: stefanp, nemanjai, amyk, hfinkel, power-llvm-team, #powerpc
Reviewed By: stefanp, nemanjai, amyk, #powerpc
Subscribers: NeHuang, steven.zhang, hiraditya, llvm-commits, wuzish, shchenz, cfe-commits, kbarton, echristo
Tags: #clang, #powerpc, #llvm
Differential Revision: https://reviews.llvm.org/D80020
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Follow-up of D72014. It is more appropriate to use a target
feature instead of a SubTypeArch to express the difference.
Reviewed By: #powerpc, jhibbits
Differential Revision: https://reviews.llvm.org/D72433
This patch will add -mcpu=future into clang for PowerPC.
A CPU type is required for work that may possibly be enabled for some future
Power CPU. The CPU type future will serve that purpose. This patch introduces
no new functionality. It is an incremental patch on top of which Power PC work
for some future CPU can be done.
Differential Revision: https://reviews.llvm.org/D70262
8548 CPU is GCC's name for the e500v2, so accept this in clang. The
e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well,
as GCC does.
Differential Revision: https://reviews.llvm.org/D67787
Works on this dependency chain:
ArrayRef.h ->
Hashing.h -> --CUT--
Host.h ->
StringMap.h / StringRef.h
ArrayRef is very popular, but Host.h is rarely needed. Move the
IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are
more likely to need it.
llvm-svn: 375316
The musl libc only supports Secure PLT.
Patch by A. Wilcox!
Reviewed By: jhibbits
Differential Revision: https://reviews.llvm.org/D59185
llvm-svn: 362051
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
This just adds the CPU to a list of commands passed to GAS when not using the
integrated assembler.
Differential Revision: https://reviews.llvm.org/D33820
llvm-svn: 309256
The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.
Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.
llvm-svn: 298449
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
