On Fri, Oct 26, 2012 at 3:55 AM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Richard Sandiford <rdsandif...@googlemail.com> writes: >> Sorry HJ, I got your message just after committing. >> >> "H.J. Lu" <hjl.to...@gmail.com> writes: >>> Please try your patch on Linux/ia32 with go enabled. There is >>> one go test which runs for a long time: >>> >>> 8149 hjl 20 0 49388 40m 9.8m R 99.3 0.3 15:18.35 go1 >>> >>> and it is still running. >> >> Are you sure this new? I can see long tests in libgo too, but the ones >> I looked at were because of long var-tracking times: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54507 >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 >> >> If it is new, which test has got worse? > > FWIW, I tried reverting all my patches from yesterday and then > bootstrapped on ia32. My results were similar to Uros's: > the libgo reflect test took 46m 40s to compile, but without > var tracking it took 20s. I checked that the compile time > without var tracking was still 20s after reapplying my patches, > and that the patches didn't affect the asm output. > > Richard >
You are right. reflect test took a long time to compile. It has nothing to with LRA. -- H.J.
