[PATCH] more warning code refactoring

Kewen.Lin linkw@linux.ibm.com
Fri Aug 20 01:38:07 GMT 2021


Hi Martin,

on 2021/8/20 上午12:30, Martin Sebor wrote:
> On 8/19/21 9:03 AM, Martin Sebor wrote:
>> On 8/18/21 11:56 PM, Kewen.Lin wrote:
>>> Hi David,
>>>
>>> on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
>>>> Hi, Martin
>>>>
>>>> A few PowerPC-specific testcases started failing yesterday on AIX with
>>>> a strange failure mode: the compiler runs out of memory.  As you may
>>>> expect from telling you this in an email reply to your patch, I have
>>>> bisected the failure and landed on your commit.  I can alternate
>>>> between the previous commit and your commit, and the failure
>>>> definitely appears with your patch, although I'm unsure how your patch
>>>> affected memory allocation in the compiler.  Maybe moving the code
>>>> changed a type of allocation or some memory no longer is being freed?
>>>>
>>>
>>>
>>> To get rid of GTY variable alloc_object_size_limit looks suspicious,
>>> maybe tree objects returned by alloc_max_size after the change are out
>>> of GC's tracking?
>>>
>>> If the suspicion holds, the attached explorative diff may help.
>>
>> I wouldn't expect that to make a difference.  There are thousands
>> of similar calls to build_int_cst() throughout the middle end.
>>
>> Looking at the original patch, the change that I'm not sure about
>> and that shouldn't have been part of the refactoring is the call
>> to enable_ranger() in pass_waccess::execute().  It's something
>> I was planning to do next.  But even that I wouldn't expect to
>> eat up a whole 1GB or memory.
> 
> I have reproduced the excessive memory consumption with
> the rlwimi-0.c test and a powerpc-linux cross-compiler, and
> confirmed that it is indeed caused by the call to enable_ranger().
> The test defines some six thousand functions so it seems that
> unless each call enable_ranger() is paired with some call to
> release the memory it allocates the memory leaks.
> 
> The removal of the alloc_object_size_limit global variable doesn't
> have any effect on the test case.  The function that used it (and
> now calls build_int_cst () instead) isn't called when the test
> is compiled  (It's only called for calls to allocation functions
> in the source and the test case has none.
> 

Thanks for the clarification and sorry for noisy suspicion!

BR,
Kewen

> Let me take care of releasing the ranger memory.
> 
> Martin
> 
> 
>>
>>>
>>> BR,
>>> Kewen
>>>
>>>> Previously, compiler bootstrap and all testcases ran with a data size
>>>> of 1GB.  After your change, the data size required for those
>>>> particular testcases jumped to 2GB.
>>>>
>>>> The testcases are
>>>>
>>>> gcc/testsuite/gcc.target/powerpc/rlwimi-[012].c
>>>>
>>>> The failure is
>>>>
>>>> cc1: out of memory allocating 65536 bytes after a total of 1608979296
>>>>
>>>> This seems like a significant memory use regression.  Any ideas what happened?
>>
>> Not really.  The patch just moved code around.  I didn't make any
>> changes that I'd expect to impact memory allocation to an appreciable
>> extent, at least not intentionally.  Let me look into it and get back
>> to you.
>>
>> Martin
>>
>>>>
>>>> Thanks, David
>>>>
>>
> 



More information about the Gcc-patches mailing list