On 10/09/2012 01:06 PM, Richard Guenther wrote:
On Tue, Oct 9, 2012 at 6:10 PM, Vladimir Makarov wrote:
On 10/08/2012 05:14 PM, Steven Bosscher wrote:
On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov
wrote:
So I checked it on big file with > hundred functionson Intel machine and
got
befor
On Tue, Oct 9, 2012 at 6:10 PM, Vladimir Makarov wrote:
> On 10/08/2012 05:14 PM, Steven Bosscher wrote:
>>
>> On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov
>> wrote:
>>
>>> So I checked it on big file with > hundred functionson Intel machine and
>>> got
>>>
>>> before a part of the patch imp
On 10/08/2012 05:14 PM, Steven Bosscher wrote:
On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov wrote:
So I checked it on big file with > hundred functionson Intel machine and got
before a part of the patch implementing the insn stack as sbitmap
real=243.40 user=241.61 system=1.00
after the
On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov wrote:
> I am not a fan of sbitmap for regular use.
Me neither, to be honest. (For the lra-eliminations.c bitmap it was a
particularly bad choice :-)
> This patch definitely helps for
> this particular test. But it might hurt performance for s
On 10/08/2012 01:14 PM, Steven Bosscher wrote:
Hello,
This patch makes lra_constraint_insn_stack_bitmap an sbitmap. This
reduces compile time by another minute or so on gcc17 for the test
case of PR54146, and I think it's a general improvement also for less
extreme code. For cc1-i files the comp
Hello,
This patch makes lra_constraint_insn_stack_bitmap an sbitmap. This
reduces compile time by another minute or so on gcc17 for the test
case of PR54146, and I think it's a general improvement also for less
extreme code. For cc1-i files the compile time change tends to be a
little less but tha
