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