<div dir="ltr">Hi Rafael,<div><br></div><div>I think now I understand your point and agree with you this alignment setup can be treated as a pure back-end issue AArch64 can handle it privately and we can avoid exposing it to shared code.</div>
<div><br></div><div>So now attached is the updated patch by removing -global-merge-aligned switch. I will work out separate patches to handle AArch64 specific stuff later on.</div><div><br></div><div>Thanks,</div><div>-Jiangning</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-03 22:16 GMT+08:00 Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> (1) We probably should change the global merge algorithm by considering the<br>
> global symbols function by function, which could finally benefit linker to<br>
> remove dead global symbols. I think I agree with that, but I want to leave<br>
> it for further improvement in future, so I added a FIXME in my new patch to<br>
> explain the issue.<br>
<br>
</div>OK.<br>
<div class=""><br>
> (2) We should avoid adding target dependent interfaces in middle-end, so it<br>
> would be better we don't add getGlobalMergeAlignment. I consider it again,<br>
> and think we still need this, and it is orthogonal with (1). For AArch64, we<br>
> need this because we want to make sure the merged global variable doesn't<br>
> cross page boundary, and this could finally remove one more "addition"<br>
> instruction finally.<br>
<br>
</div>But there is nothing special about a merge variable, right?  Consider<br>
two cases. In the first, the source code has a user defined type and<br>
global:<br>
<br>
struct foo {<br>
  int a;<br>
   int b;<br>
} my_global;<br>
<br>
int the second case the globals are just "int a;" and "int b;". In the<br>
second case we decide to concatenate 'a' and 'b'. Any alignment<br>
advantage that can be had in the second case also applies to the<br>
first, so it seems this should just be an independent optimization in<br>
the aarch64 backend.<br>
<br>
A related issue is that we probably don't want to have codegen options<br>
like global-merge-aligned.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>