6 Commits

Author SHA1 Message Date
Changpeng Fang
930e8dea41 AMDGPU: Add s-memrealtime and s-memtime-inst to RemoveIncompatibleFunctions
Summary:
 Under -O0, device-libs may still emit these instructions under conditions.
So we need to remove them with warning if not compatible.

Fixes: SWDEV-417219

Reviewers:
  arsenm, Pierre-vh and b-sumner

Differential Revision:
  https://reviews.llvm.org/D158316
2023-08-22 10:22:41 -07:00
Kazu Hirata
d85993d28f [llvm] Remove redundant control flow statements (NFC) 2023-08-19 08:07:30 -07:00
pvanhout
96e1032a5e [AMDGPU] Add extended-image-insts to RemoveIncompatibleFunctions
Otherwise device libs still has issues at O0 (in OpenCL-CTS)

Depends on D156972 as well. They're unrelated fixes but both are needed to fix the issue.

Fixes SWDEV-402331

Reviewed By: #amdgpu, arsenm

Differential Revision: https://reviews.llvm.org/D156973
2023-08-08 15:15:57 +02:00
skc7
663bb5a5f7 [AMDGPU] Remove function if FeatureWavefrontSize 32 is not supported on current GPU
Reviewed By: arsenm, b-sumner

Differential Revision: https://reviews.llvm.org/D148906
2023-05-19 23:49:01 +05:30
pvanhout
0ff02cf015 [AMDGPU] Hide "removing function" diagnostics by default
Use an `OptimizationRemark` for them even though it's not really an
optimization. It just integrates better with the other diagnostics
(enabling is easy with `-pass-remark`).

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D147703
2023-04-11 09:26:20 +02:00
pvanhout
8e68c12045 [AMDGPU] Remove function with incompatible features
Adds a new pass that removes functions
if they use features that are not supported on the current GPU.

This change is aimed at preventing crashes when building code at O0 that
uses idioms such as `if (ISA_VERSION >= N) intrinsic_a(); else intrinsic_b();`
where ISA_VERSION is not constexpr, and intrinsic_a is not selectable
on older targets.
This is a pattern that's used all over the ROCm device libs. The main
motive behind this change is to allow code using ROCm device libs
to be built at O0.

Note: the feature checking logic is done ad-hoc in the pass. There is no other
pass that needs (or will need in the foreseeable future) to do similar
feature-checking logic so I did not see a need to generalize the feature
checking logic yet. It can (and should probably) be generalized later and
moved to a TargetInfo-like class or helper file.

Reviewed By: arsenm, Joe_Nash

Differential Revision: https://reviews.llvm.org/D139000
2023-02-21 10:42:39 +01:00