This is an archive of the discontinued LLVM Phabricator instance.

[MC] Add MCSubtargetInfo to MCAlignFragment
ClosedPublic

Authored by peter.smith on Apr 23 2018, 7:23 AM.

Details

Summary

In preparation for passing the MCSubtargetInfo (STI) through to writeNops so that it can use the STI in operation at the time, we need to record the STI in operation when a MCAlignFragment may write nops as padding. The STI is currently unused, a further patch will pass it through to writeNops.

There are many places that can create an MCAlignFragment, in most cases we can find out the STI in operation at the time. In a few places this isn't possible as we are in initialisation or finalisation, or are emitting constant pools. When possible I've tried to find the most appropriate existing fragment to obtain the STI from, when none is available use the per module STI.

For constant pools we don't actually need to use EmitCodeAlign as the constant pools are data anyway so falling through into it via an executable NOP is no better than falling through into data padding.

This is part 2 of 3 of a patch series to pass MCSubtargetInfo to writeNops so that the ARM Backend can remove the per-module STI that is used to decide which nop encodings can be used.

This requires an interface change to InitSections to included a MCSubtargetInfo.

1 [MC] Move bundling and MCSubtargetInfo to MCEncodedFragment [NFC] D44928 (committed)
2 [MC] Add MCSubtargetInfo to MCAlignFragment D45961
3 [MC] Use local MCSubtargetInfo in writeNops D45962

This patch depends on D44928.

Diff Detail

Event Timeline

peter.smith created this revision.Apr 23 2018, 7:23 AM

Rebased [NFC]

asb added a comment.Aug 15 2018, 6:51 AM

You will also need to patch at least clang tools/driver/cc1as_main.cpp due to the change to InitSections.

Mechanically the changes seem fine. There's one aspect I'd appreciate further comment on: having to perform getLastSubtargetInfo seems pragmatic but feels ugly. Are there cases where this might be incorrect? Should there be a FIXME indicating that some superior solution for ensuring access to an appropate MCSubtargetInfo should be implemented?

In D45961#1200623, @asb wrote:

You will also need to patch at least clang tools/driver/cc1as_main.cpp due to the change to InitSections.

Mechanically the changes seem fine. There's one aspect I'd appreciate further comment on: having to perform getLastSubtargetInfo seems pragmatic but feels ugly. Are there cases where this might be incorrect? Should there be a FIXME indicating that some superior solution for ensuring access to an appropate MCSubtargetInfo should be implemented?

Thanks for the review. I think that in the context that it is used getLastSubtargetInfo() is at, however that doesn't mean that it could potentially be used in a different context in the future.

  • For a section with ConstantPools we are guaranteed to have at least one MCFragment with a valid MCSubtarget as there must exist a fragment with an instruction that needs a constant pool entry. In theory given that constant-pools are not instructions it shouldn't actually matter what the encoding of the NOP is because there will most likely be a crash if control flow gets to the constant pool.
  • For the Mips RoundSectionSizes option then if the last fragment has instructions we can use its MCSubtarget for the NOP and if not then we can use the per translation unit MCSubtarget. Moreover Mips doesn't even use the Subtarget when determining the NOP encoding anyway.

With this in mind it may be better to change the code so that getLastSubtargetInfo() is no longer required.

  • In ConstantPools.cpp::emitEntries() don't use EmitCodeAlignment(), use EmitValueToAlignment() instead. As mentioned above valid code shouldn't ever fall through the padding into the constant pool.
  • In Mips we can just use the global STI as there is only one NOP encoding anyway.

I don't think that there are many alternative implementations unless we make the getSubtargetInfo() return a pointer rather than a reference. I'm not sure if that would be a change worth making.

If it sounds ok to you, I can post another patch without getLastSubtargetInfo()?

One possible option might be to fix the surrounding code so that getLastSubtargetInfo() isn't needed.

asb added a comment.Aug 16 2018, 6:38 AM

I like the idea of rejigging this so getLastSubtargetInfo isn't needed.

Using EmitValueToAlignment in constant pools seems more correct to me anyway - or at least, I can't think of a disadvantage.

peter.smith edited the summary of this revision. (Show Details)

I've uploaded a new version that doesn't use getLastSubtargetInfo(). Thanks for the warning about clang tools/driver/cc1as_main.cpp I've not seen anywhere else in the project that uses InitSections(). The code there will become:

Str.get()->InitSections(Opts.NoExecStack, *STI);

As the STI has been computed earlier. I'm happy to post another review if people prefer? Otherwise I could just make the change immediately after where this to be committed.

Uploaded rebased diff, no functional changes.

efriedma accepted this revision.Jul 29 2021, 2:55 PM
efriedma added a subscriber: efriedma.

LGTM

This revision is now accepted and ready to land.Jul 29 2021, 2:55 PM
peter.smith edited the summary of this revision. (Show Details)

Rebase after patch approval from some time ago. No significant changes.

I've noticed that the MCPaddingFragment that I modified in D45960 no longer exists so I've removed that from the description. Will look at rebasing D45962 next.

Herald added a project: Restricted Project. · View Herald TranscriptAug 6 2021, 10:01 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
MaskRay accepted this revision.Aug 6 2021, 10:43 AM
MaskRay added a subscriber: MaskRay.
MaskRay added inline comments.
llvm/include/llvm/MC/MCStreamer.h
450 ↗(On Diff #364835)

If InitSections is going to be changed, perhaps fix the case to initSection

peter.smith retitled this revision from [MC] Add MCSubtargetInfo to MCAlignFragment [NFC] to [MC] Add MCSubtargetInfo to MCAlignFragment.
peter.smith edited the summary of this revision. (Show Details)

Rebased patch (sorry for the delay). I've added fixup code for the interface change to InitSections for clang and one of the unit tests. I've also removed the [NFC] as this will likely break a lot of downstream tools using MC.

An alternative implementation that is less disruptive would make the MCSubtargetInfo an optional parameter that could be nullptr but that would mean that we'd need to test in emitNops whether the MCSubtargetInfo is nullptr which is not ideal but it may lead to a much smaller patch for this and D45962

Rebased again. Updated DWARFExpressionCopyBytesTest.cpp to account for changes. I've checked that LLDB and flang build with it as well (I didn't need any changes).

Would like a double check on D45962 as I had to change quite a bit of code since the previous rebased patch. If that is still OK I can commit both at the same time.

bcain added a subscriber: bcain.Sep 3 2021, 10:15 AM
MaskRay added inline comments.Sep 4 2021, 10:22 AM
llvm/include/llvm/MC/MCFragment.h
314 ↗(On Diff #370610)

"Don’t duplicate function or class name at the beginning of the comment."

from https://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
278 ↗(On Diff #370610)

This can be deleted.

284 ↗(On Diff #370610)
llvm/unittests/DebugInfo/DWARF/DWARFExpressionCopyBytesTest.cpp
138 ↗(On Diff #370610)

emitNops does not have the STI argument in this patch.

The diff was probably created by hand.
arc patch D45961 cannot apply this patch but curl -L 'https://reviews.llvm.org/D45961?download=1' | patch -p0 can.

https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-command-line
It's a one-time setup. One it is set, the arc diff 'HEAD^' uploaded patch should be testable by builkite.
See "Build Status" currently it cannot apply the patch https://buildkite.com/llvm-project/diff-checks/builds/62270#202c5d24-7b92-474c-aa62-b0e52e14fb56

The diff was probably created by hand.
arc patch D45961 cannot apply this patch but curl -L 'https://reviews.llvm.org/D45961?download=1' | patch -p0 can.

https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-command-line
It's a one-time setup. One it is set, the arc diff 'HEAD^' uploaded patch should be testable by builkite.
See "Build Status" currently it cannot apply the patch https://buildkite.com/llvm-project/diff-checks/builds/62270#202c5d24-7b92-474c-aa62-b0e52e14fb56

Thanks for the comments, I've fixed them up locally and will give arc diff a try.

llvm/include/llvm/MC/MCStreamer.h
450 ↗(On Diff #364835)

Thanks for the suggestion, will do. I'll update on Friday when I'll have an update for D45962

arc diff didn't quite do what I wanted, I have two commits in my branch, one D45961, then D45962 and it only updated D45962. This patch is manually created but should be OK.

Have applied the 3 review comments.

MaskRay accepted this revision.Sep 6 2021, 9:34 AM

arc diff didn't quite do what I wanted, I have two commits in my branch, one D45961, then D45962 and it only updated D45962. This patch is manually created but should be OK.

Have applied the 3 review comments.

I don't know what the best solution... I personally maintain multiple branches and ensure the tip is the Differential I want to update with arc diff 'HEAD^'.

jrtc27 added a comment.Sep 6 2021, 9:35 AM

arc diff didn't quite do what I wanted, I have two commits in my branch, one D45961, then D45962 and it only updated D45962. This patch is manually created but should be OK.

Have applied the 3 review comments.

I don't know what the best solution... I personally maintain multiple branches and ensure the tip is the Differential I want to update with arc diff 'HEAD^'.

In this case you could git rebase -i HEAD^^ and add an x arc diff HEAD^ after the first pick.

MaskRay added inline comments.Sep 6 2021, 9:35 AM
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
278 ↗(On Diff #370923)

STI can be deleted.

Thanks will apply comments prior to commit

This revision was landed with ongoing or failed builds.Sep 7 2021, 7:47 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptSep 7 2021, 7:47 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript