<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 26, 2016 at 3:07 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Aug 26, 2016, at 2:06 PM, Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>> wrote:<br>
><br>
> Mehdi: I see what is going on:<br>
><br>
> +    ArrayType *Ty =<br>
> +        ArrayType::get(Type::<wbr>getInt8Ty(RegularLTO.Ctx), I.second.Size);<br>
> +    GlobalVariable *OldGV = RegularLTO.CombinedModule-><wbr>getNamedGlobal(I.first);<br>
> +    if (OldGV && OldGV->getType()-><wbr>getElementType() == Ty) {<br>
> +      // Don't create a new global if the type is already correct, just make<br>
> +      // sure the alignment is correct.<br>
><br>
> We compare the existing type to an ArrayType constructed from the<br>
> recorded merged common size. So<br>
> the original i32 type does not look the same (since it compares<br>
> against [4 x i8]).<br>
<br>
</span>Right, but that the code I wrote in r279417 right? I guess we should compare the *size* first, and only do something if the size differs.<br></blockquote><div><br></div><div>Yeah. In fact the original handling added in r278338 (addCommons) didn't even compare the size, it always created a new merged common with an ArrayType.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
How was Gold doing it before r278338?<br></blockquote><div><br></div><div>It was just letting the ModuleLinker handle it (which kept the largest one by size), and then it fixed up the alignment later.</div><div><br></div><div>Will change to first compare the size.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
—<br>
<span class="HOEnZb"><font color="#888888">Mehdi<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
><br>
> Not that familiar with type handling in LLVM, but I guess I need to<br>
> just check if the type size is the same?<br>
><br>
> On Fri, Aug 26, 2016 at 1:57 PM, Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>> wrote:<br>
>> Thanks for the test case! I can reproduce this, and see with the<br>
>> compiler I saved from just before r278338 that this is indeed a chance<br>
>> in behavior. Looking at why this changed...<br>
>><br>
>> On Fri, Aug 26, 2016 at 1:42 PM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br>
>>><br>
>>>> On Aug 26, 2016, at 1:34 PM, <a href="mailto:junbuml@codeaurora.org">junbuml@codeaurora.org</a> wrote:<br>
>>>><br>
>>>> On 2016-08-26 12:47, Mehdi Amini wrote:<br>
>>>>>> On Aug 26, 2016, at 9:06 AM, <a href="mailto:junbuml@codeaurora.org">junbuml@codeaurora.org</a> wrote:<br>
>>>>>> On 2016-08-26 11:32, Mehdi Amini wrote:<br>
>>>>>>> Hi,<br>
>>>>>>>> Recently, I noticed that less number of global variables are merged in global-merge pass and in some global variable, array types are used instead of its original type. For example, [4xi8] with align 4 is used for a i32  global variable. For me, it seems that such pattern is observed after r278338  (Resolution-based LTO API).<br>
>>>>>>> Are you sure it is performed in the global merge pass? Can you provide<br>
>>>>>>> an example of input IR where you see this now but didn’t before?<br>
>>>>>>> Also can you confirm you’re using the gold-linker?<br>
>>>>>> I used gold linker. In spec2006/perlbench, I observed the less number of globals are merged in GlobalMerge.cpp after r278338. The reason is because, from the very first pass, several global variables use [4xi8] with align 4, instead of its original type i32 after r278338. Current GlobalMerge pass doesn't seem to handle such fancy-aligned globals. If such type change (e.g., from i32 to [4xi8]) in global variables was intended in r278338, I think we should enhance GlobalMerge to handle such cases.<br>
>>>>> Can you submit a reproduction for Gold please?<br>
>>>>> We need to understand what changed with the new LTO API.<br>
>>>><br>
>>>><br>
>>>> I compiled below C code for aarch64 in lto using gold (--target=aarch64-linux-gnu  -flto -fuse-ld=gold). After r278338, two globals, GVi32_a and GVi32_b, are [4 x i8] type in the input IR to GlobalMerge. Therefore, GlobalMerge do not even start to handle them because as of now it ignores fancy-aligned globals.  Before r278338, GVi32_a and GVi32_b seems to be i32 in the input IR to GlobalMerge. Is this change in the input IR expected ?<br>
>>>><br>
>>>> -------------------------<br>
>>>> int GVi32_a  ;<br>
>>>> int GVi32_b  ;<br>
>>><br>
>>> These are common variables, this is what I mentioned in my first email. Compiling with -fno-commons or defining them with “int GVi32_a = 0;” should solve it.<br>
>>><br>
>>> However r278338 is not supposed to have changed anything on this aspect. I would have expected maybe r279417 playing a role there.<br>
>>><br>
>>> Anyway I don’t have Gold, so I’ll leave Teresa investigate why the change in behavior.<br>
>>><br>
>>> Do you want to try improving global merge to try to handle this case?<br>
>>><br>
>>> —<br>
>>> Mehdi<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>>><br>
>>>> __attribute__((noinline)) void setGV(int a) {<br>
>>>> GVi32_a = a ;<br>
>>>> GVi32_b = a ;<br>
>>>> }<br>
>>>><br>
>>>> __attribute__((noinline)) int loadGV() {<br>
>>>> return GVi32_a + GVi32_b  ;<br>
>>>> }<br>
>>>><br>
>>>> int main(int argc, char *argv[]){<br>
>>>> setGV(argc);<br>
>>>> return loadGV();<br>
>>>> }<br>
>>>> -------------------------<br>
>>>><br>
>>>><br>
>>>><br>
>>>>> —<br>
>>>>> Mehdi<br>
>>>><br>
>>>> --<br>
>>>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.<br>
>>>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.<br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Teresa Johnson | Software Engineer | <a href="mailto:tejohnson@google.com">tejohnson@google.com</a> | <a href="tel:408-460-2413" value="+14084602413">408-460-2413</a><br>
><br>
><br>
><br>
> --<br>
> Teresa Johnson | Software Engineer | <a href="mailto:tejohnson@google.com">tejohnson@google.com</a> | <a href="tel:408-460-2413" value="+14084602413">408-460-2413</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>