[X86] Use a range-based for loop (NFC) (#103519)

[Driver,CodeGen] Report error when enabling 64-bit-only features on non-64-bit arch (#101151)

In front-end, now we detect for `-mapx-features=/-mapxf` and `-muintr`,
which is aligned with GCC

ht

[Driver,CodeGen] Report error when enabling 64-bit-only features on non-64-bit arch (#101151)

In front-end, now we detect for `-mapx-features=/-mapxf` and `-muintr`,
which is aligned with GCC

https://gcc.gnu.org/bugzilla/attachment.cgi?id=58698&action=diff

In backend, we just disable these 64-bit-only features silently, so that
there is no error for
`-march=native -m32` on APX-supported arch.

llvm-issue: https://github.com/llvm/llvm-project/issues/94810
GCC thread: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115978

show more ...

Remove support for 3DNow!, both intrinsics and builtins. (#96246)

This set of instructions was only supported by AMD chips starting in
the K6-2 (introduced 1998), and before the "Bulldozer" family

Remove support for 3DNow!, both intrinsics and builtins. (#96246)

This set of instructions was only supported by AMD chips starting in
the K6-2 (introduced 1998), and before the "Bulldozer" family
(2011). They were never much used, as they were effectively superseded
by the more-widely-implemented SSE (first implemented on the AMD side
in Athlon XP in 2001).

This is being done as a predecessor towards general removal of MMX
register usage. Since there is almost no usage of the 3DNow!
intrinsics, and no modern hardware even implements them, simple
removal seems like the best option.

(Clang half originally uploaded in https://reviews.llvm.org/D94213)

Works towards issue #41665 and issue #98272.

show more ...

[IR] Don't include Module.h in Analysis.h (NFC) (#97023)

Replace it with a forward declaration instead. Analysis.h is pulled in
by all passes, but not all passes need to access the module.

Revert "[X86] Use generic CPU tuning when tune-cpu is empty" (#93436)

Reverts llvm/llvm-project#83631

Using `HasX86_64` is incorrect.

[X86] Use generic CPU tuning when tune-cpu is empty (#83631)

[NFC] Remove unused parameter from shouldAssumeDSOLocal()

[X86] Fix referencing local tagged globals

We should treat the medium code model like the small code model.
Classifying non-local references already properly handled this.

Re-Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)

For non-GlobalValue references, the small and medium code models can use
32 bit constants.

Re-Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)

For non-GlobalValue references, the small and medium code models can use
32 bit constants.

For GlobalValue references, use TargetMachine::isLargeGlobalObject().
Look through aliases for determining if a GlobalValue is small or large.
Even the large code model can reference small objects with 32 bit
constants as long as we're in no-pic mode, or if the reference is offset
from the GOT.

Original commit broke the build...

First reland broke large PIC builds referencing small data since it was using GOTOFF as a 32-bit constant.

show more ...

Revert "Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)"

This reverts commit ec92d74a0ef89b9dd46aee6ec8aca6bfd3c66a54.

Breaks some compiler-

Revert "Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)"

This reverts commit ec92d74a0ef89b9dd46aee6ec8aca6bfd3c66a54.

Breaks some compiler-rt tests, e.g. https://lab.llvm.org/buildbot/#/builders/37/builds/28834

show more ...

Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)

For non-GlobalValue references, the small and medium code models can use
32 bit constants.

F

Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)

For non-GlobalValue references, the small and medium code models can use
32 bit constants.

For GlobalValue references, use TargetMachine::isLargeGlobalObject().
Look through aliases for determining if a GlobalValue is small or large.
Even the large code model can reference small objects with 32 bit
constants as long as we're in no-pic mode, or if the reference is offset
from the GOT.

Original commit broke the build...

show more ...

Revert "[X86] Respect code models more when determining if a global reference can fit in 32 bits" (#75500)

Reverts llvm/llvm-project#75386

Breaks build.

[X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)

For non-GlobalValue references, the small and medium code models can use
32 bit constants.

For G

[X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)

For non-GlobalValue references, the small and medium code models can use
32 bit constants.

For GlobalValue references, use TargetMachine::isLargeGlobalObject().
Look through aliases for determining if a GlobalValue is small or large.
Even the large code model can reference small objects with 32 bit
constants as long as we're in no-pic mode, or if the reference is offset
from the GOT.

show more ...

[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 ...

Reland [X86] With large code model, put functions into .ltext with large section flag (#73037)

So that when mixing small and large text, large text stays out of the
way of the rest of the binary.

T

Reland [X86] With large code model, put functions into .ltext with large section flag (#73037)

So that when mixing small and large text, large text stays out of the
way of the rest of the binary.

This is useful for mixing precompiled small code model object files and
built-from-source large code model binaries so that the the text
sections don't get merged.

The reland fixes an issue where a function in the large code model would reference small data without GOTOFF.

This was incorrectly reverted in 76f78ecc789d58baa3a88b2fe2a57428f07e5362.

show more ...

Revert "Reland [X86] With large code model, put functions into .ltext with large section flag (#73037)"

This reverts commit 4bf8a688956a759b7b6b8d94f42d25c13c7af130.

This commit seems to be breakin

Revert "Reland [X86] With large code model, put functions into .ltext with large section flag (#73037)"

This reverts commit 4bf8a688956a759b7b6b8d94f42d25c13c7af130.

This commit seems to be breaking the semantics of the
ObjectFile::isSectionText method, which breaks numba/llvmlite bindings.

show more ...

Reland [X86] With large code model, put functions into .ltext with large section flag (#73037)

So that when mixing small and large text, large text stays out of the
way of the rest of the binary.

T

Reland [X86] With large code model, put functions into .ltext with large section flag (#73037)

So that when mixing small and large text, large text stays out of the
way of the rest of the binary.

This is useful for mixing precompiled small code model object files and
built-from-source large code model binaries so that the the text
sections don't get merged.

The reland fixes an issue where a function in the large code model would reference small data without GOTOFF.

show more ...

Revert "[X86] With large code model, put functions into .ltext with large section flag (#73037)"

This reverts commit 38e435895779c6f0e6c47a171f3b300ad99828b3.

May be culprit for https://lab.llvm.or

Revert "[X86] With large code model, put functions into .ltext with large section flag (#73037)"

This reverts commit 38e435895779c6f0e6c47a171f3b300ad99828b3.

May be culprit for https://lab.llvm.org/buildbot/#/builders/37/builds/28079/steps/9/logs/stdio.

show more ...

[X86] With large code model, put functions into .ltext with large section flag (#73037)

So that when mixing small and large text, large text stays out of the
way of the rest of the binary.

This

[X86] With large code model, put functions into .ltext with large section flag (#73037)

So that when mixing small and large text, large text stays out of the
way of the rest of the binary.

This is useful for mixing precompiled small code model object files and
built-from-source large code model binaries so that the the text
sections don't get merged.

show more ...

[X86] Use RIP-relative for non-globals in medium code model in classifyLocalReference() (#67070)

We only want to treat globals as potentially far away, not other things
like constants in the consta

[X86] Use RIP-relative for non-globals in medium code model in classifyLocalReference() (#67070)

We only want to treat globals as potentially far away, not other things
like constants in the constant pool.
This matches the object file emission that only puts the large section
flag on globals.

Remove FIXME since the remaining differences are accesses to 0 sized
globals which are intentional.

show more ...

[X86] Use RIP-relative addressing for data under large data threshold for medium code model

Since those data are assumed to be within the relocation offset limit.

Reviewed By: rnk

Differential Rev

[X86] Use RIP-relative addressing for data under large data threshold for medium code model

Since those data are assumed to be within the relocation offset limit.

Reviewed By: rnk

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

show more ...

[X86][EVEX512] Restrict attaching EVEX512 for default CPU only, NFCI (#65920)

Attaching EVEX512 is used to provide backward compatibility for legacy
LLVM IR files, which didn't set EVEX512 feature

[X86][EVEX512] Restrict attaching EVEX512 for default CPU only, NFCI (#65920)

Attaching EVEX512 is used to provide backward compatibility for legacy
LLVM IR files, which didn't set EVEX512 feature explicitly.

AVX512 and AVX10 targets have set or unset EVEX512 properly through
X86.td.

However, it's not feasible to list all AVX512 and AVX10 targets or their
complementary set here to skip/restrict such code.

Instead, we can restrict it for default CPU only. "generic" is used when
"target-cpu" is not specified in IR, while "pentium4" and "x86-64" is
the default CPU if "-march" is not specified in Clang for 32-bit and
64-bit targets respectively.

This patch is no functional change intended, though it might affect
scenarios like "-march=broadwell -mavx512bw", which looks like a misuse
of "-march" and can be solved by changing to "-mtune=broadwell
-mavx512bw".

show more ...

[X86][RFC] Add new option `-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 features

This is an alternative of D157485 and a pre-feature to support AVX10.

AVX10 Architecture S

[X86][RFC] Add new option `-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 features

This is an alternative of D157485 and a pre-feature to support AVX10.

AVX10 Architecture Specification: https://cdrdv2.intel.com/v1/dl/getContent/784267
AVX10 Technical Paper: https://cdrdv2.intel.com/v1/dl/getContent/784343
RFC: https://discourse.llvm.org/t/rfc-design-for-avx10-feature-support/72661

Based on the feedbacks from LLVM and GCC community, we have agreed to
start from supporting `-m[no-]evex512` on existing AVX512 features.
The option `-mno-evex512` can be used with `-mavx512xxx` to build
binaries that can run on both legacy AVX512 targets and AVX10-256.

There're still arguments about what's the expected behavior when this
option as well as `-mavx512xxx` used together with `-mavx10.1-256`. We
decided to defer the support of `-mavx10.1` after we made consensus.
Or furthermore, we start from supporting AVX10.2 and not providing any
AVX10.1 options.

Reviewed By: RKSimon, skan

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

show more ...

Revert "[X86][RFC] Add new option `-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 features"

This reverts commit 7dd48cc24de2d54d40527432cbee8a9d97a8a4f7.

Causing buildbot fa

Revert "[X86][RFC] Add new option `-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 features"

This reverts commit 7dd48cc24de2d54d40527432cbee8a9d97a8a4f7.

Causing buildbot failure.

show more ...

[X86][RFC] Add new option `-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 features

This is an alternative of D157485 and a pre-feature to support AVX10.

AVX10 Architecture S

[X86][RFC] Add new option `-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 features

This is an alternative of D157485 and a pre-feature to support AVX10.

AVX10 Architecture Specification: https://cdrdv2.intel.com/v1/dl/getContent/784267
AVX10 Technical Paper: https://cdrdv2.intel.com/v1/dl/getContent/784343
RFC: https://discourse.llvm.org/t/rfc-design-for-avx10-feature-support/72661

Based on the feedbacks from LLVM and GCC community, we have agreed to
start from supporting `-m[no-]evex512` on existing AVX512 features.
The option `-mno-evex512` can be used with `-mavx512xxx` to build
binaries that can run on both legacy AVX512 targets and AVX10-256.

There're still arguments about what's the expected behavior when this
option as well as `-mavx512xxx` used together with `-mavx10.1-256`. We
decided to defer the support of `-mavx10.1` after we made consensus.
Or furthermore, we start from supporting AVX10.2 and not providing any
AVX10.1 options.

Reviewed By: RKSimon, skan

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

show more ...