[PATCH] D85882: [AMDGPU] Update subtarget features for new target ID support

Austin Kerbow via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 13 00:21:17 PDT 2020


kerbowa created this revision.
kerbowa added reviewers: kzhuravl, t-tye, yaxunl, rampitec, scott.linder, arsenm.
Herald added subscribers: llvm-commits, hiraditya, kristof.beyls, tpr, dstuttard, nhaehnle, jvesely.
Herald added a project: LLVM.
kerbowa requested review of this revision.
Herald added a subscriber: wdng.

WIP

Current subtarget features for Xnack and SramEcc are the
FeatureDoesNotSupportXNACK/SRAMECC and FeatureXNACK/SRAMECC varieties. What
we need is to be able to differentiate between the four possible
scenarios listed below:

Not Supported: The processor has no support for Xnack/SramEcc
Default: Preference is unspecified. Use conservative settings.
On: Request Xnack/SramEcc On
Off: Request Xnack/SramEcc Off

The DoesNotSupport feature in unnecessary since we can determine which
processors support these permutations without it. Instead, GCNSubtarget will
track the four options based on the following criteria.  If the subtarget
does not support xnack/sram-ecc we say the setting is "NotSupported".  If no
subtarget features for xnack/sram-ecc are requested this is considered the
"Default".  If the subtarget features xnack/sram-ecc exist in the feature
string when initializing the subtarget, the settings are "On/Off".

There are workarounds in place to maintain the current "default" behavior.
If a subtarget would  normally codegen for "Xnack On" when xnack was nowhere
in the subtarget features string, we will still use the setting "Xnack On".
This is also true for the "generic" target where no specific GPU is
selected.

RFC

Do "fatal errors" make sense when any xnack/sramecc request is made for a
target that does not support the feature? Instead should we have a warning
if, as an example, "xnack Off" is requested for a processor without support.
I'm leaning towards avoiding the fatal error in that case since the request
is harmless, even if the request doesn't make sense.

Should the "generic" GPU be "Default" or "NotSupported"? With the current
setup it will be "Default".


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85882

Files:
  llvm/lib/Target/AMDGPU/AMDGPU.td
  llvm/lib/Target/AMDGPU/AMDGPUSubtarget.cpp
  llvm/lib/Target/AMDGPU/AMDGPUSubtarget.h
  llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
  llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.h
  llvm/test/CodeGen/AMDGPU/elf-header-flags-sram-ecc.ll
  llvm/test/CodeGen/AMDGPU/sramecc-subtarget-feature-default.ll
  llvm/test/CodeGen/AMDGPU/sramecc-subtarget-feature-disabled.ll
  llvm/test/CodeGen/AMDGPU/sramecc-subtarget-feature-enabled.ll
  llvm/test/CodeGen/AMDGPU/xnack-subtarget-feature-default.ll
  llvm/test/CodeGen/AMDGPU/xnack-subtarget-feature-disabled.ll
  llvm/test/CodeGen/AMDGPU/xnack-subtarget-feature-enabled.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D85882.285271.patch
Type: text/x-patch
Size: 24731 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200813/45f238c5/attachment.bin>


More information about the llvm-commits mailing list