On 8/19/21 9:36 AM, Segher Boessenkool wrote:
On Thu, Aug 19, 2021 at 09:03:44AM -0600, Martin Sebor via Gcc-patches wrote:
On 8/18/21 11:56 PM, Kewen.Lin wrote:
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?
I wouldn't expect that to make a difference. There are thousands
of similar calls to build_int_cst() throughout the middle end.
But it does make a huge difference. It has nothing to do with the calls
to build_int_cst, either.
Please don't mess with GTY (and call it a refactoring, to add insult to
injury) if you do not know what you are doing :-(
As I explained, the leak was caused by failing to pair the call to
enable_ranger() with the corresponding call to disable_ranger().
The removal of the global GTY variable has no impact on the test
case, or on memory usage in general. That said, I introduced
the variable in r243470 to begin with and I consider its removal
a trivially correct and appropriate part of refactoring.
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.
The testcase is super heavy in the instruction combiner, so you get a
lot of garbage. Which is not a problem, except you made the garbage
collector not pick this up, so we get a ton of garbage accumulating.
Neither that nor anything else you said is relevant or helpful.
On the off chance were trying to be and not just using this as
an opportunity to lecture, I recommend you do your homework
first next time and choose your words more carefully.
Martin
