<div dir="ltr">Hi Quentin,<div><br></div><div>Thanks for your feedback!<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><span style="font-family:arial,helvetica,sans-serif">ARM64 generates pseudo instructions ARM64::MOVaddr and friends in ISEL stage, which intends to guarantee address serialization (page address + in-page address), and exposes adrp finally by pass ExpandPseudoInsts. The assumption of ARM64 solution is we don't know the in-page offset can be fused into load/store or not at compile time, and this assumption would turn to be not true any longer for the solution of using global merge as I proposed with the patch.</span><br>
</div></div></blockquote></div>I think this is orthogonal. If you happen to merge globals they will have the same base address (i.e., the same pseudo instruction) but different offsets.</div><div>CSE and such will work like a charm for the pseudos.</div>
</div></blockquote><div><br></div><div>This is probably not true. Global merge pass happens in PreIsel stage. For my test case at <a href="http://reviews.llvm.org/D3223">http://reviews.llvm.org/D3223</a>, after applying the patch, we will have LLVM IR as below,</div>
<div><br></div><div><div> store i32 %a1, i32* getelementptr inbounds ({ i32, i32, i32 }* @_MergedGlobals_x, i32 0, i32 0), align 4</div><div> store i32 %a2, i32* getelementptr inbounds ({ i32, i32, i32 }* @_MergedGlobals_x, i32 0, i32 1), align 4</div>
</div><div><br></div><div>and after ISEL stage, we can see different Machine Instructions generated for AArch64 and ARM64.</div><div><br></div><div>AArch64:</div><div><br></div><div><div> %vreg4<def> = ADRPxi <ga:@_MergedGlobals_x>; GPR64noxzr:%vreg4</div>
<div> LS32_STR %vreg3, %vreg4, <ga:@_MergedGlobals_x>[TF=11]</div><div> %vreg5<def> = ADDxxi_lsl0_s %vreg4, <ga:@_MergedGlobals_x>[TF=11]; GPR64noxzr:%vreg5,%vreg4</div><div> LS32_STR %vreg2, %vreg5<kill>, 1</div>
</div><div><br></div><div>ARM64:</div><div> </div><div><div> %vreg2<def> = ADRP <ga:@_MergedGlobals_x>[TF=1]; GPR64common:%vreg2</div><div> STRWui %vreg0, %vreg2<kill>, <ga:@_MergedGlobals_x>[TF=18]</div>
<div> %vreg3<def> = MOVaddr <ga:@_MergedGlobals_x>[TF=1], <ga:@_MergedGlobals_x>[TF=18]; GPR64common:%vreg3</div><div> STRWui %vreg1, %vreg3<kill>, 1</div></div><div><br></div><div>The problem is MOVaddr generated for ARM64 implies introducing adrp in ExpandPseudoInsts pass again, although at this moment we don't really see redundant ADRP yet. AArch64 is using ADDxxi_lsl0_s instead, and it will be folded into LS32_STR finally.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Assuming you emit the right instructions at isel time, you will create ADRP, LOADGot, or ADD with symbols. Since you do not know anything on the symbols, CSE will match only the ones that are identical.</div>
</div></blockquote><div><br></div><div>This is correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>You will have a finer granularity to do CSE, but I am not sure it will help that much.</div></div></blockquote><div><br></div><div>The 'CSE' here is a term only rather than the traditional CSE. Since global variables are merged into a monolithic data structure, the we will be able to generate only one base address (page address) for all of those global variables.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>On the other hand, you lose the rematerialization capability, because that feature can only handle one instruction at a time. So you will still be able to rematerialize ADRP but not the LOADGot and ADD with symbols.</div>
</div></blockquote><div><br></div><div>Yes, but this depends on register pressure, and it's hard to tell rematerialization is always good.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div style="font-family:arial,helvetica,sans-serif;font-size:small">If simply apply the global merge solution to ARM64, probably we should avoid generating pseudo instruction MOVaddr and friends in ISEL stage, but I'm not sure if the LOH solution would still work or not, because,</div>
<div style="font-family:arial,helvetica,sans-serif;font-size:small">1) ARM64 link-time optimization depends on LOH.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small">
2) We don't see linker plug-in in LLVM trunk and it would be hard for me to verify any thoughts.</div></div></div></blockquote></div><div>The LOH solution is also orthogonal. You can see that as a last chance way to optimize those accesses.</div>
<div>That said, if you CSE the ADRP and not the LOADGot, you will indeed create far less candidates for the LOHs because you will have ADRPs with several uses, which is not supported by LOHs.</div></div></div></blockquote>
<div><br></div><div>Yes. This is just what I'm worrying about. So essentially those two optimizations have conflict.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>FYI, the LOH optimization is not a link-time optimization in LLVM, this is really a link-time optimization: on the binary.</div></div></div></blockquote><div><br></div><div>Yes. I see. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class=""><blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div style="font-family:arial,helvetica,sans-serif;font-size:small">
Any concrete suggestion of combining those different ADRP CSE solutions and tests would be appreciated! </div></div></div></blockquote></div><div>The bottom line is whatever you are doing with merge globals, it is orthogonal with LOHs.</div>
<div>That said I think it is best to keep the pseudo instructions.</div></div></div></blockquote><div><br></div><div>Well, if we keep the pseudo instruction MOVaddr, we would have to keep adrp and expose it to binary, so it would lose the opportunity of removing redundant adrp at compile-time.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Of course I may be wrong and the best way to check would be to measure what happens if you get rid of the pseudo instructions. Do not be too concerned with the impact on the LOHs.</div>
</div></div></blockquote><div><br></div><div>Since compile-time ADRP CSE is not so powerful as link-time ADRP removal, I don't want to hurt link-time solution.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br></div><div>Thanks,</div><div>-Quentin</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div style="font-family:arial,helvetica,sans-serif;font-size:small">
<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small">
Thanks,</div><div style="font-family:arial,helvetica,sans-serif;font-size:small">-Jiangning</div><br></div></div><div class="">
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></div></blockquote></div><br></div></div></div>