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