<div dir="ltr">Hi Quentin,<div class="gmail_extra"><br></div><div class="gmail_extra">I thought I misunderstood you, but looking at your explanation below, it seems I wasn't. See my answer below,</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><div class="gmail_quote">2014-04-25 1:06 GMT+08:00 Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span>:<br><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">
Hi Jiangning,<br>
<div class=""><br>
> I think you are correct the merged size can't be simply accumulated by indivisual global variable size, because of natural alignment requirement inside the merged data structure.<br>
<br>
</div>The size is fine, we accumulate for AllocSize, i.e., with padding and such.<br>
What I meant is the alignment of the whole structure does not look reasonable :).<br>
<br>
To be more specific, I think we should set the alignment of the merge structure to DL->getABIAlignment(MergedTy), or something like that.<br>
<br>
The example I had in mind was:<br>
@a1 = global i32 align 4<br>
@a2 = global i32 align 4<br>
@a3 = global i32 align 4<br>
@a4 = global i32 align 4<br>
=><br>
struct MergeGlobal {<br>
 i32, i32, i32, i32<br>
}<br>
With the current approach we would get an alignment of 4*4 = 16, whereas 4 may have been enough. Anyhow, this depends on the data layout.<br></blockquote><div><br></div><div>No. I think it should be 16, otherwise this MergeGlobal maybe cross page boundary, and the offset would not be able to fused into load/store instruction at compile-time.</div>
<div><br></div><div>If we set alignment to 16, we would be able to guarantee at compile-time that MergeGlobal is always within a page. The load/store instruction requires the offset is not larger than the value holding 4096 element. Conservatively, we can treat it as a page limitation, although in reality it only holds for bye element.</div>
<div><br></div><div>Could you please look into again my last reply at <a href="http://reviews.llvm.org/D3432#14">http://reviews.llvm.org/D3432#14</a> containing the summary of three different solutions? My choice is solution 2). I drew some text charts to elaborate the idea. For your example, I'm hoping we can at compile-time generate a single ADRP and no ADD instruction at all.</div>
<div><br></div><div>Thanks,<br></div><div>-Jiangning</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">

<br>
Thanks for looking into it.<br>
<br>
-Quentin<br>
<br>
<a href="http://reviews.llvm.org/D3432" target="_blank">http://reviews.llvm.org/D3432</a><br>
<br>
<br>
</blockquote></div><br></div></div>