This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: LRA for x86/x86-64 [0/9]
On Sun, Sep 30, 2012 at 6:01 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>>> ----------------------------------64-bit:-----------------------------------
>>> Reload:
>>> 503.26user 36.54system 30:16.62elapsed 29%CPU (0avgtext+0avgdata
>>> LRA:
>>> 598.70user 30.90system 27:26.92elapsed 38%CPU (0avgtext+0avgdata
>>
>> This is a ~19% slowdown
>
> I think both measurements run into swap (low CPU utilization), from the LRA
> numbers I'd say that LRA uses less memory but the timings are somewhat
> useless with the swapping.
Not on gcc17. It has almost no swap to begin with, but the max.
resident size is less than half of the machine's RAM (~7GB max.
resident vs 16GB machine RAM). It obviously has to do with memory
behavior, but it's probably more a matter of size (>200,000 basic
blocks, >600,000 pseudos, etc., basic blocks with livein/liveout sets
with a cardinality in the 10,000s, etc.), not swapping.
> It would be nice to see if LRA just has a larger constant cost factor
> compared to reload or if it has bigger complexity.
It is complexity in all typical measures of size (basic blocks, number
of insns, number of basic blocks), that's easily verified with
artificial test cases.
>> The code size changes are impressive, but I think that this kind of
>> slowdown should be addressed before making LRA the default for any
>> target.
>
> Certainly if it shows bigger complexity, not sure for the constant factor
> (but for sure improvements are welcome).
>
> I suppose there is the option to revert back to reload by default for
> x86_64 as well for 4.8, right? That is, do both reload and LRA
> co-exist for each target or is it a definite decision target by target?
Do you really want to have two such bug-sensitive paths through of the compiler?
Ciao!
Steven