Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)

Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/

Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)

Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/117907.html,
https://reviews.llvm.org/D38482, https://reviews.llvm.org/D38489, this
PR attempts to overhaul the `TargetMachine` and `LLVMTargetMachine`
interface classes. More specifically:
1. Makes `TargetMachine` the only class implemented under
`TargetMachine.h` in the `Target` library.
2. `TargetMachine` contains target-specific interface functions that
relate to IR/CodeGen/MC constructs, whereas before (at least on paper)
it was supposed to have only IR/MC constructs. Any Target that doesn't
want to use the independent code generator simply does not implement
them, and returns either `false` or `nullptr`.
3. Renames `LLVMTargetMachine` to `CodeGenCommonTMImpl`. This renaming
aims to make the purpose of `LLVMTargetMachine` clearer. Its interface
was moved under the CodeGen library, to further emphasis its usage in
Targets that use CodeGen directly.
4. Makes `TargetMachine` the only interface used across LLVM and its
projects. With these changes, `CodeGenCommonTMImpl` is simply a set of
shared function implementations of `TargetMachine`, and CodeGen users
don't need to static cast to `LLVMTargetMachine` every time they need a
CodeGen-specific feature of the `TargetMachine`.
5. More importantly, does not change any requirements regarding library
linking.

cc @arsenm @aeubanks

show more ...

CodeGen: Remove MachineModuleInfo reference from MachineFunction (#100357)

This avoids another unserializable field. Move the DbgInfoAvailable
field into the AsmPrinter, which is only really a cache

CodeGen: Remove MachineModuleInfo reference from MachineFunction (#100357)

This avoids another unserializable field. Move the DbgInfoAvailable
field into the AsmPrinter, which is only really a cache/convenience
bit for checking a direct IR module metadata check.

show more ...

Reland "SelectionDAG: Avoid using MachineFunction::getMMI" (#99779)

Reverts llvm/llvm-project#99777

Co-authored-by: Matt Arsenault <Matthew.Arsenault@amd.com>

Revert "SelectionDAG: Avoid using MachineFunction::getMMI" (#99777)

Reverts llvm/llvm-project#99696

https://lab.llvm.org/buildbot/#/builders/164/builds/1262

SelectionDAG: Avoid using MachineFunction::getMMI (#99696)

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

[SelectionDAG] Change computeAliasing signature from optional<uint64> to LocationSize. (#83017)

This is another smaller step of #70452, changing the signature of
computeAliasing() from optional<uin

[SelectionDAG] Change computeAliasing signature from optional<uint64> to LocationSize. (#83017)

This is another smaller step of #70452, changing the signature of
computeAliasing() from optional<uint64_t> to LocationSize, and follow-up
changes in DAGCombiner::mayAlias(). There are some test change due to
the previous AA->isNoAlias call incorrectly using an unknown size
(~UINT64_T(0)). This should then be improved again in #70452 when the
types are known to be scalable.

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

[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)

This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future chang

[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)

This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.

This matches other nearby enums.

For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::

show more ...

[CodeGen] llvm::Optional => std::optional

Fix compile error in unittests after 1d1de7467c32d52926ca56b9167a2c65c451ecfa

Build-bot failure: https://lab.llvm.org/buildbot/#/builders/139/builds/32477

commit 1d1de7467c32d52926ca56b9167a2c65c45

Fix compile error in unittests after 1d1de7467c32d52926ca56b9167a2c65c451ecfa

Build-bot failure: https://lab.llvm.org/buildbot/#/builders/139/builds/32477

commit 1d1de7467c32d52926ca56b9167a2c65c451ecfa (HEAD -> main, origin/main)
Author: OCHyams <orlando.hyams@sony.com>
Date: Fri Dec 9 15:43:56 2022 +0000

show more ...

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the am

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...

[SelectionDAG] Replace error prone index check in BaseIndexOffset::computeAliasing

Deriving NoAlias based on having the same index in two BaseIndexOffset
expressions seemed weird (and as shown in th

[SelectionDAG] Replace error prone index check in BaseIndexOffset::computeAliasing

Deriving NoAlias based on having the same index in two BaseIndexOffset
expressions seemed weird (and as shown in the added unittest the
correctness of doing so depended on undocumented pre-conditions that
the user of BaseIndexOffset::computeAliasing would need to take care
of.

This patch removes the code that dereived NoAlias based on indices
being the same. As a compensation, to avoid regressions/diffs in
various lit test, we also add a new check. The new check derives
NoAlias in case the two base pointers are based on two different
GlobalValue:s (neither of them being a GlobalAlias).

Reviewed By: niravd

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

show more ...

[SelectionDAG] Assume that a GlobalAlias may alias other global values

This fixes a bug detected in DAGCombiner when using global alias
variables. Here is an example:
@foo = global i16 0, align 1

[SelectionDAG] Assume that a GlobalAlias may alias other global values

This fixes a bug detected in DAGCombiner when using global alias
variables. Here is an example:
@foo = global i16 0, align 1
@aliasFoo = alias i16, i16 * @foo
define i16 @bar() {
...
store i16 7, i16 * @foo, align 1
store i16 8, i16 * @aliasFoo, align 1
...
}

BaseIndexOffset::computeAliasing would incorrectly derive NoAlias
for the two accesses in the example above, resulting in DAGCombiner
miscompiles.

This patch fixes the problem by a defensive approach letting
BaseIndexOffset::computeAliasing return false, i.e. that the aliasing
couldn't be determined, when comparing two global values and at least
one is a GlobalAlias. In the future we might improve this with a
deeper analysis to look at the aliasee for the GlobalAlias etc. But
that is a bit more complicated considering that we could have
'local_unnamed_addr' and situations with several 'alias' variables.

Fixes PR51878.

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

show more ...

[unittests][CodeGen] Mark tests that cannot be executed with GTEST_SKIP()

This helps to distinguish such tests from successfully passed ones.

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

[SelectionDAG] Don't pass a scalable vector to MachinePointerInfo::getWithOffset in a unit test.

Suppresses an implicit TypeSize to uint64_t conversion warning.

We might be able to just not offset

[SelectionDAG] Don't pass a scalable vector to MachinePointerInfo::getWithOffset in a unit test.

Suppresses an implicit TypeSize to uint64_t conversion warning.

We might be able to just not offset it since we're writing to a
Fixed stack object, but I wasn't sure so I just did what
DAGTypeLegalizer::IncrementPointer does.

Reviewed By: sdesmalen

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

show more ...

[SelectionDAG] Avoid aliasing analysis if the object size is unknown.

If the size of memory access is unknown, do not use it to analysis. One
example of unknown size memory access is to load/store s

[SelectionDAG] Avoid aliasing analysis if the object size is unknown.

If the size of memory access is unknown, do not use it to analysis. One
example of unknown size memory access is to load/store scalable vector
objects on the stack.

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

show more ...