[LLVM] [Clang] Support for Gentoo `*t64` triples (64-bit time_t ABIs) (#111302)

Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `ti

[LLVM] [Clang] Support for Gentoo `*t64` triples (64-bit time_t ABIs) (#111302)

Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.

An open question is whether we can backport this to LLVM 19.x. After
all, adding new triplets to Triple sounds like an ABI change — though I
suppose we can minimize the risk of breaking something if we move new
enum values to the very end.

show more ...

[ARM][AArch64] Introduce the Armv9.6-A architecture version (#110825)

This introduces the Armv9.6-A architecture version, including the
relevant command-line option for -march.

More details abou

[ARM][AArch64] Introduce the Armv9.6-A architecture version (#110825)

This introduces the Armv9.6-A architecture version, including the
relevant command-line option for -march.

More details about the Armv9.6-A architecture version can be found at:
* https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2024
* https://developer.arm.com/documentation/ddi0602/2024-09/

show more ...

[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber Stri

[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".

show more ...

Revert "[ARM] __ARM_ARCH macro definition fix (#81493)"

This reverts commit 89c1bf1230e011f2f0e43554c278205fa1819de5.

This has been unimplemenented for a while, and GCC does not implement
it, there

Revert "[ARM] __ARM_ARCH macro definition fix (#81493)"

This reverts commit 89c1bf1230e011f2f0e43554c278205fa1819de5.

This has been unimplemenented for a while, and GCC does not implement
it, therefore we need to consider whether we should just deprecate it
in the ACLE instead.

show more ...

[ARM] __ARM_ARCH macro definition fix (#81493)

This patch changes how the macro __ARM_ARCH is defined to match its
defintion in the ACLE. In ACLE 5.4.1, __ARM_ARCH is defined as equal to
the major

[ARM] __ARM_ARCH macro definition fix (#81493)

This patch changes how the macro __ARM_ARCH is defined to match its
defintion in the ACLE. In ACLE 5.4.1, __ARM_ARCH is defined as equal to
the major architecture version for ISAs up to and including v8. From
v8.1 onwards, its definition is changed to include minor versions, such
that for an architecture vX.Y, __ARM_ARCH = X*100 + Y. Before this
patch, LLVM defined __ARM_ARCH using only the major architecture version
for all architecture versions. This patch adds functionality to define
__ARM_ARCH correctly for architectures greater than or equal to v8.1.

show more ...

[ARM] Introduce the v9.5-A architecture version to Arm targets (#78994)

This introduces the Armv9.5-A architecture version to the Arm backend,
following on from the existing implementation for AArc

[ARM] Introduce the v9.5-A architecture version to Arm targets (#78994)

This introduces the Armv9.5-A architecture version to the Arm backend,
following on from the existing implementation for AArch64 targets.

Mode details about the Armv9.5-A architecture version can be found at:
* https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2023
* https://developer.arm.com/documentation/ddi0602/2023-09/

show more ...

[llvm] Teach MachO about XROS (#78373)

Add support for XROS to encode in Mach-O file formats.

[llvm] Use StringRef::consume_front (NFC)

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[Clang][OHOS] Keep ARM ABI selection logic in sync between Clang and LLVM (#68656)

[ARM] fix "+fp.dp" in multilib selection (#67412)

When the FPU was selected with "+(no)fp(.dp)" extensions in "-march" or
"-mcpu" options, the FPU used for multilib selection was still the
default

[ARM] fix "+fp.dp" in multilib selection (#67412)

When the FPU was selected with "+(no)fp(.dp)" extensions in "-march" or
"-mcpu" options, the FPU used for multilib selection was still the
default one for given architecture or CPU.

show more ...

[Driver] Hook up Haiku ARM support (#67222)

[clang] Enable descriptions for --print-supported-extensions (#66715)

Enables summary descriptions along with the names of the feature.
Descriptions here are simply looked up via the available llvm

[clang] Enable descriptions for --print-supported-extensions (#66715)

Enables summary descriptions along with the names of the feature.
Descriptions here are simply looked up via the available llvm tablegen
data.

show more ...

[clang][ARM] Enable --print-supported-extensions for ARM (#66083)

```
$ ./bin/clang --target=arm-linux-gnueabihf --print-supported-extensions
<...>
All available -march extensions for ARM

[clang][ARM] Enable --print-supported-extensions for ARM (#66083)

```
$ ./bin/clang --target=arm-linux-gnueabihf --print-supported-extensions
<...>
All available -march extensions for ARM

crc
crypto
sha2
aes
dotprod
<...>
```

This follows the format set by RISC-V and AArch64. As for AArch64, ARM
doesn't have versioned extensions like RISC-V does. So there is only 1
column, which contains the name.

Any extension without a "feature" is hidden as these cannot be used with
-march.

show more ...

[ARM][NFC] Use FPUKind enum instead of unsigned

Also rename some FPUID variables to FPUKind now it's clear that's what
they are.

Differential Revision: https://reviews.llvm.org/D146141

[Driver][FreeBSD] Simplify ARM handling

Since FreeBSD 8 / 9 support was dropped from the Driver there is room to simplify
things with the ARM handling.

The exception model handling function can be

[Driver][FreeBSD] Simplify ARM handling

Since FreeBSD 8 / 9 support was dropped from the Driver there is room to simplify
things with the ARM handling.

The exception model handling function can be removed.

EABI is now the default.

Reviewed By: dim

Differential Revision: https://reviews.llvm.org/D144823

show more ...

[OHOS] Add support for OpenHarmony

Add support for OpenHarmony OS

General OpenHarmony OS discussion on discourse thread "[RFC] Add support for OpenHarmony OS"
https://discourse.llvm.org/t/rfc-add-s

[OHOS] Add support for OpenHarmony

Add support for OpenHarmony OS

General OpenHarmony OS discussion on discourse thread "[RFC] Add support for OpenHarmony OS"
https://discourse.llvm.org/t/rfc-add-support-for-openharmony-os/66656

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D138202

show more ...

[Support] Move TargetParsers to new component

This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
componen

[Support] Move TargetParsers to new component

This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.

And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM

Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.

If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.

Differential Revision: https://reviews.llvm.org/D137838

show more ...