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 AMDGPU target only emits shared libraries currently. This patch
changes the handling of the PIC level to be managed in the
AMDGPUToolChain rather than having a special case for it. This causes
`--target=amdgcn--` to no longer set the PIC. This should be an
acceptable change since that doesn't use a correct toolchain anyway.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D142999
Currently we have two versions of the static library. One is built as
individual bitcode files and linked via `-mlink-builtin-bitcode`. The
other is built as a single static archive `omptarget.devicertl.a` and is
linked via `-lomptarget.devicertl` and handled by the linker wrapper
during LTO. We use the former in the case that we are not performing
LTO, because linking the library late wouldn't allow us to optimize the
runtime library effectively. The support in D142484 allows us to
unconditionally link this library, so it will only be pulled in if
needed. That is, if we linked already via `-mlink-builtin-bitcode` then
we will not pull in the static library even if it's linked on the
command line.
Depends on D142484
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D142486
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
The option does not change IR but affect object file generation. Without a
backend option the option is a no-op for in-process ThinLTO.
The problem is known and there are many options similar to -fstack-size-section.
That said, -fstack-size-section has relatively wider adoption, so it probably
makes sense to have custom code for it.
Close https://github.com/llvm/llvm-project/issues/59424
Leaves the implementation and tests files in-place for right now, but
deletes the ability to build the old sanitizer-common based scudo. This
has been on life-support for a long time, and the newer scudo_standalone
is much better supported and maintained.
Also patches up some GWP-ASan wording, primarily related to the fact
that -fsanitize=scudo now is scudo_standalone, and therefore the way to
reference the GWP-ASan options through the environment variable has
changed.
Future follow-up patches will delete the original scudo, and migrate all
its tests over to be part of the scudo_standalone test suite.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D138157
This patch:
- Adds target-feature and target-cpu to FC1Options.
- Moves getTargetFeatures() from Clang.cpp to CommonArgs.cpp.
- Processes target cpu and features in the flang driver. Right now
features are only added for AArch64/x86 because I only did basic
testing on them but it should generally work for others as well.
Option handling is similar to clang.
- Adds appropriate structures in TargetOptions and passes them to
the target machine.
What's missing:
- Adding the CPU info and the features as attributes in the LLVM IR
module.
- Processing target specific flags, e.g. SVE vector bits for AArch64,
ABI etc.
Differential Revision: https://reviews.llvm.org/D137995
Change-Id: Ib081a74ea98617674845518a5d2754edba596418
This patch enables context sensitive PGO (CSPGO) for LTO on AIX. Two parts are involved:
# Frontend logic is added so libLTO can understand the CSPGO related options.
# Two options are added to the backend so that the LTOCodeGenerator can understand the CSPGO related options and make use of them.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D138854
It broke the build, see comments on code review.
> Leaves the implementation and tests files in-place for right now, but
> deletes the ability to build the old sanitizer-common based scudo. This
> has been on life-support for a long time, and the newer scudo_standalone
> is much better supported and maintained.
>
> Also patches up some GWP-ASan wording, primarily related to the fact
> that -fsanitize=scudo now is scudo_standalone, and therefore the way to
> reference the GWP-ASan options through the environment variable has
> changed.
>
> Future follow-up patches will delete the original scudo, and migrate all
> its tests over to be part of the scudo_standalone test suite.
>
> Reviewed By: vitalybuka
>
> Differential Revision: https://reviews.llvm.org/D138157
This reverts commit ab1a5991fe765d71c0f3262f25726d6b4d66a545.
Leaves the implementation and tests files in-place for right now, but
deletes the ability to build the old sanitizer-common based scudo. This
has been on life-support for a long time, and the newer scudo_standalone
is much better supported and maintained.
Also patches up some GWP-ASan wording, primarily related to the fact
that -fsanitize=scudo now is scudo_standalone, and therefore the way to
reference the GWP-ASan options through the environment variable has
changed.
Future follow-up patches will delete the original scudo, and migrate all
its tests over to be part of the scudo_standalone test suite.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D138157
For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from
the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template.
This change makes `--` long option diagnostics more convenient.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D137659
We may need hosted Clang/LLVM to compile and `getHostCpuName`
can be used for native detection.
Tests are added in riscv-cpus.c just like what AArch64/PPC
have done.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D136930
We've been working around this for a long time in the Linux kernel; we
bend over backwards to continue to support CC=clang (w/
-fno-integrated-as) for architectures where clang can't yet be used to
assemble the kernel's assembler sources. Supporting debug info for the
combination of CC=clang w/ GNU binutils as "GAS" has been painful.
Fix this in clang so that we can work towards dropping complexity in the
Linux kernel's build system, Kbuild, for supporting this combination of
tools.
GAS added support for -gdwarf-{3|4|5} in 2020 2.35 release via
commit 31bf18645d98 ("Add support for --dwarf-[3|4|5] to assembler command line.")
Refactor code to share logic between integrated-as and non-integrated-as
for determining the implicit default. This change will now always
explicitly pass a -gdwarf-* flag to the GNU assembler when -g is
specified.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D136707
On AIX, `strict-dwarf` defaults to `true`. This patch implement this default behaviour. Additionally, it adds debug tuning tests.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D135908
When -lxxx is specified, if there happens to have a directory or
file with name xxx, clang will not look up libxxx.a, but will
try to unbundle xxx instead.
Reviewed by: Saiyedul Islam, Artem Belevich
Differential Revision: https://reviews.llvm.org/D135724
This patch teaches `clang` to use the prefix `-bplugin_opt:` (instead of `-plugin-opt`) on AIX, when passing plugin options to the linker. This patch follows https://reviews.llvm.org/D134668.
We put the code that decides what plugin option prefix to use at the top of the function `tools::addLTOOptions`. The plugin option prefix, the mcpu prefix, and the opt level prefix are different on AIX. We thought about choosing the strings in a function that reads the linker name and the target triple, or we could push the logic into different derived `ToolChain` classes. But this logic would not be used anywhere else, so these alternatives looked too complicated for what they did. Therefore we are doing it the current way. That said, I am all ears for suggestions to improve this code!
Subsequent code uses the `PluginOptPrefix` variable consistently instead of the hardcoded `-plugin-opt`.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D134820
Remove the ability to disable opaque pointers by default in clang.
It is still possible to explicitly disable them via cc1
-no-opaque-pointers.
Differential Revision: https://reviews.llvm.org/D135259
The following three static functions in `clang/lib/Driver/ToolChains/CommonArgs.cpp`
```
static void renderRpassOptions(...)
static void renderRemarksOptions(...)
static void renderRemarksHotnessOptions(...)
```
use `--plugin-opt` for the plugin option prefix, while the function `tools::addLTOOptions` uses `-plugin-opt`. This patch makes sure that we only use `-plugin-opt` (single dash) everywhere. It is not clear to me that why we decided to use `--plugin-opt` in https://reviews.llvm.org/D85810. If using `--plugin-opt` is intended, I'd love to hear the reason and I will close this patch.
We intend to followup this patch with a few other patches that teach `clang` to pass plugin options to the AIX linker, which uses a different prefix (`-bplugin_opt:`).
Reviewed By: w2yehia
Differential Revision: https://reviews.llvm.org/D134668
HIP is able to unbundle archive of bundled bitcode.
However currently there are two bugs:
1. archives passed by -l: are not unbundled.
2. archives passed as input files are not unbundled
The actual file name of an archive passed by -l: should
not be prefixed with lib and appended with '.a',
but the file path is prefixed with paths in '-L' options.
The actual file name of an archive passed as an input file
stays the same, not affected by the '-L' options.
Right now in case of LTO the section is not emited:
$ cat test.c
void __attribute__((optnone)) bar()
{
}
void __attribute__((optnone)) foo()
{
bar();
}
int main()
{
foo();
}
$ clang -flto=thin -gdwarf-aranges -g -O3 test.c
$ eu-readelf -waranges a.out | fgrep -c -e foo -e bar
0
$ clang -gdwarf-aranges -g -O3 test.c
$ eu-readelf -waranges a.out | fgrep -c -e foo -e bar
2
Fix this by passing explicitly -mllvm -generate-arange-section.
P.S. although this looks like a hack, since none of -mllvm was passed to
the lld before.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
Suggested-by: OCHyams <orlando.hyams@sony.com>
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D133092
We're seeing the following warnings with --rtlib=compiler-rt:
lld-link: warning: ignoring unknown argument '--as-needed'
lld-link: warning: ignoring unknown argument '-lunwind'
lld-link: warning: ignoring unknown argument '--no-as-needed'
MSVC doesn't use the unwind library, so just omit it.
Differential Revision: https://reviews.llvm.org/D132440
Normally, passing -rtlib=platform overrides any earlier -rtlib
options, and overrides any hardcoded CLANG_DEFAULT_RTLIB option.
However, some targets, MSVC and Darwin, have custom logic for
disallowing specific -rtlib= option values; amend these checks for
allowing the -rtlib=platform option.
Differential Revision: https://reviews.llvm.org/D132444
We're seeing the following warnings with --rtlib=compiler-rt:
lld-link: warning: ignoring unknown argument '--as-needed'
lld-link: warning: ignoring unknown argument '-lunwind'
lld-link: warning: ignoring unknown argument '--no-as-needed'
MSVC doesn't use the unwind library, so just omit it.
Differential Revision: https://reviews.llvm.org/D132440
This patch does the following:
- Consumes the PIC flags (fPIC/fPIE/fropi/frwpi etc) in flang-new.
tools::ParsePICArgs() in ToolChains/CommonArgs.cpp is used for this.
- Adds FC1Option to "-mrelocation-model", "-pic-level", and "-pic-is-pie"
command line options.
- Adds the above options to flang/Frontend/CodeGenOptions' data structure.
- Sets the relocation model in the target machine, and
- Sets module flags for the respective PIC/PIE type in LLVM IR.
I have tried my best to replicate how clang does things.
Differential Revision: https://reviews.llvm.org/D131533
Change-Id: I68fe64910be28147dc5617826641cea71b92d94d
Use this instead of `*_LIBDIR_SUFFIX`, from which it is computed.
This gets us ready for D130586, in which `*_LIBDIR_SUFFIX` is
deprecated.
Differential Revision: https://reviews.llvm.org/D132300
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
To make use of SPARC support in `getHostCPUName` as implemented by D130272
<https://reviews.llvm.org/D130272>, this patch uses it to handle
`-mcpu=native` and `-mtune=native`. To match GCC, this patch rejects
`-march` instead of silently treating it as a no-op.
Tested on `sparcv9-sun-solaris2.11` and checking that those options are
passed on as `-target-cpu` resp. `-tune-cpu` as expected.
Differential Revision: https://reviews.llvm.org/D130273
This patch changes legacy LTO to set data-sections by default. The user can
explicitly unset data-sections. The reason for this patch is to match the
behaviour of lld and gold plugin. Both lld and gold plugin have data-sections on
by default.
This patch also fixes the forwarding of the clang options -fno-data-sections and
-fno-function-sections to libLTO. Now, when -fno-data/function-sections are
specified in clang, -data/function-sections=0 will be passed to libLTO to
explicitly unset data/function-sections.
Reviewed By: w2yehia, MaskRay
Differential Revision: https://reviews.llvm.org/D129401
This patch changes legacy LTO to set data-sections by default. The user can
explicitly unset data-sections. The reason for this patch is to match the
behaviour of lld and gold plugin. Both lld and gold plugin have data-sections on
by default.
This patch also fixes the forwarding of the clang options -fno-data-sections and
-fno-function-sections to libLTO. Now, when -fno-data/function-sections are
specified in clang, -data/function-sections=0 will be passed to libLTO to
explicitly unset data/function-sections.
Reviewed By: w2yehia, MaskRay
Differential Revision: https://reviews.llvm.org/D129401
Normally we do not link the device libraries if the user passed
`nogpulib` we do this for the standard bitcode library. This behaviour
was not added when using the static library for LTO, causing it to
always be linked in. This patch fixes that.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D129534
With libgcc, we follow the behavior of GCC for backwards compatibility,
only using --as-needed in the non-C++ mode.
With libunwind, there are no backward compatibility requirements so we
can always use --as-needed on all supported platforms.
Differential Revision: https://reviews.llvm.org/D128841
With libgcc, we follow the behavior of GCC for backwards compatibility,
only using --as-needed in the non-C++ mode.
With libunwind, there are no backward compatibility requirements so we
can always use --as-needed on all supported platforms.
Differential Revision: https://reviews.llvm.org/D128841
