This patch is spamming compiles with unhelpful and confusing messages.
E.g. the Linux kernel uses "grep -q" in several places. It's meant to
quit with a return code of zero when the first match is found. This can
cause a SIGPIPE signal, but that's expected, and there's no way to turn
this error message off to avoid spurious error messages.
UNIX03 apparently doesn't require printing an error message on SIGPIPE,
but specifically when there's an error on the stdout stream in a normal
program flow, e.g. when SIGPIPE trap is disabled.
A separate patch is planned to address the specific case we care most
about (involving llvm-nm).
This reverts commit b89bcefa62.
Link: https://github.com/llvm/llvm-project/issues/59037
Link: https://github.com/ClangBuiltLinux/linux/issues/1651
Differential Revision: https://reviews.llvm.org/D138244
The invalid case is now represented by an empty StringRef rather than
a nullptr.
Previously ARCH_FEATURE was build from SUB_ARCH by prepending "+".
This is now reverse, so that the "+arch-feature" is now visible in
the .def, which is a bit clearer. This meant converting one StringSwitch
into a loop.
Removed getters which are now mostly unnecessary.
Removed some old FIXMEs.
Differential Revision: https://reviews.llvm.org/D138026
Users may partition parameters specified by configuration file and put
different groups into separate files. These files are inserted into the
main file using constructs `@file`. Relative file names in it are
resolved relative to the including configuration file and this is not
convenient in some cases. A configuration file, which resides in system
directory, may need to include a file with user-defined parameters and
still provide default definitions if such file is absent.
To solve such problems, the option `--config=` is allowed inside
configuration files. Like `@file` it results in insertion of
command-line arguments but the algorithm of file search is different and
allows overriding system definitions with user ones.
Differential Revision: https://reviews.llvm.org/D136354
NVIDIA, ARM, and Intel recently introduced two new FP8 formats, as described in the paper: https://arxiv.org/abs/2209.05433. The first of the two FP8 dtypes, E5M2, was added in https://reviews.llvm.org/D133823. This change adds the second of the two: E4M3.
There is an RFC for adding the FP8 dtypes here: https://discourse.llvm.org/t/rfc-add-apfloat-and-mlir-type-support-for-fp8-e5m2/65279. I spoke with the RFC's author, Stella, and she gave me the go ahead to implement the E4M3 type. The name of the E4M3 type in APFloat is Float8E4M3FN, as discussed in the RFC. The "FN" means only Finite and NaN values are supported.
Unlike E5M2, E4M3 has different behavior from IEEE types in regards to Inf and NaN values. There are no Inf values, and NaN is represented when the exponent and mantissa bits are all 1s. To represent these differences in APFloat, I added an enum field, fltNonfiniteBehavior, to the fltSemantics struct. The possible enum values are IEEE754 and NanOnly. Only Float8E4M3FN has the NanOnly behavior.
After this change is submitted, I plan on adding the Float8E4M3FN type to MLIR, in the same way as E5M2 was added in https://reviews.llvm.org/D133823.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D137760
AArch64TargetParser reuses data structures and some data from ARMTargetParser,
which causes more problems than it solves. This change separates them.
Code which is common to ARM and AArch64 is moved to ARMTargetParserCommon
which both ARMTargetParser and AArch64TargetParser use.
Some of the information in AArch64TargetParser.def was unused or nonsensical
(CPU_ATTR, ARCH_ATTR, ARCH_FPU) because it reused data strutures from
ARMTargetParser where some of these make sense. These are removed.
Differential Revision: https://reviews.llvm.org/D137924
Fix a assertion in dsymutil coming from the Reproducer/FileCollector.
When TMPDIR is empty, the root becomes a relative path, triggering an
assertion when adding a relative path to the VFS mapping. This patch
fixes the issue by resolving the relative path and also moves the
assertion up to make it easier to diagnose these issues in the future.
rdar://102170986
Differential revision: https://reviews.llvm.org/D137959
Fix a assertion in dsymutil coming from the Reproducer/FileCollector.
When TMPDIR is empty, the root becomes a relative path, triggering an
assertion when adding a relative path to the VFS mapping. This patch
fixes the issue by resolving the relative path and also moves the
assertion up to make it easier to diagnose these issues in the future.
rdar://102170986
Differential revision: https://reviews.llvm.org/D137959
OpenGroup specification doesn't require getpwuid and getpwnam
to be thread-safe. And musl libc has a not thread-safe implementation.
When building clang with musl, this can make clang-scan-deps crash.
Reviewed By: pirama
Differential Revision: https://reviews.llvm.org/D137864
This change provides an implementation of the XVentanaCondOps vendor extension. This extension is defined in version 1.0.0 of the VTx-family custom instructions specification (https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf) by Ventana Micro Systems.
In addition to the technical contribution, this change is intended to be a test case for our vendor extension policy.
Once this lands, I plan to use this extension to prototype selection lowering to conditional moves. There's an RVI proposal in flight, and the expectation is that lowering to these and the new RVI instructions is likely to be substantially similar.
Differential Revision: https://reviews.llvm.org/D137350
A specific case for ThinLTO cache pruning is that the current build is huge, and the cache wasn't big enough to hold the intermediate object files of that build. So in doing that build, a file would be cached, and later in that same build it would be evicted. This was significantly decreasing the effectiveness of the cache. By giving this warning, the user could identify the required cache size/files and improve ThinLTO link speed.
Differential Revision: https://reviews.llvm.org/D135590
Underlying data may have requirements/expectations/etc. about
the run-time alignment. WritableMemoryBuffer currently uses
a 16 byte alignment, which works for many situations but not all.
Allowing a desired alignment makes it easier to reuse WritableMemoryBuffer
in situations of special alignment, and also removes a problem when
opening files with special alignment constraints. Large files generally
get mmaped, which has ~page alignment, but small files go through
WritableMemoryBuffer which has the much smaller alignment guarantee.
Differential Revision: https://reviews.llvm.org/D137820
The canonical multiarch tuples for LoongArch are defined in [the
LoongArch toolchain conventions][1] document. As the musl port is still
WIP, only the GNU triples are added for now.
The spec mentions `loongarch64-linux-gnuf64`, which is functionally the
same as the existing `loongarch64-linux-gnu` triple, only with the
floating-point ABI part explicitly spelled out. Both forms are
supported, but normalization of one into another is not implemented in
this patch, to give the ecosystem some time to experiment and discuss.
[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D135751
This is very backend specific so either belongs in Toolchains/ARM or in
ARMTargetParser. Since it is used in lldb, ARMTargetParser made more sense.
This is part of an effort to move information about ARM/AArch64 architecture
versions, extensions and CPUs into their respective TargetParsers.
Differential Revision: https://reviews.llvm.org/D137564
This was done as a test for D137302 and it makes sense to push these changes
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D137493
* Set LLVM_ATOMIC_LIB to keep track of when we need to link against libatomic.
* Add detection of mold linker which is required for this.
* Use --as-needed when linking against libatomic as a bonus. On some platforms,
libatomic may be required only sometimes.
Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136280
As now errors in file operation are handled, check for file existence
must be done prior to check for recursion, otherwise reported errors are
misleading.
Differential Revision: https://reviews.llvm.org/D136090
This change modifies the implementation of the format() function
so that vendor forks committed to building with compilers that
support __attribute__((format)) on non-variadic functions can
check the format() function with it.
rdar://84571523
Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.
This change enhances handling errors in the expansion so that users
could get more informative error messages.
Differential Revision: https://reviews.llvm.org/D136090
[Re-submit after earlier revert due to a test failure. Commit dce78646f0
("clang-tblgen build: avoid duplicate inclusion of libLLVMSupport")
is believe to address the root cause of the test failure.]
Follow the pattern used in MLIR for the cl::opt instances.
v2:
- make DebugCounter::isCountingEnabled public so that the
DebugCounterOwner doesn't have to be a nested class. This simplifies
later changes
v3:
- remove the indirection via DebugCounterOwner::instance()
Differential Revision: https://reviews.llvm.org/D129116
Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.
This change enhances handling errors in the expansion so that users
could get more informative error messages.
Differential Revision: https://reviews.llvm.org/D136090
It splited into several zb* extensions, and `b` is dropped after
0.93, so it time to retired that as other non-ratified zb* extensions.
Currntly clang can accept that with warning:
$ clang -target riscv64-elf ~/hello.c -S -march=rv64gcb
'+b' is not a recognized feature for this target (ignoring feature)
'+b' is not a recognized feature for this target (ignoring feature)
'+b' is not a recognized feature for this target (ignoring feature)
Reviewed By: asb, luismarques
Differential Revision: https://reviews.llvm.org/D136812
While profiling InclusionRewriter, it was found that counting lines was
so slow that it took up 20% of the processing time. Surely, calling
memcmp() of size 1 on every substring in the window isn't a good idea.
Use StringRef::find() instead; in the case of N=1 it will forward to
memcmp which is much more optimal. For 2<=N<256 it will run the same
memcmp loop as we have now, which is still suboptimal but at least does
not regress anything.
Differential Revision: https://reviews.llvm.org/D133658
This change modifies the implementation of the format() function
so that vendor forks committed to building with compilers that
support __attribute__((format)) on non-variadic functions can
check the format() function with it.
Reviewed By: ahatanak
Differential Revision: https://reviews.llvm.org/D132413
rdar://84571523
This adds AArch64 TargetParser support to define CPU aliases, and
ports the definition of Grace over to that. This is following up
on D136425.
Differential Revision: https://reviews.llvm.org/D136611
As a continuation of D132034, this switches the QRDMX v8.1a neon
intrinsics over from preprocessor defines to be target-gated. As there
is no "rdma" or "qrdmx" target feature, they use the "v8.1a"
architecture feature directly.
This works well for AArch64, but something needs to be done for Arm at
the same time, as they both use the same header and tablegen emitter.
This patch opts for adding "v8.1a" and all dependant target features to
the Arm TargetParser, similar to what was recently done for AArch64 but
through initFeatureMap when the Architecture is parsed. I attempted to
make the code similar to the AArch64 backend.
Otherwise this is similar to the changes made in D132034.
Differential Revision: https://reviews.llvm.org/D135615
Bill Wendling