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

[via llvm-dev]

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? 
If this is pretty common, 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.





> 
> 
>> 
>> __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.