[PATCH] more warning code refactoring

Martin Sebor msebor@gmail.com
Fri Aug 20 14:49:48 GMT 2021


On 8/19/21 7:38 PM, Kewen.Lin wrote:
> 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!

No worries.  It was a reasonable first guess.

Martin

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