[llvm-dev] Use of array type in globals in LTO

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 26 15:05:34 PDT 2016


> On Aug 26, 2016, at 2:47 PM, junbuml at codeaurora.org wrote:
> 
> On 2016-08-26 16:42, Mehdi Amini wrote:
>>> On Aug 26, 2016, at 1:34 PM, junbuml at codeaurora.org wrote:
>>> On 2016-08-26 12:47, Mehdi Amini wrote:
>>>>> On Aug 26, 2016, at 9:06 AM, junbuml at codeaurora.org wrote:
>>>>> On 2016-08-26 11:32, Mehdi Amini wrote:
>>>>>> Hi,
>>>>>>> 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).
>>>>>> Are you sure it is performed in the global merge pass? Can you provide
>>>>>> an example of input IR where you see this now but didn’t before?
>>>>>> Also can you confirm you’re using the gold-linker?
>>>>> 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.
>>>> Can you submit a reproduction for Gold please?
>>>> We need to understand what changed with the new LTO API.
>>> 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 ?
>>> -------------------------
>>> int GVi32_a  ;
>>> int GVi32_b  ;
>> 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.
>> However r278338 is not supposed to have changed anything on this
>> aspect. I would have expected maybe r279417 playing a role there.
>> Anyway I don’t have Gold, so I’ll leave Teresa investigate why the
>> change in behavior.
>> Do you want to try improving global merge to try to handle this case?
>>>> Mehdi
> 
> 
> I’m that familiar with the common variables and how they are generated?

Common variables are here because in C (not C++) when you see at the file scope "int a;” you don’t know if a is an external declaration (with a definition in another file) or a definition. While if you write “int a = 0;” then it has to be a definition.
The linker has to merge every “common” (“a” need to have the same address when accessed from different files), but has to adjust the size and the alignment to the maximum of all the commons.

Let me know if it isn’t clear.

> If this is pretty common,

They are very “common” ;)
(Sorry)


> then I will happy to improve GlboalMerge to handle them. Before I start looking at this I may want to estimate how often this cause GlobalMerge to lose opportunities.

I was thinking that independently of the common variables, this may enables more opportunities in general.

— 
Mehdi


> 
> 
> 
> 
> 
>>> __attribute__((noinline)) void setGV(int a) {
>>> GVi32_a = a ;
>>> GVi32_b = a ;
>>> }
>>> __attribute__((noinline)) int loadGV() {
>>> return GVi32_a + GVi32_b  ;
>>> }
>>> int main(int argc, char *argv[]){
>>> setGV(argc);
>>> return loadGV();
>>> }
>>> -------------------------
>>>>>>>> Mehdi
>>> --
>>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
> 
> -- 
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160826/0f60d889/attachment.html>


More information about the llvm-dev mailing list