This is an archive of the discontinued LLVM Phabricator instance.

[X86] Not track size of the boudaryalign fragment during the layout
AbandonedPublic

Authored by skan on Feb 29 2020, 2:25 AM.

Details

Summary

Currently the boundaryalign fragment caches its size during the process
of layout and then it is relaxed and update the size in each iteration. This
behaviour is unnecessary and ugly.

Diff Detail

Event Timeline

skan created this revision.Feb 29 2020, 2:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 29 2020, 2:25 AM
skan updated this revision to Diff 247443.Feb 29 2020, 5:49 AM

remove the unused data member Size for MCBoundaryAlignFragment

skan updated this revision to Diff 247488.Feb 29 2020, 11:57 PM

Change a comment

skan retitled this revision from [X86] Make the boudaryalign fragment behave more like align fragment to [X86] Not track size of the boudaryalign fragment during the layout.Mar 1 2020, 12:26 AM
skan edited the summary of this revision. (Show Details)
skan updated this revision to Diff 247491.Mar 1 2020, 1:01 AM
skan edited the summary of this revision. (Show Details)

fix the error reported by clang-tidy

MaskRay accepted this revision.Mar 1 2020, 5:05 PM

Thanks for deleting the Size member variable. It can avoid some cache invalidation problems. LGTM, but please wait for another pair of eyes.

llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
445

easily during the layout process.

This revision is now accepted and ready to land.Mar 1 2020, 5:05 PM
MaskRay added inline comments.Mar 1 2020, 5:06 PM
llvm/lib/MC/MCAssembler.cpp
366

auto -> int

368

Delete excess parentheses.

skan updated this revision to Diff 247536.Mar 1 2020, 5:27 PM

delete excess parentheses

skan marked 2 inline comments as done.Mar 1 2020, 5:28 PM
This revision was automatically updated to reflect the committed changes.
skan marked an inline comment as done.Mar 1 2020, 5:47 PM
skan added inline comments.
llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
445

oh..I missed this comment. Currently there are many redundant boundary align fragments inserted, I will open another revison to fix that and of course the code change will cover this comment.

MaskRay added a comment.EditedMar 1 2020, 6:43 PM

Thanks for deleting the Size member variable. It can avoid some cache invalidation problems. LGTM, but please wait for another pair of eyes.

Closed by commit rG2ac19feb1571: [X86] Not track size of the boudaryalign fragment during the layout (authored by skan). · Explain Why

For this case, it is likely that @reames will want to review the change, so I provided a qualified approval. From D71916 "LGTM - How a Patch Is Accepted":

If it is likely that others will want to review a recently-posted patch, especially if there might be objections, but no one else has done so yet, it is also polite to provide a qualified approval (e.g., "LGTM, but please wait for a couple of days in case others wish to review"). If approval is received very quickly, a patch author may also elect to wait before committing (and this is certainly considered polite for non-trivial patches). Especially given the global nature of our community, this waiting time should be at least 24 hours. Please also be mindful of weekends and major holidays.

The advice may apply to https://reviews.llvm.org/D75017 as well. If Phabricator is telling the truth, with all due respect, Annita has not ever committed to llvm-project and has not actively reviewed the assembly mitigations (there may be some internal review process but that is not visible to us). It was likely that someone would suggest some wording change, so it was not very appropriate to commit just 3 hours (BTW, 18:00~22:00 are not working hours in Pacific Time) after Annita approved the patch. Additionally, IIUC, we are not native English speakers😹 and it would be very helpful to get wording suggestions from others.

Last, from the thread https://lists.llvm.org/pipermail/llvm-dev/2020-January/137889.html . It may be helpful to include Reviewed By: ... in the git commit description.

skan added a comment.Mar 1 2020, 7:11 PM

Thanks for deleting the Size member variable. It can avoid some cache invalidation problems. LGTM, but please wait for another pair of eyes.

Closed by commit rG2ac19feb1571: [X86] Not track size of the boudaryalign fragment during the layout (authored by skan). · Explain Why

For this case, it is likely that @reames will want to review the change, so I provided a qualified approval. From D71916 "LGTM - How a Patch Is Accepted":

Thanks for pointing out. I missed the comments "easily during the layout process." and "wait for another pair of eyes" unintentionally.

skan reopened this revision.Mar 2 2020, 7:39 PM

Commit https://reviews.llvm.org/rG2ac19feb1571960b8e1479a451b45ab56da7034e causes some test case to run fail and was reverted by me. We need some fixes for this.

This revision is now accepted and ready to land.Mar 2 2020, 7:39 PM
skan abandoned this revision.Mar 2 2020, 10:28 PM

In e-mail @reames wrote:

Er, I'm not sure this is correct. The concern is that boundary align requires the computation of the size of a fragment following the boundary align. Since the size may be influenced by the starting offset (e.g. align), the size of the boundary align must already be known. The circularity of the logic there seems likely to lead to issues, though I don't have a specific test case.

Though... I guess the way we use BA makes this "safe" as we know the instructions following must be either DataFragments or RelaxableFragments.

And unfortunately,I did find some test cases failed during runtime. I agree with reame, one difference between boundar align
and align fragment is that the size of boundary align depends on the following fragment while align not. Before finishLayout, we have to fix its size before we write boudary align and this has to be done in relaxBoundaryAlign. I feel sorry that D75203 may need to change some logic since this patch was reverted.

In e-mail @reames wrote:

Er, I'm not sure this is correct. The concern is that boundary align requires the computation of the size of a fragment following the boundary align. Since the size may be influenced by the starting offset (e.g. align), the size of the boundary align must already be known. The circularity of the logic there seems likely to lead to issues, though I don't have a specific test case.

Though... I guess the way we use BA makes this "safe" as we know the instructions following must be either DataFragments or RelaxableFragments.

And unfortunately,I did find some test cases failed during runtime. I agree with reame, one difference between boundar align
and align fragment is that the size of boundary align depends on the following fragment while align not. Before finishLayout, we have to fix its size before we write boudary align and this has to be done in relaxBoundaryAlign. I feel sorry that D75203 may need to change some logic since this patch was reverted.

We also found this patch to cause problems with our downstream testing, though I do not have good reproducers as of right now.