[llvm][AsmPrinter] Add an option to print instruction latencies (#113243)

... matching what we have in the disassembler. This isn't turned on by
default since several of the scheduling models are n

[llvm][AsmPrinter] Add an option to print instruction latencies (#113243)

... matching what we have in the disassembler. This isn't turned on by
default since several of the scheduling models are not completely
accurate, and we don't want to be misleading.

show more ...

[MCSchedule] Simplify and remove a C++20-deprecated is_pod call. NFC

[TableGen] Rename ResourceCycles and StartAtCycle to clarify semantics

D150312 added a TODO:

TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` r

[TableGen] Rename ResourceCycles and StartAtCycle to clarify semantics

D150312 added a TODO:

TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` respectively, to stress the
fact that resource allocation is now represented as an interval,
relatively to the issue cycle of the instruction.

This patch implements that TODO. This naming clarifies how to use these
fields in the scheduler. In addition it was confusing that `StartAtCycle` was
singular but `Cycles` was plural. This renaming fixes this inconsistency.

This commit as previously reverted since it missed renaming that came
down after rebasing. This version of the commit fixes those problems.

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

show more ...

Revert "[TableGen] Rename ResourceCycles and StartAtCycle to clarify semantics"

This reverts commit 5b854f2c23ea1b000cb4cac4c0fea77326c03d43.

Build still failing.

[TableGen] Rename ResourceCycles and StartAtCycle to clarify semantics

D150312 added a TODO:

TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` r

[TableGen] Rename ResourceCycles and StartAtCycle to clarify semantics

D150312 added a TODO:

TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` respectively, to stress the
fact that resource allocation is now represented as an interval,
relatively to the issue cycle of the instruction.

This patch implements that TODO. This naming clarifies how to use these
fields in the scheduler. In addition it was confusing that `StartAtCycle` was
singular but `Cycles` was plural. This renaming fixes this inconsistency.

This commit as previously reverted since it missed renaming that came
down after rebasing. This version of the commit fixes those problems.

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

show more ...

Revert "[TableGen] Rename ResourceCycles and StartAtCycle to clarify semantics"

This reverts commit 030d33409568b2f0ea61116e83fd40ca27ba33ac.

This commit is causing build failures

[TableGen] Rename ResourceCycles and StartAtCycle to clarify semantics

D150312 added a TODO:

TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` r

[TableGen] Rename ResourceCycles and StartAtCycle to clarify semantics

D150312 added a TODO:

TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` respectively, to stress the
fact that resource allocation is now represented as an interval,
relatively to the issue cycle of the instruction.

This patch implements that TODO. This naming clarifies how to use these
fields in the scheduler. In addition it was confusing that `StartAtCycle` was
singular but `Cycles` was plural. This renaming fixes this inconsistency.

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

show more ...

[MISched][rework] Introduce and use ResourceSegments.

Re-landing the code that was reverted because of the buildbot failure
in https://lab.llvm.org/buildbot#builders/9/builds/27319.

Original commit

[MISched][rework] Introduce and use ResourceSegments.

Re-landing the code that was reverted because of the buildbot failure
in https://lab.llvm.org/buildbot#builders/9/builds/27319.

Original commit message
======================

The class `ResourceSegments` is used to keep track of the intervals
that represent resource usage of a list of instructions that are
being scheduled by the machine scheduler.

The collection is made of intervals that are closed on the left and
open on the right (represented by the standard notation `[a, b)`).

These collections of intervals can be extended by `add`ing new
intervals accordingly while scheduling a basic block.

Unit tests are added to verify the possible configurations of
intervals, and the relative possibility of scheduling a new
instruction in these configurations. Specifically, the methods
`getFirstAvailableAtFromBottom` and `getFirstAvailableAtFromTop` are
tested to make sure that both bottom-up and top-down scheduling work
when tracking resource usage across the basic block with
`ResourceSegments`.

Note that the scheduler tracks resource usage with two methods:

1. counters (via `std::vector<unsigned> ReservedCycles;`);

2. intervals (via `std::map<unsigned, ResourceSegments> ReservedResourceSegments;`).

This patch can be considered a NFC test for existing scheduling models
because the tracking system that uses intervals is turned off by
default (field `bit EnableIntervals = false;` in the tablegen class
`SchedMachineModel`).

Reviewed By: andreadb

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

show more ...

Revert "[MISched] Introduce and use ResourceSegments."

Reverted because it produces the following builbot failure at https://lab.llvm.org/buildbot#builders/9/builds/27319:

/b/ml-opt-rel-x86-64-b1/l

Revert "[MISched] Introduce and use ResourceSegments."

Reverted because it produces the following builbot failure at https://lab.llvm.org/buildbot#builders/9/builds/27319:

/b/ml-opt-rel-x86-64-b1/llvm-project/llvm/unittests/CodeGen/SchedBoundary.cpp: In member function ‘virtual void ResourceSegments_getFirstAvailableAtFromBottom_empty_Test::TestBody()’:
/b/ml-opt-rel-x86-64-b1/llvm-project/llvm/unittests/CodeGen/SchedBoundary.cpp:395:31: error: call of overloaded ‘ResourceSegments(<brace-enclosed initializer list>)’ is ambiguous
395 | auto X = ResourceSegments({});
| ^

This reverts commit dc312f0331309692e8d6e06e93b3492b6a40989f.

show more ...

[MISched] Introduce and use ResourceSegments.

The class `ResourceSegments` is used to keep track of the intervals
that represent resource usage of a list of instructions that are
being scheduled by

[MISched] Introduce and use ResourceSegments.

The class `ResourceSegments` is used to keep track of the intervals
that represent resource usage of a list of instructions that are
being scheduled by the machine scheduler.

The collection is made of intervals that are closed on the left and
open on the right (represented by the standard notation `[a, b)`).

These collections of intervals can be extended by `add`ing new
intervals accordingly while scheduling a basic block.

Unit tests are added to verify the possible configurations of
intervals, and the relative possibility of scheduling a new
instruction in these configurations. Specifically, the methods
`getFirstAvailableAtFromBottom` and `getFirstAvailableAtFromTop` are
tested to make sure that both bottom-up and top-down scheduling work
when tracking resource usage across the basic block with
`ResourceSegments`.

Note that the scheduler tracks resource usage with two methods:

1. counters (via `std::vector<unsigned> ReservedCycles;`);

2. intervals (via `std::map<unsigned, ResourceSegments> ReservedResourceSegments;`).

This patch can be considered a NFC test for existing scheduling models
because the tracking system that uses intervals is turned off by
default (field `bit EnableIntervals = false;` in the tablegen class
`SchedMachineModel`).

Reviewed By: andreadb

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

show more ...

Use llvm::popcount instead of llvm::countPopulation(NFC)

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_E

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).

This commit fixes LLVMAnalysis and its dependencies.

show more ...

[MC] Use std::optional in MCSchedule.cpp (NFC)

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-

[MC] Use std::optional in MCSchedule.cpp (NFC)

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

[llvm] Use value instead of getValue (NFC)

[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[ARM][SchedModels] Convert IsPredicatedPred to MCSchedPredicate

Differential revision: https://reviews.llvm.org/D89553

[MC][X86] Correctly model additional operand latency caused by transfer delays from the integer to the floating point unit.

This patch adds a new ReadAdvance definition named ReadInt2Fpu.
ReadInt2Fp

[MC][X86] Correctly model additional operand latency caused by transfer delays from the integer to the floating point unit.

This patch adds a new ReadAdvance definition named ReadInt2Fpu.
ReadInt2Fpu allows x86 scheduling models to accurately describe delays caused by
data transfers from the integer unit to the floating point unit.
ReadInt2Fpu currently defaults to a delay of zero cycles (i.e. no delay) for all
x86 models excluding BtVer2. That means, this patch is only a functional change
for the Jaguar cpu model only.

Tablegen definitions for instructions (V)PINSR* have been updated to account for
the new ReadInt2Fpu. That read is mapped to the the GPR input operand.
On Jaguar, int-to-fpu transfers are modeled as a +6cy delay. Before this patch,
that extra delay was added to the opcode latency. In practice, the insert opcode
only executes for 1cy. Most of the actual latency is actually contributed by the
so-called operand-latency. According to the AMD SOG for family 16h, (V)PINSR*
latency is defined by expression f+1, where f is defined as a forwarding delay
from the integer unit to the fpu.

When printing instruction latency from MCA (see InstructionInfoView.cpp) and LLC
(only when flag -print-schedule is speified), we now need to account for any
extra forwarding delays. We do this by checking if scheduling classes declare
any negative ReadAdvance entries. Quoting a code comment in TargetSchedule.td:
"A negative advance effectively increases latency, which may be used for
cross-domain stalls". When computing the instruction latency for the purpose of
our scheduling tests, we now add any extra delay to the formula. This avoids
regressing existing codegen and mca schedule tests. It comes with the cost of an
extra (but very simple) hook in MCSchedModel.

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

llvm-svn: 351965

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[CodeGen] assume max/default throughput for unspecified instructions

This is a fix for the problem arising in D47374 (PR37678):
https://bugs.llvm.org/show_bug.cgi?id=37678

We may not have throughpu

[CodeGen] assume max/default throughput for unspecified instructions

This is a fix for the problem arising in D47374 (PR37678):
https://bugs.llvm.org/show_bug.cgi?id=37678

We may not have throughput info because it's not specified in the model
or it's not available with variant scheduling, so assume that those
instructions can execute/complete at max-issue-width.

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

llvm-svn: 334055

show more ...

[MCSchedule] Add the ability to compute the latency and throughput information for MCInst.

This patch extends the MCSchedModel API with new methods that can be used to
obtain the latency and recipro

[MCSchedule] Add the ability to compute the latency and throughput information for MCInst.

This patch extends the MCSchedModel API with new methods that can be used to
obtain the latency and reciprocal througput information for an MCInst.

Scheduling models have recently gained the ability to resolve variant scheduling
classes associated with MCInst objects. Before, models were only able to resolve
a variant scheduling class from a MachineInstr object.

This patch is mainly required by D47374 to avoid regressing a pair of x86
specific -print-schedule tests for btver2. Patch D47374 introduces a new variant
class to teach the btver scheduling model (x86 target) how to correctly compute
the latency profile for some zero-idioms using the new scheduling predicates.

The new methods added by this patch would be mainly used by llc when flag
-print-schedule is specified. In particular, tests that contain inline assembly
require that code is parsed at code emission stage into a sequence of MCInst.
That forces the print-schedule functionality to query the latency/rthroughput
information for MCInst instructions too. If we don't expose this new API, then
we lose "-print-schedule" test coverage as soon as variant scheduling classes
are added to the x86 models.

The tablegen SubtargetEmitter changes teaches how to query latency profile
information using a object that derives from TargetSubtargetInfo. Note that this
should really have been part of r333286. To avoid code duplication, the logic
that "resolves" variant scheduling classes for MCInst, has been moved to a
common place in MC. That logic is used by the "resolveVariantSchedClass" methods
redefined in override by the tablegen'd GenSubtargetInfo classes.

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

llvm-svn: 333650

show more ...

[MC] Moved all the remaining logic that computed instruction latency and reciprocal throughput from TargetSchedModel to MCSchedModel.

TargetSchedModel now always delegates to MCSchedModel the comput

[MC] Moved all the remaining logic that computed instruction latency and reciprocal throughput from TargetSchedModel to MCSchedModel.

TargetSchedModel now always delegates to MCSchedModel the computation of
instruction latency and reciprocal throughput.
No functional change intended.

llvm-svn: 330099

show more ...

[MC] Fix -Wmissing-field-initializer warning after r329067.

This should fix the problem reported by the lld buildbots:
- Builder lld-x86_64-darwin13, Build #19782
- Builder lld-perf-testsuite, Bui

[MC] Fix -Wmissing-field-initializer warning after r329067.

This should fix the problem reported by the lld buildbots:
- Builder lld-x86_64-darwin13, Build #19782
- Builder lld-perf-testsuite, Build #1419

llvm-svn: 329068

show more ...

[MC] Move the reciprocal throughput computation from TargetSchedModel to MCSchedModel.

The goal is to make the reciprocal throughput computation accessible through the
MCSchedModel interface. This i

[MC] Move the reciprocal throughput computation from TargetSchedModel to MCSchedModel.

The goal is to make the reciprocal throughput computation accessible through the
MCSchedModel interface. This is particularly important for llvm-mca because it
can only query the MCSchedModel interface.

No functional change intended.

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

llvm-svn: 327420

show more ...