Show line numbers to the left of diagnostic code snippets and increase
the numbers of lines shown from 1 to 16.
Differential Revision: https://reviews.llvm.org/D147875
These tests should have added -std=c++23 instead of replacing -std=c++2b
in D149553.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D150063
This patch add the instructions of zcmp extension.
Instructions in zcmp extension try to optimise `mv` inst and the prologue & epilogue in functions
co-author: @Scott Egerton, @ZirconLiu, @Lukacma, @Heda Chen, @luxufan, @heyiliang, @liaochunyu
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D132819
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
Clang was writing paths to the dependency file that don't exist when using a sysroot with symlinks, causing everything to get rebuilt every time. This is reproducible on Linux by creating a symlink to '/', using that as the sysroot, and trying to build something with ninja that includes the C++ stdlib (e.g. a typical build of LLVM).
This fixes https://github.com/ninja-build/ninja/issues/1330 and somewhat matches gcc.
gcc canonicalizes system headers in dependency files under a -f[no-]canonical-system-headers, but it makes more sense to look at -canonical-prefixes.
D37954 was a previous attempt at this.
Fixed use of %T instead of %t in test, causing bots to fail the test on the initial commit.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D149187
Clang was writing paths to the dependency file that don't exist when using a sysroot with symlinks, causing everything to get rebuilt every time. This is reproducible on Linux by creating a symlink to '/', using that as the sysroot, and trying to build something with ninja that includes the C++ stdlib (e.g. a typical build of LLVM).
This fixes https://github.com/ninja-build/ninja/issues/1330 and somewhat matches gcc.
gcc canonicalizes system headers in dependency files under a -f[no-]canonical-system-headers, but it makes more sense to look at -canonical-prefixes.
D37954 was a previous attempt at this.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D149187
The multiple-include optimization allows Clang to avoid opening a
files when they contain #pragma once or a proper include guard.
Both GCC and Microsoft Visual Studio allow null directives outside of
the #ifndef/#endif pair without disabling this multiple-include
optimization. GCC documents this behavior here
https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html.
> There must be no directives outside the controlling directive pair,
> but the null directive (a line containing nothing other than a
> single '#' and possibly whitespace) is permitted.
However, Clang disables the multiple-include optimization when
encountering the null directive.
In particular, this slows down preprocessing of most projects that
depend on boost as many boost libraries depend on the boost
preprocessor library, which contains null directives outside the
include guard on every header file.
Differential Revision: https://reviews.llvm.org/D147928
Update the Zvk support from 0.3.x to 0.5.1, tracking the extension as
documented in
<https://github.com/riscv/riscv-crypto/releases/download/v20230407/riscv-crypto-spec-vector.pdf>.
- Zvkb is split into Zvbb and Zvbc
- Zvbc (vector carryless multiply) requires 64 bit elements (Zve64x)
- Use the extension descriptions from the specification for Zvbb/Zvbc
- Zvkt is introduced (no instructions, but adds an attribute and macro)
- Zvkn and Zvks both imply Zvkt
- Zvkng and Zvksg are introduced, adding Zvkg (GMAC) to Zvkn and Zvks
- In Zvbb, add vrev.v, vclz.v, vctz.v, vcpop.v, vwsll.{vv,vx,vi}
Differential Revision: https://reviews.llvm.org/D148483
As of
1f03818281
in the riscv-isa-manual, Zfa is at version 0.2. Reviewing the commit
history for
zfa.tex
<https://github.com/riscv/riscv-isa-manual/commits/master/src/zfa.tex>
there are no relevant changes since 0.1. As such, we can simply
increment the version number.
This change also removes the claim in RISCVUsage that we implement a
"subset of" Zfa, as I believe this is no longer true. That sentence
previously incorrectly claimed we didn't implement fli.{h,s,d} (I
[corrected this a couple of weeks
ago](https://reviews.llvm.org/rG3d969191b277)) but I think should have
removed the "subset of" wording too.
As was noted during the review, we never added Zfa to the release notes.
This is corrected in this patch.
Differential Revision: https://reviews.llvm.org/D148634
New versions I2.1, F2.2, D2.2 A2.1
Make F and Zfinx imply Zicsr.
Make G imply Zifencei.
This should have no impact to generated code. We have no plans to require Zicsr/Zifencei extension to be explicitly enabled to use Zicsr/Zifencei instructions in assembly.
See https://reviews.llvm.org/D147183 for documentation regarding what version specification we implement.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D147179
Currently when in -CC mode when processing a function like macro
ReadMacroParameterList(...) does not handle the case where there is a comment
embedded in the parameter-list.
Instead of using LexUnexpandedToken(...) I switched to using
LexUnexpandedNonComment(...) which eats comments while lexing.
Fixes: https://github.com/llvm/llvm-project/issues/60887
Differential Revision: https://reviews.llvm.org/D144511
This patch adds the basic MC layer support for Zicond, based on
[1.0-rc1](https://github.com/riscv/riscv-zicond/releases/tag/v1.0-rc1).
As with other extensions, if there are additional changes between
release candidates without incrementing the version number we won't be
able to reflect that in the version number. I believe we've previously
decided this is not a problem for extensions still considered
experimental (i.e. not yet ratified).
Differential Revision: https://reviews.llvm.org/D146946
POWER Darwin support in the backend has been removed for some time: https://discourse.llvm.org/t/rfc-remove-darwin-support-from-power-backends
but Clang still has the TargetInfo and other remnants lying around.
This patch does some cleanup and removes those and other related frontend support still remaining. We adjust any tests using the triple to either remove
the test if unneeded or switch to another Power triple.
Reviewed By: MaskRay, nemanjai
Differential Revision: https://reviews.llvm.org/D146459
Add a clang part of OpenHarmony target
Related LLVM part: D138202
~~~
Huawei RRI, OS Lab
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145227
Add '__builtin_FILE_NAME()', which expands to the filename because the
full path is not always needed. It corresponds to the '__FILE_NAME__'
predefined macro and is consistent with the other '__builin' functions
added for predefined macros.
Differential Revision: https://reviews.llvm.org/D144878
The issue was introduced in D135801. When there are only header maps in the SearchDirs,
the out of bounds value is assigned to FirstNonHeaderMapSearchDirIdx.
Test Plan: check-clang
Differential Revision: https://reviews.llvm.org/D146156
This change had tests that break whenever LLVM_ENABLE_LINKER_BUILD_ID is
set, as is the case in the Fuchsia target.
This reverts commits:
f81317a54572474afa27
Add a clang part of OpenHarmony target
Related LLVM part: D138202
~~~
Huawei RRI, OS Lab
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145227
On some R-profile CPUs, leaving out the FPU is an option. Clang will
accept `-march=armv8-r+nofp`, but it's currently not possible to find
out via the preprocessor whether it's in that mode (e.g. to change or
disable inline asm statements in your code).
The __ARM_FP macro, which has a bit set for each size of floating
point number supported by the hardware, is the natural thing to test.
But Clang was defining it unconditionally on AArch64. Now it checks
for FP support before defining it at all.
Reviewed By: tmatheson, DavidSpickett
Differential Revision: https://reviews.llvm.org/D145781
Setting __FLT_EVAL_METHOD__ to -1 with fast-math will set
__GLIBC_FLT_EVAL_METHOD to 2 and long double ends up being used for
float_t and double_t. This creates some ABI breakage with various C libraries.
See details here: https://github.com/llvm/llvm-project/issues/60781
This reverts commit bbf0d1932a.
GNU line marker directives are not recognised when preprocessing
assembly files, meaning they can't be used in the predefines file
meaning macros defined on the command line are reported as being
built-in.
Change this to permit line markers but only in the predefines file,
so we can correctly report command line macros as coming from the
command line.
Differential Revision: https://reviews.llvm.org/D145397
Support for the unratified 1.0-rc3 specification was introduced in
D133443. The specification has since been ratified (in November 2022
according to the recently ratified extensions list
<https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions>.
A review of the diff
<https://github.com/riscv/riscv-zawrs/compare/V1.0-rc3...main> of the
1.0-rc3 spec vs the current/ratified document shows no changes to the
instruction encoding or naming. At one point, a note was added
<e84f42406a>
indicating Zawrs depends on the Zalrsc extension (not officially
specified, but I believe to be just the LR/SC instructions from the A
extension). The final text ended up as "The instructions in the Zawrs
extension are only useful in conjunction with the LR instructions, which
are provided by the A extension, and which we also expect to be provided
by a narrower Zalrsc extension in the future." I think it's consistent
with this phrasing to not require the A extension for Zawrs, which
matches what was implemented.
No intrinsics are implemented for Zawrs currently, meaning we don't need
to additionally review whether those intrinsics can be considered
finalised and ready for exposure to end users.
Differential Revision: https://reviews.llvm.org/D143507
Experimental support for the zfa extension was recently added in https://reviews.llvm.org/D141984. A couple of the normal test changes and clang plumbing got missed in that change. This commit updates the usual suspects.
Differential Revision: https://reviews.llvm.org/D144288
Currently the implementation of __VA_OPT__ will treat the concatenation of a
non-placemaker token and placemaker token as a placemaker token which is not
correct. This will fix the implementation and treat the result as a
non-placemaker token.
This fixes: https://github.com/llvm/llvm-project/issues/60268
Differential Revision: https://reviews.llvm.org/D142604
This change adds the definition of the two extensions, but does not either a) make any instruction conditional on them or b) enabled the extensions by default. (The *instructions* do remain enabled by default per ISA version 2.0 which is our current default.)
This is meant to be a building block towards something like https://reviews.llvm.org/D141666, and in the meantime, address one of the most surprising of the current user experience warts. The current behavior of rejecting the extensions at the command line despite emitting code which appears to use them is surprising to anyone not deeply versed in the details of this situation.
Between versions 2.0 and 2.1 of the base I specification, a backwards incompatible change was made to remove selected instructions and CSRs from the base ISA. These instructions were grouped into a set of new extensions (these), but were no longer required by the base ISA. This change is described in “Preface to Document Version 20190608-Base-Ratified” from the specification document.
As LLVM currently implements only version 2.0 of the base specification, accepting these extensions at the command line introduces a configuration which doesn't actually match any spec version. It's a pretty harmless variant since the 2.0 extension definitions, to my knowledge, exactly match the text from the 2.0 I text before they were moved into standalone extensions in 2.1 of I. (The version numbering in that sentence is a tad confusing to say the least. Hopefully I got it right.)
It is worth noting that we already have numerous examples of accepting extensions in the march string which didn't exist in version of the spec document corresponding to our current base I version, so this doesn't set any new precedent.
Differential Revision: https://reviews.llvm.org/D143953
Craig Topper pointed out in post-commit review of d05e1e99b1 that the
series of CHECK-NOT lines followed by CHECK would not work as intended
if __riscv_i came first in the input and was followed by the disallowed
lines.
The simplest solution is to just introduced separate RUN lines for the
__riscv_i check.
`CHECK-NOT: __riscv_f 2000000{{$}}` was overly precise, in that it
wouldn't test what we want it to if the version of the F extension was
bumped. Meanwhile, lines like `CHECK-NOT: __riscv_d` were too imprecise,
as they would match any define with that prefix (e.g.
`__riscv_dsomethingelse`).
This patch just updates these lines to check for `__riscv_foo {{.*$}}`.
The current behavior for AMX macros is:
```
gcc -march=native -dM -E - < /dev/null | grep TILE
clang -march=native -dM -E - < /dev/null | grep TILE
```
which is not ideal. Change `__AMXTILE__` and friends to `__AMX_TILE__` (i.e.
have an underscore in them). This makes GCC and Clang agree on the naming of
these AMX macros to simplify downstream user code.
Fix this for `__AMXTILE__`, `__AMX_INT8__`, `__AMX_BF16__`, and `__AMX_FP16__`.
Differential Revision: https://reviews.llvm.org/D143094
Currently negative architecture features passes to clang like -Xclang
-target-feature -Xclang -v9.3a will end up _enabling_ dependant target
features (like FEAT_MOPS). This patch fixes that by ensuring we don't
enable dependant target features when !Enabled.
Fixes#60375
Differential Revision: https://reviews.llvm.org/D142963
This adds a quick check for -neon, making it imply the same as -crypto,
which helps get some features correct in more cases.
Differential Revision: https://reviews.llvm.org/D142988
This replaces AEK_CRYPTO in the AArch64TargetParser definitions,
replacing the composite Crypto features with the constituent parts.
AEK_CRYPTO is replaced with either AEK_AES | AEK_SHA2 or AEK_AES |
AEK_SHA2 | AEK_SHA3 | AEK_SHA4 depending on if the cpu is Arm-v8.4+.
This helps get the features correct in some more places like
target(cpu=..) attributes.
Otherwise this is hopefully an NFC for -mcpu options but seems like a
cleaner design.
Differential Revision: https://reviews.llvm.org/D142548
This patch add the instructions of Zcb extension.
Instructions in zcb extensions shorten part of bit manipulation instructions.
Co-authored-by: Craig Topper <craig.topper@sifive.com>
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D131141
The CPUs never supported SM4 instructions, but until recently I think crypto
was folded into the baseline architecture as a monolithic feature so it was
difficult to represent that. Now it's split we can, and the CPUs that support
v8.4 onwards only handle AES, SHA2, SHA3 by way of crypto instructions.
The Armv8.6-a and later architecture definitions included AES, SHA2,
SHA3 and SM4, but this did not have an effect when specifying
-march=armv8.6-a. The did not set preprocessor features
(https://godbolt.org/z/1YKad6M8e) or enable the relevant instructions
(like eor3 from sha3: https://godbolt.org/z/vY9v4MqvG). Similarly
architectures armv8 to armv8.5 defined +crypto, but this did not effect
the -march's, only the -mcpu with those architectures. I believe this
was working as intended.
After D141411 we now add the default features for architectures except
for +crypto, which has had the effect of enabling aes/sha2/sha3/sm4 when
-march=armv8.6-a is used. This patch removed those crypto features
again, going back to how things were before. It also removes the
AEK_CRYPTO feature from lower architecture levels, moving it to the cpus
that use it. This shouldn't make any changes, but a few extra tests have
been added for preprocessor features that have improved since llvm 15.
The -mcpu=ampere1 cpu is the only armv8.6+ cpu at present. For that, the
AES, SHA2 and SHA3 features have been re-added to the CPU definition to
keep it in-line with the gcc definition from
db2f5d6612.
Differential Revision: https://reviews.llvm.org/D141606
Reworked after several other major changes to the TargetParser since
this was reverted. Combined with several other changes.
Inline calls for the following macros and delete AArch64TargetParser.def:
AARCH64_ARCH, AARCH64_CPU_NAME, AARCH64_CPU_ALIAS, AARCH64_ARCH_EXT_NAME
Squashed changes from D139278 and D139102.
Differential Revision: https://reviews.llvm.org/D138792
