This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] Factored PAL metadata handling out into its own class
ClosedPublic

Authored by tpr on Jan 21 2019, 9:46 AM.

Details

Summary

This commit introduces a new AMDGPUPALMetadata class that:

  • is inside the AMDGPU target;
  • keeps an in-memory representation of PAL metadata;
  • provides a method for use by LLPC to write metadata into LLVM IR;
  • provides a method to read the frontend-supplied metadata from LLVM IR;
  • provides methods for the asm printer to set metadata items;
  • provides methods to write the metadata as a binary blob to put in a .note record or as an asm directive;
  • provides a method to read the metadata as a binary blob from a .note record.

Because llvm-readobj cannot call directly into a target, I had to remove
llvm-readobj's ability to dump PAL metadata, pending a resolution to
https://reviews.llvm.org/D52821

Change-Id: I756dc830894fcb6850324cdcfa87c0120eb2cf64

Diff Detail

Repository
rL LLVM

Event Timeline

tpr created this revision.Jan 21 2019, 9:46 AM

The code looks good to me, but I'm wondering why the move from doing this in AsmPrinter::EmitEndOfAsmFile to TargetStreamer::finish? It seems like it is fine to emit directives in either, but I don't understand why the change here.

Herald added a project: Restricted Project. · View Herald TranscriptFeb 1 2019, 1:48 PM
scott.linder added inline comments.Feb 1 2019, 1:55 PM
lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.h
85 ↗(On Diff #182808)

How is the front-end structured so that it has access to this header? I thought all of the headers in the AMDGPU target were private.

arsenm added inline comments.Feb 1 2019, 1:57 PM
lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.h
85 ↗(On Diff #182808)

They are

tpr added a comment.Feb 4 2019, 9:50 AM

The code looks good to me, but I'm wondering why the move from doing this in AsmPrinter::EmitEndOfAsmFile to TargetStreamer::finish? It seems like it is fine to emit directives in either, but I don't understand why the change here.

The idea was so that a disassembler disassembling into a TargetStreamer would go through the same code to emit the directives.

tpr marked an inline comment as done.Feb 4 2019, 9:53 AM
tpr added inline comments.
lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.h
85 ↗(On Diff #182808)

Right, I've got the frontend diving in and directly including the .h file from inside lib/Target/AMDGPU. Is that bad? Is that an argument for going back to putting this stuff, maybe excluding the parts used by codegen, in lib/BinaryFormat, or something?

In D57027#1383432, @tpr wrote:

The code looks good to me, but I'm wondering why the move from doing this in AsmPrinter::EmitEndOfAsmFile to TargetStreamer::finish? It seems like it is fine to emit directives in either, but I don't understand why the change here.

The idea was so that a disassembler disassembling into a TargetStreamer would go through the same code to emit the directives.

That sounds reasonable to me, I was just curious if HSA should move where it emits the equivalent metadata note to the streamer as well.

lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.h
85 ↗(On Diff #182808)

My understanding is that directly referencing private headers, like those in lib/Target/AMDGPU, is not correct. One immediate issue you might encounter is that the headers do not exist in the installed copy of LLVM, meaning you will only be able to compile against the LLVM build directory. I think you're right that this is an argument for moving anything intended for use outside of the backend to somewhere public.

tpr updated this revision to Diff 191102.Mar 18 2019, 8:52 AM

V2: Removed AMDGPUPALMetadata API used directly by LLPC. The plan now is

that LLPC will continue to put the PAL metadata binary blob
into IR metadata itself.
tpr marked 3 inline comments as done.Mar 18 2019, 8:56 AM
tpr added inline comments.
lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.h
85 ↗(On Diff #182808)

LLPC no longer dives in to access the private header, and I have removed the API that LLPC was using.

scott.linder added inline comments.Mar 18 2019, 4:12 PM
lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.h
12 ↗(On Diff #191102)

I think #include "Utils/AMDGPUPALMetadata.h" should be enough?

lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.cpp
41–45 ↗(On Diff #191102)

Even if you keep going with whatever you can get out of the IR, if it is malformed I would emit some sort of diagnostic. Maybe return a bool like in setFromBlob and emit a diagnostic in AMDGPUAsmPrinter::EmitStartOfAsmFile?

53 ↗(On Diff #191102)

Am I missing the use of this? Or is this here for when objdump can disassemble the note again?

189–195 ↗(On Diff #191102)

I think this kind of pun is UB in C++, and this doesn't handle big-endian hosts. A memcpy would work, but would still require handling endianness. I think just masking out each individual byte handles everything.

arsenm added inline comments.Mar 18 2019, 4:18 PM
lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.cpp
170–177 ↗(On Diff #191102)

Single quotes around the single characters

189–195 ↗(On Diff #191102)

Three's an endianness writer in support

tpr updated this revision to Diff 191254.Mar 19 2019, 12:44 AM
tpr marked 3 inline comments as done.

V3: Fixed review comments.

tpr marked 4 inline comments as done.Mar 19 2019, 12:45 AM
tpr added inline comments.
lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.cpp
41–45 ↗(On Diff #191102)

Val==0 is certainly not malformed, it's just that we don't need a map entry for a 0 value register. Key==0 is arguably malformed, but I think LLPC actually does it, so I would rather not emit a diagnostic for it.

53 ↗(On Diff #191102)

Yes, we want objdump to use it again one day via a new target abstraction, and we have an out-of-tree utility that uses it.

scott.linder accepted this revision.Mar 19 2019, 7:36 AM

LGTM, thanks! I think you can also drop "provides a method for use by LLPC to write metadata into LLVM IR" from the commit message.

lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.cpp
41–45 ↗(On Diff #191102)

That make sense, but what about cases where Tuple->getNumOperands() is odd? It seems like values are just silently ignored? In the end the values are probably not being edited, and you will be deleting this code, so I'm OK with dropping the odd value.

This revision is now accepted and ready to land.Mar 19 2019, 7:36 AM
This revision was automatically updated to reflect the committed changes.