This is an archive of the discontinued LLVM Phabricator instance.

[DirectX][MC] Add MC support for DXContainer
ClosedPublic

Authored by beanz on Jun 6 2022, 4:29 PM.

Details

Summary

DXContainer files resemble traditional object files in that they are
comprised of parts which resemble sections. Adding DXContainer as an
object file format in the MC layer will allow emitting DXContainer
objects through the normal object emission pipeline.

Diff Detail

Event Timeline

beanz created this revision.Jun 6 2022, 4:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 6 2022, 4:29 PM
beanz requested review of this revision.Jun 6 2022, 4:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 6 2022, 4:29 PM
beanz updated this revision to Diff 434651.Jun 6 2022, 5:29 PM

Properly setting the shader kind and version.

beanz updated this revision to Diff 434655.Jun 6 2022, 5:47 PM

Fixing an include guard.

kuhar added inline comments.Jun 6 2022, 8:28 PM
llvm/include/llvm/MC/MCContext.h
667

nit: Other function comments start with 3 slashes

llvm/include/llvm/MC/MCDXContainerStreamer.h
10

Could we also describe what features this implementation *does* use and why it's needed for DXContainers?

36

Shouldn't one virtual function be defined in a cpp file? https://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers

Separately, I'm concerned about unused argument warnings. (Also with other functions in this patch. If there are existing functions with named but unused arguments in the surrounding code, please disregard this comment.)

llvm/include/llvm/MC/MCDXContainerWriter.h
26

Also here

llvm/include/llvm/MC/MCSectionDXContainer.h
34

Also here

llvm/lib/MC/MCContext.cpp
847

Can we use a more descriptive variable name? The uses like R.first->second don't help much wrt readability.

For example, what if we renamed Section -> SectionName and did something like:

auto ItInsertedPair = DXCUniquingMap.try_emplace(SectionName);
StringMapEntry<MCSectionDXContainer *> &Entry = *ItInsertedPair.first;

if (!ItInsertedPair.second)
  return Entry;

Entry.setValue(new (DXCAllocator.Allocate()) MCSectionDXContainer(SectionName, K, nullptr));
...

return Entry.getValue();

(pseudocode, I haven't actually tried it)

851

Isn't this the same as the Section argument?

llvm/lib/MC/MCDXContainerStreamer.cpp
24

ubernit: auto *S, since the type is obvious

llvm/lib/MC/MCDXContainerWriter.cpp
51

How did you pick this constant?

76

nit: This is probably pedantic, but I think technically characters don't have to use ASCII on all platforms and it would be safer to use exact hex values.

beanz marked 7 inline comments as done.Jun 7 2022, 8:35 AM

Updates coming.

llvm/lib/MC/MCContext.cpp
851

It should be the same text, but is likely a different address. The address from the StringMap is guaranteed to remain valid through the lifetime of the object writer, while the input may come from an IR construct that has a different lifetime (aren't unowned StringRefs fun?).

llvm/lib/MC/MCDXContainerWriter.cpp
51

DXContainers generally end up with 7-10 parts. I picked the next power of two above that range so that it would likely all fit in the space. I'll elaborate in a comment.

76

So... I will concede that technically someone could attempt to compile LLVM for a non-ASCII platform, and this _could_ be a problem. If someone were to use this on a non-ASCII platform this would be the least of our problems because we do a lot of string-compares on binary data, and we generally encode section names and other "strings" as ASCII.

How about a happy middle ground, I can make these explicit UTF-8 constants. I prefer the readability of characters rather than needing to keep an ASCII chart handy.

kuhar added inline comments.Jun 7 2022, 8:40 AM
llvm/lib/MC/MCContext.cpp
851

Gah... Can you explain this in a comment?

llvm/lib/MC/MCDXContainerWriter.cpp
76

Ack. I think both of your options are practical. Thanks for explaining.

beanz marked 2 inline comments as done.Jun 7 2022, 9:14 AM
beanz added inline comments.
llvm/lib/MC/MCDXContainerWriter.cpp
76

Gah! UTF-8 character literals are C++17 :(

Since we do have other places (like the ELF ZILB constant) where we assume character literals are ASCII, and I'm completely unaware of any non-ASCII platform that supports enough memory to build or run LLVM, I'm going to prefer to keep this as characters.

beanz updated this revision to Diff 434845.Jun 7 2022, 9:17 AM

Updates based on PR feedback. Thanks @kuhar!

beanz updated this revision to Diff 434848.Jun 7 2022, 9:33 AM

One last bit of feedback from @kuhar that I missed in the last update.

kuhar accepted this revision.Jun 7 2022, 10:44 AM

LGTM but please get a second approval before submitting

This revision is now accepted and ready to land.Jun 7 2022, 10:44 AM

I don't know much about DX but this looks like object emission to me. :)

I guess any problem from these changes will only show up in DX lowering, so not very high risk to other targets...

llvm/lib/MC/MCObjectFileInfo.cpp
1025

What about the DXIL section, do you need to initialise it here, too?

beanz added inline comments.Jun 9 2022, 8:46 AM
llvm/lib/MC/MCObjectFileInfo.cpp
1025

I treat the DXIL section as a data section the same way other backends emit bitcode into sections, so it gets initialized when the global variable emission gets triggered.

Makes sense, I have no additional comments. LGTM, thanks!

arsenm added a comment.Jun 9 2022, 5:25 PM

Probably should have something in docs that explains what this is

MaskRay added inline comments.Jun 10 2022, 2:52 PM
llvm/include/llvm/MC/MCDXContainerWriter.h
21

delete blank line

MaskRay added inline comments.Jun 11 2022, 12:23 AM
llvm/include/llvm/MC/MCSectionDXContainer.h
31

delete

llvm/lib/MC/MCDXContainerWriter.cpp
96
101
108
beanz marked 5 inline comments as done.Jun 13 2022, 6:50 AM
beanz updated this revision to Diff 436376.Jun 13 2022, 6:55 AM

Updating based on feedback from @MaskRay.

Working on additional documentation as well.

beanz added a comment.Jun 13 2022, 8:07 AM

@arsenm, I've posted two additional documentation PRs. One specific to the DirectX backend (D127640), and one for object file support in the code generator more generally (D127645).

This revision was landed with ongoing or failed builds.Jun 17 2022, 7:23 PM
This revision was automatically updated to reflect the committed changes.