Bug 55092

Summary:	[4.8/4.9 Regression] LRA aggravates var-tracking scalability problems
Product:	gcc	Reporter:	H.J. Lu <hjl.tools>
Component:	rtl-optimization	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	jakub, vmakarov
Priority:	P3	Keywords:	compile-time-hog
Version:	4.8.0
Target Milestone:	4.8.3
Host:		Target:
Build:		Known to work:
Known to fail:		Last reconfirmed:	2012-10-27 00:00:00
Bug Depends on:	54402
Bug Blocks:

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