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.
Details
Diff Detail
Event Timeline
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. |
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. |
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.
Thanks for pointing out. I missed the comments "easily during the layout process." and "wait for another pair of eyes" unintentionally.
Commit https://reviews.llvm.org/rG2ac19feb1571960b8e1479a451b45ab56da7034e causes some test case to run fail and was reverted by me. We need some fixes for this.
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.
auto -> int