[PATCH] D146023: [AMDGPU] Remove Code Object V2

Scott Linder via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 1 09:41:14 PDT 2023


scott.linder added inline comments.


================
Comment at: llvm/lib/Target/AMDGPU/AMDGPUHSAMetadataStreamer.cpp:520
 
-  assert(Func.getCallingConv() == CallingConv::AMDGPU_KERNEL ||
-         Func.getCallingConv() == CallingConv::SPIR_KERNEL);
+  if (Func.getCallingConv() != CallingConv::AMDGPU_KERNEL &&
+      Func.getCallingConv() != CallingConv::SPIR_KERNEL)
----------------
I don't follow this change; was the assert just incorrect previously?


================
Comment at: llvm/test/MC/AMDGPU/hsa-gfx10.s:3
-// RUN: llvm-mc -filetype=obj -triple amdgcn--amdhsa -mcpu=gfx1010 --amdhsa-code-object-version=2 -mattr=-wavefrontsize32,+wavefrontsize64 -show-encoding %s | llvm-readobj -S --sd --syms - | FileCheck %s --check-prefix=ELF
-
-// ELF: Section {
----------------
Pierre-vh wrote:
> arsenm wrote:
> > I thought we were still going to be able to read old objects 
> I think llvm-readobj uses all of the MC/Target infrastructure so if we remove emission, we also remove reading, no?
> 
> I'm actually not sure if we plan to let readobj/readelf read COV2 object files, it's an interesting question
I think this is my biggest concern. Do we incur a huge maintenance burden that warrants dropping read support? How much code do we really need to maintain to keep the readobj/objdump like tools universal?

@t-tye do you have any thoughts on whether we should maintain backwards compatibility in the LLVM tooling, even if we drop generation support?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146023/new/

https://reviews.llvm.org/D146023



More information about the cfe-commits mailing list