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