Summary:
LLVM issues a warning if passed unknown target features. Neither I nor
@asb noticed this until after https://reviews.llvm.org/D63498 landed.
This patch stops passing the (unknown) "save-restore" target feature to
the LLVM backend, but continues to emit a warning if a driver asks for
`-msave-restore`. The default of assuming `-mno-save-restore` (and
emitting no warnings) remains.
Reviewers: asb
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, cfe-commits, asb
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64008
llvm-svn: 364777
Summary:
The changes in D59673 made the choice redundant, since we can achieve
single-file split DWARF just by not setting an output file name.
Like llc we can also derive whether to enable Split DWARF from whether
-split-dwarf-file is set, so we don't need the flag at all anymore.
The test CodeGen/split-debug-filename.c distinguished between having set
or not set -enable-split-dwarf with -split-dwarf-file, but we can
probably just always emit the metadata into the IR.
The flag -split-dwarf wasn't used at all anymore.
Reviewers: dblaikie, echristo
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D63167
llvm-svn: 364479
Summary:
This diff enables address sanitizer on Emscripten.
On Emscripten, real memory starts at the value passed to --global-base.
All memory before this is used as shadow memory, and thus the shadow mapping
function is simply dividing by 8.
Reviewers: tlively, aheejin, sbc100
Reviewed By: sbc100
Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D63742
llvm-svn: 364468
This patch introduces support of hip_pinned_shadow variable for HIP.
A hip_pinned_shadow variable is a global variable with attribute hip_pinned_shadow.
It has external linkage on device side and has no initializer. It has internal
linkage on host side and has initializer or static constructor. It can be accessed
in both device code and host code.
This allows HIP runtime to implement support of HIP texture reference.
Differential Revision: https://reviews.llvm.org/D62738
llvm-svn: 364381
The android target assumes that for the x86_64 target, the CPU supports SSE4.2
and popcnt. This implies that the CPU is Nehalem or newer. This should be
sufficiently new to provide the double word compare and exchange instruction.
This allows us to directly lower `__sync_val_compare_and_swap_16` to a `cmpxchg16b`.
It appears that the libatomic in android's NDK does not provide the
implementation for lowering calls to the library function.
llvm-svn: 364352
This reverts r363985 (git commit d5f16d6cfc)
This test can't use printf on Windows because the path contains
backslashes which must not be interpreted as escapes by printf.
llvm-svn: 364089
Summary:
The GCC RISC-V toolchain accepts `-msave-restore` and `-mno-save-restore`
to control whether libcalls are used for saving and restoring the stack within
prologues and epilogues.
Clang currently errors if someone passes -msave-restore or -mno-save-restore.
This means that people need to change build configurations to use clang. This
patch adds these flags, so that clang invocations can now match gcc.
As the RISC-V backend does not currently have a `save-restore` target feature,
we emit a warning if someone requests `-msave-restore`. LLVM does not error if
we pass the (unimplemented) target features `+save-restore` or `-save-restore`.
Reviewers: asb, luismarques
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63498
llvm-svn: 364018
Clang :: Driver/cl-response-file.c currently FAILs on Solaris:
Command Output (stderr):
--
/vol/llvm/src/clang/dist/test/Driver/cl-response-file.c:10:11: error: CHECK: expected string not found in input
// CHECK: "-I" "{{.*}}\\Inputs\\cl-response-file\\" "-D" "FOO=2"
^
Looking at the generated response file reveals that this is no surprise:
/I/vol/llvm/src/clang/dist/test/Driver\Inputs
with no newline at the end. The echo command used to create it boils down to
echo 'a\cb'
However, one cannot expect \c to be emitted literally: e.g. bash's builtin
echo has
\c suppress further output
I've tried various combinations of builtin echo, /usr/bin/echo, GNU echo if
different, the same for printf, and the backslash unescaped and quoted
(a\cb and a\\cb). The only combination that worked reliably on Solaris,
Linux, and macOS was
printf 'a\\cb'
so this is what this patch uses. Tested on amd64-pc-solaris2.11 and
x86_64-pc-linux-gnu.
Differential Revision: https://reviews.llvm.org/D63600
llvm-svn: 363985
Use -fsave-optimization-record=<format> to specify a different format
than the default, which is YAML.
For now, only YAML is supported.
llvm-svn: 363573
The flag is useful when wanting to create .o files that are independent
from the absolute path to the build directory. -fdebug-prefix-map= can
be used to the same effect, but it requires putting the absolute path
to the build directory on the build command line, so it still requires
the build command line to be dependent on the absolute path of the build
directory. With this flag, "-fdebug-compilation-dir ." makes it so that
both debug info and the compile command itself are independent of the
absolute path of the build directory, which is good for build
determinism (in the sense that the build is independent of which
directory it happens in) and for caching compile results.
(The tradeoff is that the debugger needs explicit configuration to know
the build directory. See also http://dwarfstd.org/ShowIssue.php?issue=171130.2)
Differential Revision: https://reviews.llvm.org/D63387
llvm-svn: 363548
Summary:
With Split DWARF the resulting object file (then called skeleton CU)
contains the file name of another ("DWO") file with the debug info.
This can be a problem for remote compilation, as it will contain the
name of the file on the compilation server, not on the client.
To use Split DWARF with remote compilation, one needs to either
* make sure only relative paths are used, and mirror the build directory
structure of the client on the server,
* inject the desired file name on the client directly.
Since llc already supports the latter solution, we're just copying that
over. We allow setting the actual output filename separately from the
value of the DW_AT_[GNU_]dwo_name attribute in the skeleton CU.
Fixes PR40276.
Reviewers: dblaikie, echristo, tejohnson
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D59673
llvm-svn: 363496
Summary:
This is the first in a series of changes trying to align clang -cc1
flags for Split DWARF with those of llc. The unfortunate side effect of
having -split-dwarf-output for single file Split DWARF will disappear
again in a subsequent change.
The change is the result of a discussion in D59673.
Reviewers: dblaikie, echristo
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D63130
llvm-svn: 363494
Add constraints for the test that require specific backend targets
to be registered.
Remove trailing whitespace in the doc.
Differential Revision: https://reviews.llvm.org/D63105
llvm-svn: 363475
This patch allows clang users to print out a list of supported CPU models using
clang [--target=<target triple>] --print-supported-cpus
Then, users can select the CPU model to compile to using
clang --target=<triple> -mcpu=<model> a.c
It is a handy feature to help cross compilation.
llvm-svn: 363464
Move include path construction from
InitHeaderSearch::AddDefaultIncludePaths in the Driver which appears
to be the more modern/correct way of doing things.
Differential Revision: https://reviews.llvm.org/D63030
llvm-svn: 363241
It breaks if build directory is not writable. This change is required
to fix our integrate.
Also add a flush() call, otherwise time trace option does not produce
the full output.
llvm-svn: 363052
Summary:
Add output to `llvm::errs()` when `-ftime-trace` option is enabled,
add regression test checking this option works as expected.
Reviewers: thakis, aganea
Subscribers: cfe-commits, llvm-commits
Tags: #clang, #llvm
This is recommit of r362821
Differential Revision: https://reviews.llvm.org/D61914
llvm-svn: 363036
Summary:
Add output to `llvm::errs()` when `-ftime-trace` option is enabled,
add regression test checking this option works as expected.
Reviewers: thakis, aganea
Subscribers: cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D61914
........
Breaks buildbots - @anton-afanasyev please can you take a look?
llvm-svn: 362816
Summary:
Add output to `llvm::errs()` when `-ftime-trace` option is enabled,
add regression test checking this option works as expected.
Reviewers: thakis, aganea
Subscribers: cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D61914
llvm-svn: 362792
Change D60691 caused some knock-on failures that weren't caught by the
existing tests. Firstly, selecting a CPU that should have had a
restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs
and no double precision) could give the unrestricted version, because
`ARM::getFPUFeatures` returned a list of features including subtracted
ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw
away all the ones that didn't start with `+`. Secondly, the
preprocessor macros didn't reliably match the actual compilation
settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as
if hardware FP was available, because the list of features on the cc1
command line would include things like `+vfp4`,`-vfp4d16` and clang
didn't realise that one of those cancelled out the other.
I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so
that it returns a list that enables every FP-related feature
compatible with the selected FPU and disables every feature not
compatible, which is more verbose but means clang doesn't have to
understand the dependency relationships between the backend features.
Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all
the various forms of the FP feature names, so that it won't miss cases
where it should have set `HW_FP` to feed into feature test macros.
That in turn caused an ordering problem when handling `-mcpu=foo+bar`
together with `-mfpu=something_that_turns_off_bar`. To fix that, I've
arranged that the `+bar` suffixes on the end of `-mcpu` and `-march`
cause feature names to be put into a separate vector which is
concatenated after the output of `getFPUFeatures`.
Another side effect of all this is to fix a bug where `clang -target
armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even
though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was
because `HW_FP` was being set to a value including only the `FPARMV8`
bit, but that feature test macro was testing only the `VFP4FPU` bit.
Now `HW_FP` ends up with all the bits set, so it gives the right
answer.
Changes to tests included in this patch:
* `arm-target-features.c`: I had to change basically all the expected
results. (The Cortex-M4 test in there should function as a
regression test for the accidental double-precision bug.)
* `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG`
everywhere so that those tests are no longer sensitive to the order
of cc1 feature options on the command line.
* `arm-acle-6.5.c`: been updated to expect the right answer to that
FMA test.
* `Preprocessor/arm-target-features.c`: added a regression test for
the `mfpu=softvfp` issue.
Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne
Reviewed By: ostannard
Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62998
llvm-svn: 362791
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
Tests that use -O1, -O2 and -O3 would often produce different results
with the new pass manager which makes these tests fail. Disable new PM
explicitly for these tests.
Differential Revision: https://reviews.llvm.org/D58375
llvm-svn: 362580
Part 2 (the Clang portion) of D59881.
This patch (first of two patches) enables the vectorizer to recognize the
IBM MASS vector library routines. This patch specifically adds support for
recognizing the -vector-library=MASSV option, and defines mappings from IEEE
standard scalar math functions to generic PowerPC MASS vector counterparts.
For instance, the generic PowerPC MASS vector entry for double-precision
cbrt function is __cbrtd2_massv.
The second patch will further lower the generic PowerPC vector entries to
PowerPC subtarget-specific entries.
For instance, the PowerPC generic entry cbrtd2_massv is lowered to
cbrtd2_P9 for Power9 subtarget.
The overall support for MASS vector library is presented as such in two patches
for ease of review.
Patch by Jeeva Paudel.
Differential revision: https://reviews.llvm.org/D59881
llvm-svn: 362571
The recent change D60691 introduced a bug in clang when handling
option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those
options together should select Cortex-M4 but disable all use of
hardware FP, but in fact, now hardware FP instructions can still be
generated in that mode.
The reason is because the handling of FPUVersion::NONE disables all
the same feature names it used to, of which the base one is `vfp2`.
But now there are further features below that, like `vfp2d16fp` and
(following D60694) `fpregs`, which also need to be turned off to
disable hardware FP completely.
Added a tiny test which double-checks that compiling a simple FP
function doesn't access the FP registers.
Reviewers: SjoerdMeijer, dmgreen
Reviewed By: dmgreen
Subscribers: lebedev.ri, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62729
llvm-svn: 362380
The new tests were failing, because I missed dependent patch D60697.
I have removed the failing cases for now, which I will restore once
D60697 is in.
llvm-svn: 362100
Given the existing infrastructure in LLVM side for +fp and +fp.dp,
this is more or less trivial, needing only one tiny source change and
a couple of tests.
Patch by Simon Tatham.
Differential Revision: https://reviews.llvm.org/D60699
llvm-svn: 362096
Modern ELF platforms use -fuse-init-array to emit .init_array instead of
.ctors . ld.bfd and gold --ctors-in-init-array merge .init_array and
.ctors into .init_array but lld doesn't do that.
If crtbegin*.o crtend*.o don't provide .ctors/.dtors, such .ctors in
user object files can lead to crash (see PR42002. The first and the last
elements in .ctors/.dtors are ignored - they are traditionally provided
by crtbegin*.o crtend*.o).
Call addClangTargetOptions() to ensure -fuse-init-array is rendered on
modern ELF platforms. On Hexagon, this renders -target-feature
+reserved-r19 for -ffixed-r19.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D62509
llvm-svn: 362052
This matches gcc -static-pie. The intention is to prevent dynamic
relocations in read-only segments.
In ld.bfd and gold, -z notext is the default. If text relocations are needed:
* -z notext: allow and emit DF_TEXTREL.
DF_TEXTREL is not emitted if there is no text relocation.
* -z text: error
In lld, -z text is the default (this change is a no-op).
* -z text: error on text relocations
* -z notext: allow text relocations, and emit DF_TEXTREL no matter whether
text relocations exist.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D62606
llvm-svn: 362050
This is useful when looking for directories or files relative to the
toolchain root, e.g. include/c++/v1. This change also adds a test
to make sure this functionality doesn't regress in the future.
Differential Revision: https://reviews.llvm.org/D62558
llvm-svn: 361903
Sam Elliott