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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
