Bug 55092 - [4.8/4.9 Regression] LRA aggravates var-tracking scalability problems
Summary: [4.8/4.9 Regression] LRA aggravates var-tracking scalability problems
Status: RESOLVED DUPLICATE of bug 54402
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: 4.8.3
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog
Depends on: 54402
Blocks:
  Show dependency tree / graph
 
Reported: 2012-10-26 21:54 UTC by H.J. Lu
Modified: 2013-10-25 11:48 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-10-27 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2012-10-26 21:54:11 UTC 
From

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402#c4

-----
As Uros says in bug 54507, the reflect test from libgo is another example.
Without var tracking it takes 20s on my x86_64 box (tested with a 32-bit
compiler).  With var tracking it takes 46m 40s.
-----

It only happens with -m32.  It takes less than 20 seconds for
-m64 and -mx32. Turn-off LRA takes only 13 seconds to finish.
Comment 1 Jakub Jelinek 2012-10-26 22:13:09 UTC 
It isn't LRA that doesn't scale, it is var-tracking memory clobbering that needs improvements, but it would be nice to analyze what are the changes that LRA does compared to reload that make var-tracking to take that much longer and whether the generated code is better or worse.  If it is better, this is just PR54402 dup.
Comment 2 Vladimir Makarov 2012-10-26 22:49:23 UTC 
 LRA reuses stack memory much better than reload (in all modes but especially in -O0).  May be that is the reason of the var-tracking problem.
Comment 3 H.J. Lu 2012-10-26 22:56:55 UTC 
The testcase is compiled with -O2, not -O0.
Comment 4 Vladimir Makarov 2012-10-26 22:57:38 UTC 
(In reply to comment #2)
>  LRA reuses stack memory much better than reload (in all modes but especially
> in -O0).  May be that is the reason of the var-tracking problem.

I forgot to say that LRA understands -fno-ira-share-spill-slots.  In this case,  each pseudo gets own stack slot.

I thing it is worth to try it.
Comment 5 H.J. Lu 2012-10-26 23:03:05 UTC 
-fno-ira-share-spill-slots doesn't make a difference.
Comment 6 Jakub Jelinek 2012-12-10 10:53:50 UTC 
I believe on that testcase it was because without LRA the function didn't use a frame pointer, while with LRA for some reason it does.
Comment 7 Richard Biener 2013-02-26 15:15:27 UTC 
(In reply to comment #6)
> I believe on that testcase it was because without LRA the function didn't use a
> frame pointer, while with LRA for some reason it does.

Can we make this bug a dup or is this now about IRA vs. LRA and the frame
pointer issue?
Comment 8 Jakub Jelinek 2013-03-22 14:45:08 UTC 
GCC 4.8.0 is being released, adjusting target milestone.
Comment 9 Jakub Jelinek 2013-05-31 10:58:47 UTC 
GCC 4.8.1 has been released.
Comment 10 Jakub Jelinek 2013-10-16 09:49:28 UTC 
GCC 4.8.2 has been released.
Comment 11 Richard Biener 2013-10-25 11:48:30 UTC 

*** This bug has been marked as a duplicate of bug 54402 ***