On 10/07/2012 02:52 PM, Steven Bosscher wrote:
On Sat, Oct 6, 2012 at 4:52 AM, Vladimir Makarov wrote:
Without this patch:
Compressing live ranges: from 700458 to 391665 - 55%, pre_count
40730653, post_count 34363983
max per-reg pre_count 12978 (228090, 2 defs, 2 uses) (reg/f:DI 228090
[ SR.2500
On Sat, Oct 6, 2012 at 4:52 AM, Vladimir Makarov wrote:
>> Without this patch:
>> Compressing live ranges: from 700458 to 391665 - 55%, pre_count
>> 40730653, post_count 34363983
>> max per-reg pre_count 12978 (228090, 2 defs, 2 uses) (reg/f:DI 228090
>> [ SR.25009 ])
>> max per-reg post_count 1096
On 12-10-05 5:53 PM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 2:59 PM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 1:30 PM, Richard Guenther
wrote:
Isn't _REVERSE vs. non-_RESERVE still kind-of "random" order?
Not at this stage. For cfglayout mode I would answer yes, but IRA/LRA
opera
On Thu, Oct 4, 2012 at 2:59 PM, Steven Bosscher wrote:
> On Thu, Oct 4, 2012 at 1:30 PM, Richard Guenther
> wrote:
>> Isn't _REVERSE vs. non-_RESERVE still kind-of "random" order?
>
> Not at this stage. For cfglayout mode I would answer yes, but IRA/LRA
> operates in cfgrtl mode, so the sequence
On 10/04/2012 01:44 PM, Vladimir Makarov wrote:
On 10/04/2012 12:56 PM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 6:12 PM, Vladimir Makarov
wrote:
so that I get the timings in the -ftime-report like so:
CPROP : 43.14 ( 4%) usr
integrated RA : 200.81 (17%)
On 10/04/2012 12:56 PM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 6:12 PM, Vladimir Makarov wrote:
0.6% sounds really very different from my timings. How much time does
create_start_finish_chains take for you?
0.65% (2.78s).
Actually, I have a profile but I am not sure now that it is for
On Thu, Oct 4, 2012 at 6:56 PM, Steven Bosscher wrote:
> "Crude, but efficient" (tm) :-)
BTW with a similar approach I also time other bits of process_bb_lives:
timevar_push (TV_HOIST);
/* See if we'll need an increment at the end of this basic block.
An increment is needed if the PSEUDOS
On Thu, Oct 4, 2012 at 6:12 PM, Vladimir Makarov wrote:
>>> 0.6% sounds really very different from my timings. How much time does
>>> create_start_finish_chains take for you?
>>>
>> 0.65% (2.78s).
>>
>> Actually, I have a profile but I am not sure now that it is for PR54146.
>> It might be for PR2
On Thu, Oct 4, 2012 at 5:31 PM, Vladimir Makarov wrote:
>
> Wow. I did not have such effect. What machine do you use?
I do all my testing on gcc17.
Ciao!
Steven
On 10/04/2012 11:45 AM, Vladimir Makarov wrote:
On 10/04/2012 02:57 AM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov
wrote:
I was going to look at this code too but I was interesting in
generation of
less points and live ranges. It is strange that in my profiles,
r
On 10/04/2012 02:57 AM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov wrote:
I was going to look at this code too but I was interesting in generation of
less points and live ranges. It is strange that in my profiles,
remove_some_program_points_and_update_live_ranges t
On 10/04/2012 05:43 AM, Steven Bosscher wrote:
On Wed, Oct 3, 2012 at 5:35 PM, Steven Bosscher wrote:
The "worst" result is this:
Compressing live ranges: from 726174 to 64496 - 8%, pre_count 40476128,
post_count 12483414
But that's still a lot better than before the patch for the same functi
On 10/04/2012 03:24 AM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 8:57 AM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov wrote:
I was going to look at this code too but I was interesting in generation of
less points and live ranges. It is strange that in my prof
On Thu, Oct 4, 2012 at 1:30 PM, Richard Guenther
wrote:
> Isn't _REVERSE vs. non-_RESERVE still kind-of "random" order?
Not at this stage. For cfglayout mode I would answer yes, but IRA/LRA
operates in cfgrtl mode, so the sequence of insns and basic blocks
must match. Therefore, if you walk the b
On Thu, Oct 4, 2012 at 11:43 AM, Steven Bosscher wrote:
> On Wed, Oct 3, 2012 at 5:35 PM, Steven Bosscher wrote:
>> The "worst" result is this:
>> Compressing live ranges: from 726174 to 64496 - 8%, pre_count 40476128,
>> post_count 12483414
>>
>> But that's still a lot better than before the pa
On Wed, Oct 3, 2012 at 5:35 PM, Steven Bosscher wrote:
> The "worst" result is this:
> Compressing live ranges: from 726174 to 64496 - 8%, pre_count 40476128,
> post_count 12483414
>
> But that's still a lot better than before the patch for the same function:
> Compressing live ranges: from 17425
On Thu, Oct 4, 2012 at 8:57 AM, Steven Bosscher wrote:
> On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov wrote:
>> I was going to look at this code too but I was interesting in generation of
>> less points and live ranges. It is strange that in my profiles,
>> remove_some_program_points_and_upd
On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov wrote:
> I was going to look at this code too but I was interesting in generation of
> less points and live ranges. It is strange that in my profiles,
> remove_some_program_points_and_update_live_ranges takes 0.6% of compiler
> time on these huge t
On 12-10-03 11:35 AM, Steven Bosscher wrote:
On Wed, Oct 3, 2012 at 4:56 PM, Vladimir Makarov wrote:
On 12-10-03 3:13 AM, Steven Bosscher wrote:
On Tue, Oct 2, 2012 at 3:42 PM, Richard Sandiford
wrote:
+/* Compress pseudo live ranges by removing program points where
+ nothing happens. Com
On Wed, Oct 3, 2012 at 4:56 PM, Vladimir Makarov wrote:
> On 12-10-03 3:13 AM, Steven Bosscher wrote:
>>
>> On Tue, Oct 2, 2012 at 3:42 PM, Richard Sandiford
>> wrote:
+/* Compress pseudo live ranges by removing program points where
+ nothing happens. Complexity of many algorith
20 matches
Mail list logo
