History log of /llvm-project/llvm/lib/Target/AMDGPU/GCNSubtarget.cpp (Results 1 – 10 of 10)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 6206f544 23-Jan-2025 Lucas Ramirez <11032120+lucas-rami@users.noreply.github.com>

[AMDGPU] Occupancy w.r.t. workgroup size range is also a range (#123748)

Occupancy (i.e., the number of waves per EU) depends, in addition to
register usage, on per-workgroup LDS usage as well as on

[AMDGPU] Occupancy w.r.t. workgroup size range is also a range (#123748)

Occupancy (i.e., the number of waves per EU) depends, in addition to
register usage, on per-workgroup LDS usage as well as on the range of
possible workgroup sizes. Mirroring the latter, occupancy should
therefore be expressed as a range since different group sizes generally
yield different achievable occupancies.

`getOccupancyWithLocalMemSize` currently returns a scalar occupancy
based on the maximum workgroup size and LDS usage. With respect to the
workgroup size range, this scalar can be the minimum, the maximum, or
neither of the two of the range of achievable occupancies. This commit
fixes the function by making it compute and return the range of
achievable occupancies w.r.t. workgroup size and LDS usage; it also
renames it to `getOccupancyWithWorkGroupSizes` since it is the range of
workgroup sizes that produces the range of achievable occupancies.

Computing the achievable occupancy range is surprisingly involved.
Minimum/maximum workgroup sizes do not necessarily yield maximum/minimum
occupancies i.e., sometimes workgroup sizes inside the range yield the
occupancy bounds. The implementation finds these sizes in constant time;
heavy documentation explains the rationale behind the sometimes
relatively obscure calculations.

As a justifying example, consider a target with 10 waves / EU, 4 EUs/CU,
64-wide waves. Also consider a function with no LDS usage and a flat
workgroup size range of [513,1024].

- A group of 513 items requires 9 waves per group. Only 4 groups made up
of 9 waves each can fit fully on a CU at any given time, for a total of
36 waves on the CU, or 9 per EU. However, filling as much as possible
the remaining 40-36=4 wave slots without decreasing the number of groups
reveals that a larger group of 640 items yields 40 waves on the CU, or
10 per EU.
- Similarly, a group of 1024 items requires 16 waves per group. Only 2
groups made up of 16 waves each can fit fully on a CU ay any given time,
for a total of 32 waves on the CU, or 8 per EU. However, removing as
many waves as possible from the groups without being able to fit another
equal-sized group on the CU reveals that a smaller group of 896 items
yields 28 waves on the CU, or 7 per EU.

Therefore the achievable occupancy range for this function is not [8,9]
as the group size bounds directly yield, but [7,10].

Naturally this change causes a lot of test churn as instruction
scheduling is driven by achievable occupancy estimates. In most unit
tests the flat workgroup size range is the default [1,1024] which,
ignoring potential LDS limitations, would previously produce a scalar
occupancy of 8 (derived from 1024) on a lot of targets, whereas we now
consider the maximum occupancy to be 10 in such cases. Most tests are
updated automatically and checked manually for sanity. I also manually
changed some non-automatically generated assertions when necessary.

Fixes #118220.

show more ...


# 93d35ad5 22-Jan-2025 Matt Arsenault <Matthew.Arsenault@amd.com>

AMDGPU: Delete FillMFMAShadowMutation (#123861)

No test changes with this removed and it appears to
be obsolete.


Revision tags: llvmorg-19.1.7, llvmorg-19.1.6
# 03847f19 16-Dec-2024 Sergei Barannikov <barannikov88@gmail.com>

[SelectionDAG] Add empty implementation of SelectionDAGInfo to some targets (#119968)

#119969 adds a couple of new methods to this class, which will need to
be overridden by these targets.

Part of

[SelectionDAG] Add empty implementation of SelectionDAGInfo to some targets (#119968)

#119969 adds a couple of new methods to this class, which will need to
be overridden by these targets.

Part of #119709.

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

show more ...


Revision tags: llvmorg-19.1.5
# cd20fc07 23-Nov-2024 Matt Arsenault <Matthew.Arsenault@amd.com>

AMDGPU: Remove wavefrontsize64 feature from dummy target (#117410)

This is a refinement for the existing hack. With this,
the default target will have neither wavefrontsize feature
present, unless i

AMDGPU: Remove wavefrontsize64 feature from dummy target (#117410)

This is a refinement for the existing hack. With this,
the default target will have neither wavefrontsize feature
present, unless it was explicitly specified. That is,
getWavefrontSize() == 64 no longer implies +wavefrontsize64.
getWavefrontSize() == 32 does imply +wavefrontsize32.

Continue to assume the value is 64 with no wavesize feature.
This maintains the codegenable property without any code
that directly cares about the wavesize needing to worry about it.

Introduce an isWaveSizeKnown helper to check if we know the
wavesize is accurate based on having one of the features explicitly
set, or a known target-cpu.

I'm not sure what's going on in wave_any.s. It's testing what
happens when both wavesizes are enabled, but this is treated
as an error in codegen. We now treat wave32 as the winning
case, so some cases that were previously printed as vcc are now
vcc_lo.

show more ...


# b3995aa3 19-Nov-2024 Jay Foad <jay.foad@amd.com>

[AMDGPU] Decrease default NSA threshold from 3 to 2 (#116624)

In graphics shaders it is better overall to use NSA encoding for IMAGE
instructions, because the benefit of less constrained register

[AMDGPU] Decrease default NSA threshold from 3 to 2 (#116624)

In graphics shaders it is better overall to use NSA encoding for IMAGE
instructions, because the benefit of less constrained register
allocation outweighs the cost of larger encoding. In particular NSA form
often avoids the need for extra V_MOV_B32 instructions between IMAGE
instructions, which can allow the IMAGE instructions to be claused.

Note that in GFX12 there is no longer a bit in the encoding to choose
between NSA and non-NSA forms, so this only affects GFX10 and GFX11.

show more ...


Revision tags: llvmorg-19.1.4
# be187369 14-Nov-2024 Kazu Hirata <kazu@google.com>

[AMDGPU] Remove unused includes (NFC) (#116154)

Identified with misc-include-cleaner.


Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1
# 6f956e31 30-Sep-2024 Jay Foad <jay.foad@amd.com>

[AMDGPU] Rename LocalMemorySize features to AddressableLocalMemorySize (#110242)

Change the names of the TableGen features to match the names used by
AMDGPUSubtarget. "Addressable" refers to the am

[AMDGPU] Rename LocalMemorySize features to AddressableLocalMemorySize (#110242)

Change the names of the TableGen features to match the names used by
AMDGPUSubtarget. "Addressable" refers to the amount that can be accessed
by a single workgroup. Add some explanatory comments. NFC.

show more ...


Revision tags: llvmorg-19.1.0
# 4ce8808d 05-Sep-2024 Jay Foad <jay.foad@amd.com>

[AMDGPU] Common up default value of -amdgpu-nsa-threshold. NFC.

The default value of 3 was specified in two places. Use the actual value
of the cl::init to avoid repeating it.


Revision tags: llvmorg-19.1.0-rc4
# b02b5b7b 23-Aug-2024 Jay Foad <jay.foad@amd.com>

[AMDGPU] Simplify use of hasMovrel and hasVGPRIndexMode (#105680)

The generic subtarget has neither of these features. Rather than forcing
HasMovrel on, it is simpler to expand dynamic vector index

[AMDGPU] Simplify use of hasMovrel and hasVGPRIndexMode (#105680)

The generic subtarget has neither of these features. Rather than forcing
HasMovrel on, it is simpler to expand dynamic vector indexing to a
sequence of compare/select instructions.

NFC for real subtargets.

show more ...


# a6bae5cb 21-Aug-2024 Jay Foad <jay.foad@amd.com>

[AMDGPU] Split GCNSubtarget into its own file. NFC. (#105525)