[nfc][llvm] Clean up isUEFI checks (#124845)

The check for `isOSWindows() || isUEFI()` is used in several places
across the codebase. Introducing `isOSWindowsOrUEFI()` in Triple.h
to simplify thes

[nfc][llvm] Clean up isUEFI checks (#124845)

The check for `isOSWindows() || isUEFI()` is used in several places
across the codebase. Introducing `isOSWindowsOrUEFI()` in Triple.h
to simplify these checks.

show more ...

[DataLayout] Remove getMaxIndexSizeInBits() API

The last use was removed in #119365, and we should not add more
uses of this concept in the future either.

DataLayout: Fix latent issues with getMaxIndexSizeInBits (#118740)

Because it was implemented in terms of getMaxIndexSize, it was always
rounding the values up to a multiple of 8. Additionally, it

DataLayout: Fix latent issues with getMaxIndexSizeInBits (#118740)

Because it was implemented in terms of getMaxIndexSize, it was always
rounding the values up to a multiple of 8. Additionally, it was using
the PointerSpec's BitWidth rather than its IndexBitWidth, which was
self-evidently incorrect.

Since getMaxIndexSize was only used by getMaxIndexSizeInBits, and its
name and function seem niche and somewhat confusing, go ahead and remove
it until a concrete need for it arises.

show more ...

[DataLayout] Refactor storage of non-integral address spaces

Instead of storing this as a separate array of non-integral pointers,
add it to the PointerSpec class instead. This will allow for future

[DataLayout] Refactor storage of non-integral address spaces

Instead of storing this as a separate array of non-integral pointers,
add it to the PointerSpec class instead. This will allow for future
simplifications such as splitting the non-integral property into
multiple distinct ones: relocatable (i.e. non-stable representation) and
non-integral representation (i.e. pointers with metadata).

Reviewed By: arsenm

Pull Request: https://github.com/llvm/llvm-project/pull/105734

show more ...

[DataLayout] Refactor the rest of `parseSpecification` (#104545)

The aim is to improve test coverage of data layout string parsing.

Pull Request: https://github.com/llvm/llvm-project/pull/104545

[DataLayout] Refactor parsing of i/f/v/a specifications (#104699)

Split off of #104545 to reduce patch size.

[DataLayout] Refactor parsing of "p" specification (#104583)

Split off of #104545 to reduce patch size.
Similar to #104546, this introduces `parseSize` and `parseAlignment`,
which are improved ver

[DataLayout] Refactor parsing of "p" specification (#104583)

Split off of #104545 to reduce patch size.
Similar to #104546, this introduces `parseSize` and `parseAlignment`,
which are improved versions of `getInt` tailored for specific needs.

I'm not a GTest guru, so the tests are not ideal.

show more ...

[DataLayout] Refactor parsing of "ni" specification (#104546)

Split off of #104545 to reduce patch size.
This introduces `parseAddrSpace` function, intended as a replacement for
`getAddrSpace`, wh

[DataLayout] Refactor parsing of "ni" specification (#104546)

Split off of #104545 to reduce patch size.
This introduces `parseAddrSpace` function, intended as a replacement for
`getAddrSpace`, which doesn't check for trailing characters after the
address space number. `getAddrSpace` will be removed after switching all
uses to `parseAddrSpace`.

Pull Request: https://github.com/llvm/llvm-project/pull/104546

show more ...

[DataLayout] Extract loop body into a function to reduce nesting (NFC) (#104420)

Also, use `iterator_range` version of `split`.

Pull Request: https://github.com/llvm/llvm-project/pull/104420

[DataLayout] Add helper predicates to sort specifications (NFC) (#104417)

[DataLayout] Move '*AlignElem' structs and enum inside DataLayout (NFC) (#103723)

This makes `LayoutAlignElem` / `PointerAlignElem` and `AlignTypeEnum`
inner types of `DataLayout`. The types are al

[DataLayout] Move '*AlignElem' structs and enum inside DataLayout (NFC) (#103723)

This makes `LayoutAlignElem` / `PointerAlignElem` and `AlignTypeEnum`
inner types of `DataLayout`. The types are also renamed to match their
meaning (LangRef refers to them as "specification" and "specifier").

Pull Request: https://github.com/llvm/llvm-project/pull/103723

show more ...

[DataLayout] Use member initialization (NFC) (#103712)

This also adds a default constructor and a few uses of it.

[DataLayout] Split StructAlignment into two fields (NFC) (#103700)

Aggregate type specification doesn't have the size component.
Don't abuse LayoutAlignElem to avoid confusion.

[DataLayout] Remove `clear` and `reset` methods (NFC) (#102993)

`clear` was never necessary as it is always called on a fresh instance
of the class or just before freeing an instance's memory. `res

[DataLayout] Remove `clear` and `reset` methods (NFC) (#102993)

`clear` was never necessary as it is always called on a fresh instance
of the class or just before freeing an instance's memory. `reset` is
effectively the same as the constructor.

Pull Reuquest: https://github.com/llvm/llvm-project/pull/102993

show more ...

[DataLayout] Remove constructor accepting a pointer to Module (#102841)

The constructor initializes `*this` with `M->getDataLayout()`, which
is effectively the same as calling the copy constructor.

[DataLayout] Remove constructor accepting a pointer to Module (#102841)

The constructor initializes `*this` with `M->getDataLayout()`, which
is effectively the same as calling the copy constructor.
There does not seem to be a case where a copy would be necessary.

Pull Request: https://github.com/llvm/llvm-project/pull/102841

show more ...

[DataLayout] Move `operator=` to cpp file (NFC) (#102849)

`DataLayout` isn't exactly cheap to copy (448 bytes on a 64-bit host).
Move `operator=` to cpp file to improve compilation time. Also move

[DataLayout] Move `operator=` to cpp file (NFC) (#102849)

`DataLayout` isn't exactly cheap to copy (448 bytes on a 64-bit host).
Move `operator=` to cpp file to improve compilation time. Also move
`operator==` closer to `operator=` and add a couple of FIXMEs.

show more ...

[DataLayout] Remove deprecated method (#101495)

The method has been deprecated for a year and a half now.

Remove the `x86_mmx` IR type. (#98505)

It is now translated to `<1 x i64>`, which allows the removal of a bunch
of special casing.

This _incompatibly_ changes the ABI of any LLVM IR function wit

Remove the `x86_mmx` IR type. (#98505)

It is now translated to `<1 x i64>`, which allows the removal of a bunch
of special casing.

This _incompatibly_ changes the ABI of any LLVM IR function with
`x86_mmx` arguments or returns: instead of passing in mmx registers,
they will now be passed via integer registers. However, the real-world
incompatibility caused by this is expected to be minimal, because Clang
never uses the x86_mmx type -- it lowers `__m64` to either `<1 x i64>`
or `double`, depending on ABI.

This change does _not_ eliminate the SelectionDAG `MVT::x86mmx` type.
That type simply no longer corresponds to an IR type, and is used only
by MMX intrinsics and inline-asm operands.

Because SelectionDAGBuilder only knows how to generate the
operands/results of intrinsics based on the IR type, it thus now
generates the intrinsics with the type MVT::v1i64, instead of
MVT::x86mmx. We need to fix this before the DAG LegalizeTypes, and thus
have the X86 backend fix them up in DAGCombine. (This may be a
short-lived hack, if all the MMX intrinsics can be removed in upcoming
changes.)

Works towards issue #98272.

show more ...

Add llvm::min/max_element and use it in llvm/ and mlir/ directories. (#84678)

For some reason this was missing from STLExtras.

[IR] Fix GEP offset computations for vector GEPs (#75448)

Vectors are always bit-packed and don't respect the elements' alignment
requirements. This is different from arrays. This means offsets of

[IR] Fix GEP offset computations for vector GEPs (#75448)

Vectors are always bit-packed and don't respect the elements' alignment
requirements. This is different from arrays. This means offsets of
vector GEPs need to be computed differently than offsets of array GEPs.

This PR fixes many places that rely on an incorrect pattern
that always relies on `DL.getTypeAllocSize(GTI.getIndexedType())`.
We replace these by usages of `GTI.getSequentialElementStride(DL)`,
which is a new helper function added in this PR.

This changes behavior for GEPs into vectors with element types for which
the (bit) size and alloc size is different. This includes two cases:

* Types with a bit size that is not a multiple of a byte, e.g. i1.
GEPs into such vectors are questionable to begin with, as some elements
are not even addressable.
* Overaligned types, e.g. i16 with 32-bit alignment.

Existing tests are unaffected, but a miscompilation of a new test is fixed.

---------

Co-authored-by: Nikita Popov <github@npopov.com>

show more ...

[llvm][TypeSize] Fix addition/subtraction in TypeSize. (#72979)

It seems TypeSize is currently broken in the sense that:

TypeSize::Fixed(4) + TypeSize::Scalable(4) => TypeSize::Fixed(8)

with

[llvm][TypeSize] Fix addition/subtraction in TypeSize. (#72979)

It seems TypeSize is currently broken in the sense that:

TypeSize::Fixed(4) + TypeSize::Scalable(4) => TypeSize::Fixed(8)

without failing its assert that explicitly tests for this case:

assert(LHS.Scalable == RHS.Scalable && ...);

The reason this fails is that `Scalable` is a static method of class
TypeSize,
and LHS and RHS are both objects of class TypeSize. So this is
evaluating
if the pointer to the function Scalable == the pointer to the function
Scalable,
which is always true because LHS and RHS have the same class.

This patch fixes the issue by renaming `TypeSize::Scalable` ->
`TypeSize::getScalable`, as well as `TypeSize::Fixed` to
`TypeSize::getFixed`,
so that it no longer clashes with the variable in
FixedOrScalableQuantity.

The new methods now also better match the coding standard, which
specifies that:
* Variable names should be nouns (as they represent state)
* Function names should be verb phrases (as they represent actions)

show more ...

[IR] Require index width to be ule pointer width (#70015)

I don't think there is a use case for having an index type that is wider
than the pointer type, and I'm not entirely clear what semantics t

[IR] Require index width to be ule pointer width (#70015)

I don't think there is a use case for having an index type that is wider
than the pointer type, and I'm not entirely clear what semantics this
would even have.

Also clarify the GEP semantics to explicitly say how they interact with
the index type width.

show more ...

[Basic] Support 64-bit x86 target for UEFI

Adding support for X86_64 UEFI target to begin with.

Reviewed By: phosek, MaskRay

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

Revert "[Basic] Support 64-bit x86 target for UEFI"

This reverts commit 315a407086b0ab302d0293b720d7f9b3e8f6ffa9.
The new test added fails to link the unit tests correctly and breaks
certain buildbo

Revert "[Basic] Support 64-bit x86 target for UEFI"

This reverts commit 315a407086b0ab302d0293b720d7f9b3e8f6ffa9.
The new test added fails to link the unit tests correctly and breaks
certain buildbots.

show more ...

[Basic] Support 64-bit x86 target for UEFI

Adding support for X86_64 UEFI target to begin with.

Reviewed By: phosek, MaskRay

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