This is an archive of the discontinued LLVM Phabricator instance.

[MC] Make it possible for targets to define their own MCObjectFileInfo
ClosedPublic

Authored by flip1995 on May 5 2021, 9:37 AM.

Details

Summary

This MCObjectFileInfo is then used to determine things like section
alignment.

For example, this commit removes the hard-coded 4-byte alignment for
text sections and uses the alignment defined by the target specific
MCObjectFileInfo.

This is a follow up to https://reviews.llvm.org/D101462 and prepares for the
RISCV backend defining the text section alignment depending on the enabled
extensions.

Diff Detail

Event Timeline

flip1995 created this revision.May 5 2021, 9:37 AM
flip1995 updated this revision to Diff 343324.May 6 2021, 1:52 AM
flip1995 edited the summary of this revision. (Show Details)

rebased

flip1995 published this revision for review.May 6 2021, 7:13 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald Transcript

Can you post the RISCV patch depending on this one?

llvm/include/llvm/Support/TargetRegistry.h
1029

https://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments
"Don’t duplicate function or class name at the beginning of the comment."

Just ignore existing comments which do not abide by the standard.

llvm/lib/DWARFLinker/DWARFStreamer.cpp
57–60

The argument is almost always /*MOFI=*/nullptr. Doesn't this regress a bit?

This comment was removed by flip1995.
llvm/include/llvm/Support/TargetRegistry.h
1029

https://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments
"Don’t duplicate function or class name at the beginning of the comment."

Just ignore existing comments which do not abide by the standard.

flip1995 added inline comments.May 7 2021, 1:01 AM
llvm/lib/DWARFLinker/DWARFStreamer.cpp
57–60

I agree. I think the best thing to do here would be to just remove this argument?

Can you post the RISCV patch depending on this one?

Yes, sure. See https://reviews.llvm.org/D102052.

flip1995 updated this revision to Diff 343605.May 7 2021, 1:13 AM

Remove redundant item names in doc comments

flip1995 marked an inline comment as done.May 7 2021, 1:13 AM
MaskRay added inline comments.May 11 2021, 12:20 PM
llvm/include/llvm/MC/MCObjectFileInfo.h
255

This should be moved to D102052

llvm/lib/DWARFLinker/DWARFStreamer.cpp
57–60

I think so. Since MOFI is guaranteed to be constructed after MCContext now.

MaskRay added inline comments.May 11 2021, 12:21 PM
clang/tools/driver/cc1as_main.cpp
407–412

Can we fix the FIXME now?

flip1995 marked an inline comment as done.May 12 2021, 7:11 AM
flip1995 added inline comments.
clang/tools/driver/cc1as_main.cpp
407–412

Not quite. The construction is still in the order MCContext -> MOFI -> "continue construction of MCContext by setting the MOFI". The order just changed from "dummy MOFI" -> MCContext -> "init dummy MOFI".

llvm/include/llvm/MC/MCObjectFileInfo.h
255

Will do.

llvm/lib/DWARFLinker/DWARFStreamer.cpp
57–60

Will do.

flip1995 updated this revision to Diff 344849.May 12 2021, 9:33 AM

rebased and addressed review comments:

  • [MC] Remove MOFI argument from MCContext constructor
  • [MC] Remove getTextSectionAlignment function from MCObjectFileInfo
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2021, 9:33 AM

Can createMCObjectFileInfo return MCObjectFileInfo instead of std::unique_ptr<MCObjectFileInfo>?

clang/lib/Parse/ParseStmtAsm.cpp
591

Can MOFI be null? (i.e. can createMCObjectFileInfo guarantee no-null return value?)

Consider moving the construction below the checks.

Can createMCObjectFileInfo return MCObjectFileInfo instead of std::unique_ptr<MCObjectFileInfo>?

createMCObjectfileInfo returns a MCObjectFileInfo * similar to every other create* function in TargetRegistry.h.

clang/lib/Parse/ParseStmtAsm.cpp
591

You're right. The createMCObjectFileInfo always returns a no-null value. I'll move the construction and remove the check for MOFI.

flip1995 updated this revision to Diff 345432.May 14 2021, 7:06 AM
  • [MC] Don't check if constructed MOFI is a nullptr
flip1995 marked 2 inline comments as done.May 14 2021, 7:07 AM
MaskRay accepted this revision.May 20 2021, 2:51 PM

LGTM. This looks like an improvement because it avoids a temporary MCObjectFileInfo MOFI; (which appeared to be initialized in two subsequent calls) in numerous places.

This revision is now accepted and ready to land.May 20 2021, 2:51 PM
This revision was landed with ongoing or failed builds.May 23 2021, 2:15 PM
This revision was automatically updated to reflect the committed changes.
MaskRay added inline comments.May 25 2021, 10:42 AM
llvm/include/llvm/Support/TargetRegistry.h
26

include/llvm/Support/TargetRegistry.h now has cyclic dependency on include/MC/*.h.

The previous style isn't good as well: include/llvm/Support/TargetRegistry.h has forward declarations of a number of MC* classes.

I think this header probably should be moved to lib/Target.

flip1995 added inline comments.May 26 2021, 2:26 AM
llvm/include/llvm/Support/TargetRegistry.h
26

include/llvm/Support/TargetRegistry.h now has cyclic dependency on include/MC/*.h

I'll submit a quick fix changing this to a forward decl.

I think this header probably should be moved to lib/Target.

The whole TargetRegistry.h header?

flip1995 added inline comments.May 26 2021, 3:47 AM
llvm/include/llvm/Support/TargetRegistry.h
26

I'll submit a quick fix changing this to a forward decl.

I just noticed, that this isn't as easy, as I would've thought, since the MOFI is constructed if no createMCObjectFileInfo callback function is defined by the target.

Because of new MCObjectFileInfo, we cannot use a forward declaration (incomplete class) to replace #include "llvm/MC/MCObjectFileInfo.h" in TargetRegistry.h.

I thought about moving TargetRegistry.{h,cpp} from Support to Target. However, it doesn't work because Bitcode/Object call TargetRegistry::lookupTarget and Bitcode/Object are lower than Target.

@compnerd @dblaikie @mehdi_amini Do you have suggestions on fixing the layering?

Because of new MCObjectFileInfo, we cannot use a forward declaration (incomplete class) to replace #include "llvm/MC/MCObjectFileInfo.h" in TargetRegistry.h.

I thought about moving TargetRegistry.{h,cpp} from Support to Target. However, it doesn't work because Bitcode/Object call TargetRegistry::lookupTarget and Bitcode/Object are lower than Target.

@compnerd @dblaikie @mehdi_amini Do you have suggestions on fixing the layering?

Looks like a big patch and a bit hard for me to page in all the context. Could you summarize the layering constraints/what headers/types/functions are in which libraries and why they are there/what constrains them?