On 12-10-11 5:53 PM, Peter Bergner wrote:
On Tue, 2012-10-02 at 10:57 -0400, Vladimir Makarov wrote:
Chaitin-Briggs literature does not discuss the termination, just saying
that live-ranges shortening will result to assigning hard regs to all
necessary pseudos which is not clearly guaranteed. Th
On Tue, 2012-10-02 at 10:57 -0400, Vladimir Makarov wrote:
> Chaitin-Briggs literature does not discuss the termination, just saying
> that live-ranges shortening will result to assigning hard regs to all
> necessary pseudos which is not clearly guaranteed. There is the same
> problem in LRA. S
On 12-10-04 4:56 PM, Steven Bosscher wrote:
On Tue, Oct 2, 2012 at 3:14 AM, Vladimir Makarov wrote:
Analogous live ranges are used in IRA as intermidiate step to build a
conflict graph.
Right, ira-lives.c and lra-lives.c look very much alike, the only
major difference is that the object of
On Tue, Oct 2, 2012 at 3:14 AM, Vladimir Makarov wrote:
> Analogous live ranges are used in IRA as intermidiate step to build a
> conflict graph.
Right, ira-lives.c and lra-lives.c look very much alike, the only
major difference is that the object of interest in an IRA live range
is an ira_obje
On Sat, Sep 29, 2012 at 10:26 PM, Steven Bosscher wrote:
> To put it in another perspective, here are my timings of trunk vs lra
> (both checkouts done today):
>
> trunk:
> integrated RA : 181.68 (24%) usr 1.68 (11%) sys 183.43
> (24%) wall 643564 kB (20%) ggc
> reload
On Mon, Oct 1, 2012 at 1:11 AM, Steven Bosscher wrote:
> On Mon, Oct 1, 2012 at 12:44 AM, Vladimir Makarov wrote:
>> Actually, I don't see there is a problem with LRA right now. I think we
>> should first to solve a whole compiler memory footprint problem for this
>> test because cpu utilizati
On 10/02/2012 12:22 AM, Jeff Law wrote:
On 10/01/2012 07:14 PM, Vladimir Makarov wrote:
Analogous live ranges are used in IRA as intermidiate step to build a
conflict graph. Actually, the first approach was to use IRA code to
assign hard registers to pseudos (e.g. Jeff Law tried this appro
Il 02/10/2012 10:49, Steven Bosscher ha scritto:
> On Tue, Oct 2, 2012 at 10:29 AM, Paolo Bonzini wrote:
>> Il 02/10/2012 09:28, Steven Bosscher ha scritto:
My experience shows that these lists are usually 1-2 elements. Although
in
> this case, there are pseudos with huge number e
On Tue, Oct 2, 2012 at 10:29 AM, Paolo Bonzini wrote:
> Il 02/10/2012 09:28, Steven Bosscher ha scritto:
>>> My experience shows that these lists are usually 1-2 elements. Although in
>>> > this case, there are pseudos with huge number elements (hundreeds). I
>>> > tried
>>> > -fweb for this t
Il 02/10/2012 09:28, Steven Bosscher ha scritto:
>> My experience shows that these lists are usually 1-2 elements. Although in
>> > this case, there are pseudos with huge number elements (hundreeds). I
>> > tried
>> > -fweb for this tests because it can decrease the number elements but GCC (I
>
On Tue, Oct 2, 2012 at 3:14 AM, Vladimir Makarov wrote:
> My experience shows that these lists are usually 1-2 elements. Although in
> this case, there are pseudos with huge number elements (hundreeds). I tried
> -fweb for this tests because it can decrease the number elements but GCC (I
> don'
On 10/01/2012 07:14 PM, Vladimir Makarov wrote:
Analogous live ranges are used in IRA as intermidiate step to build a
conflict graph. Actually, the first approach was to use IRA code to
assign hard registers to pseudos (e.g. Jeff Law tried this approach)
but it was rejected as requiring muc
On 10/01/2012 09:03 AM, Steven Bosscher wrote:
On Sat, Sep 29, 2012 at 10:26 PM, Steven Bosscher wrote:
LRA create live ranges : 175.30 (15%) usr 2.14 (13%) sys 177.44
(15%) wall2761 kB ( 0%) ggc
I've tried to split this up a bit more:
process_bb_lives ~50%
create_start_finish_chains
On 12-10-01 4:24 PM, Steven Bosscher wrote:
On Mon, Oct 1, 2012 at 9:51 PM, Vladimir Makarov wrote:
I think it's more important in this case to recognize Steven's real
point, which is that for an identical situation (IRA), and with an
identical patch author, we had similar bugs. They were prom
On Mon, Oct 1, 2012 at 9:51 PM, Vladimir Makarov wrote:
>> I think it's more important in this case to recognize Steven's real
>> point, which is that for an identical situation (IRA), and with an
>> identical patch author, we had similar bugs. They were promised to be
>> worked on, and yet some
On Mon, Oct 1, 2012 at 9:19 PM, David Miller wrote:
> From: Ian Lance Taylor
> Date: Mon, 1 Oct 2012 11:55:56 -0700
>
>> Steven is correct in saying that there is a tendency to move on and
>> never address GCC bugs. However, there is also a counter-vailing
>> tendency to fix GCC bugs. Anyhow I'
On 10/01/2012 03:19 PM, David Miller wrote:
From: Ian Lance Taylor
Date: Mon, 1 Oct 2012 11:55:56 -0700
Steven is correct in saying that there is a tendency to move on and
never address GCC bugs. However, there is also a counter-vailing
tendency to fix GCC bugs. Anyhow I'm certainly not sayi
From: Ian Lance Taylor
Date: Mon, 1 Oct 2012 11:55:56 -0700
> Steven is correct in saying that there is a tendency to move on and
> never address GCC bugs. However, there is also a counter-vailing
> tendency to fix GCC bugs. Anyhow I'm certainly not saying that in all
> cases it's OK to accept
On Mon, Oct 1, 2012 at 10:51 AM, Vladimir Makarov wrote:
>
> When I proposed merge LRA to gcc4.8, I had in mind that:
> o moving most changes from LRA branch will help LRA maintenance on the
> branch and I'll have more time to work on other targets and problems.
> o the earlier we start the tr
On 12-10-01 6:30 AM, Bernd Schmidt wrote:
On 10/01/2012 12:14 PM, Jakub Jelinek wrote:
On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
I would also agree if it were not for the fact that IRA is already a
scalability bottle-neck and that has been known for a long time, too.
I ha
On Sat, Sep 29, 2012 at 10:26 PM, Steven Bosscher wrote:
> LRA create live ranges : 175.30 (15%) usr 2.14 (13%) sys 177.44
> (15%) wall2761 kB ( 0%) ggc
I've tried to split this up a bit more:
process_bb_lives ~50%
create_start_finish_chains ~25%
remove_some_program_points_and_update_liv
On Mon, Oct 1, 2012 at 12:10 PM, Steven Bosscher wrote:
> The " LRA create live range" time is mostly spent in merge_live_ranges
> walking lists.
Hmm no, that's just gcc17's ancient debugger telling me lies.
lra_live_range_in_p is not even used.
/me upgrades to something newer than gdb 6.8...
C
On 10/01/2012 12:14 PM, Jakub Jelinek wrote:
> On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
>> I would also agree if it were not for the fact that IRA is already a
>> scalability bottle-neck and that has been known for a long time, too.
>> I have no confidence at all that if LRA
On Mon, Oct 1, 2012 at 12:14 PM, Jakub Jelinek wrote:
> On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
>> I would also agree if it were not for the fact that IRA is already a
>> scalability bottle-neck and that has been known for a long time, too.
>> I have no confidence at all t
On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
> I would also agree if it were not for the fact that IRA is already a
> scalability bottle-neck and that has been known for a long time, too.
> I have no confidence at all that if LRA goes in now, these scalability
> problems will be
On Sun, Sep 30, 2012 at 7:03 PM, Richard Guenther
wrote:
> On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher
> wrote:
>> Hi,
>>
>>
>> To look at it in yet another way:
>>
>>> integrated RA : 189.34 (16%) usr
>>> LRA non-specific: 59.82 ( 5%) usr
>>> LRA virtuals eliminatenon
On Mon, Oct 1, 2012 at 11:52 AM, Richard Guenther
wrote:
>> I think this testcase shouldn't be a show stopper for LRA inclusion into
>> 4.8, but something to look at for stage3.
>
> I agree here.
I would also agree if it were not for the fact that IRA is already a
scalability bottle-neck and that
On Mon, Oct 1, 2012 at 9:16 AM, Jakub Jelinek wrote:
> On Mon, Oct 01, 2012 at 08:47:13AM +0200, Steven Bosscher wrote:
>> The test case compiles just fine at -O2, only VRP has trouble with it.
>> Let's try to stick with facts, not speculation.
>
> I was talking about the other PR, PR26854, which
On Mon, Oct 1, 2012 at 7:48 AM, Jakub Jelinek wrote:
> On Sun, Sep 30, 2012 at 06:50:50PM -0400, Vladimir Makarov wrote:
>> But I think that LRA cpu time problem for this test can be fixed.
>> But I don't think I can fix it for 2 weeks. So if people believe
>> that current LRA behaviour on this
[ Sorry for re-send, it seems that mobile gmail sends text/html and
the sourceware mailer daemon rejects that. ]
On Monday, October 1, 2012, Jakub Jelinek wrote:
> On Sun, Sep 30, 2012 at 06:50:50PM -0400, Vladimir Makarov wrote:
>
> I think this testcase shouldn't be a show stopper for LRA inclu
On Mon, Oct 01, 2012 at 08:47:13AM +0200, Steven Bosscher wrote:
> The test case compiles just fine at -O2, only VRP has trouble with it.
> Let's try to stick with facts, not speculation.
I was talking about the other PR, PR26854, which from what I remember when
trying it myself and even the lates
On Sun, Sep 30, 2012 at 06:50:50PM -0400, Vladimir Makarov wrote:
> But I think that LRA cpu time problem for this test can be fixed.
> But I don't think I can fix it for 2 weeks. So if people believe
> that current LRA behaviour on this PR is a stopper to include it
> into gcc4.8 than we should
On 12-09-28 1:48 PM, Andi Kleen wrote:
Steven Bosscher writes:
On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote:
Any comments and proposals are appreciated. Even if GCC community
decides that it is too late to submit it to gcc4.8, the earlier reviews
are always useful.
I would l
On 12-09-30 7:15 PM, Steven Bosscher wrote:
On Mon, Oct 1, 2012 at 12:50 AM, Vladimir Makarov wrote:
As I wrote, I don't see that LRA has a problem right now because even on
8GB machine, GCC with LRA is 10% faster than GCC with reload with real time
point of view (not saying that LRA generat
On Mon, Oct 1, 2012 at 12:50 AM, Vladimir Makarov wrote:
> As I wrote, I don't see that LRA has a problem right now because even on
> 8GB machine, GCC with LRA is 10% faster than GCC with reload with real time
> point of view (not saying that LRA generates 15% smaller code). And real
> time is
On Mon, Oct 1, 2012 at 12:44 AM, Vladimir Makarov wrote:
> Actually, I don't see there is a problem with LRA right now. I think we
> should first to solve a whole compiler memory footprint problem for this
> test because cpu utilization is very small for this test. On my machine
> with 8GB, th
On 12-09-30 4:42 PM, Steven Bosscher wrote:
On Sun, Sep 30, 2012 at 7:03 PM, Richard Guenther
wrote:
On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher wrote:
Hi,
To look at it in yet another way:
integrated RA : 189.34 (16%) usr
LRA non-specific: 59.82 ( 5%) usr
LR
On 12-09-30 1:03 PM, Richard Guenther wrote:
On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher wrote:
Hi,
To look at it in yet another way:
integrated RA : 189.34 (16%) usr
LRA non-specific: 59.82 ( 5%) usr
LRA virtuals eliminatenon: 56.79 ( 5%) usr
LRA create liv
On Sun, Sep 30, 2012 at 7:03 PM, Richard Guenther
wrote:
> On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher
> wrote:
>> Hi,
>>
>>
>> To look at it in yet another way:
>>
>>> integrated RA : 189.34 (16%) usr
>>> LRA non-specific: 59.82 ( 5%) usr
>>> LRA virtuals eliminatenon
On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher wrote:
> Hi,
>
>
> To look at it in yet another way:
>
>> integrated RA : 189.34 (16%) usr
>> LRA non-specific: 59.82 ( 5%) usr
>> LRA virtuals eliminatenon: 56.79 ( 5%) usr
>> LRA create live ranges : 175.30 (15%) usr
>> L
Hi,
To look at it in yet another way:
> integrated RA : 189.34 (16%) usr
> LRA non-specific: 59.82 ( 5%) usr
> LRA virtuals eliminatenon: 56.79 ( 5%) usr
> LRA create live ranges : 175.30 (15%) usr
> LRA hard reg assignment : 130.85 (11%) usr
The IRA pass is slower tha
Richard Guenther writes:
>
> 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.
On Linux I would normally recommend to use
/usr/bin/time -f 'real=%e user=%U system=%S sh
On Sun, Sep 30, 2012 at 6:01 PM, Richard Guenther
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
>
On Sat, Sep 29, 2012 at 10:26 PM, Steven Bosscher wrote:
> Hi Vlad,
>
> Thanks for the testing and the logs. You must have good hardware, your
> timings are all ~3 times faster than mine :-)
>
> On Sat, Sep 29, 2012 at 3:01 AM, Vladimir Makarov wrote:
>> --32-bit--
Hi Vlad,
Thanks for the testing and the logs. You must have good hardware, your
timings are all ~3 times faster than mine :-)
On Sat, Sep 29, 2012 at 3:01 AM, Vladimir Makarov wrote:
> --32-bit
> Reload:
> 581.85user 29.91system
On 2012.09.28 at 11:21 -0400, Vladimir Makarov wrote:
> On 12-09-28 4:21 AM, Steven Bosscher wrote:
> > On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov
> > wrote:
> >>Any comments and proposals are appreciated. Even if GCC community
> >> decides that it is too late to submit it to gcc4.8,
On Fri, Sep 28, 2012 at 5:21 PM, Vladimir Makarov wrote:
> On 12-09-28 4:21 AM, Steven Bosscher wrote:
>>
>> On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov
>> wrote:
>>>
>>>Any comments and proposals are appreciated. Even if GCC community
>>> decides that it is too late to submit it to g
Steven Bosscher writes:
> On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov
> wrote:
>> Any comments and proposals are appreciated. Even if GCC community
>> decides that it is too late to submit it to gcc4.8, the earlier reviews
>> are always useful.
>
> I would like to see some benchmark n
On 12-09-28 4:21 AM, Steven Bosscher wrote:
On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote:
Any comments and proposals are appreciated. Even if GCC community
decides that it is too late to submit it to gcc4.8, the earlier reviews
are always useful.
I would like to see some benchm
On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote:
> Any comments and proposals are appreciated. Even if GCC community
> decides that it is too late to submit it to gcc4.8, the earlier reviews
> are always useful.
I would like to see some benchmark numbers, both for code quality and
com
On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote:
> Originally I was to submit LRA at the very beginning of stage1 for
> gcc4.9 as it was discussed on this summer GNU Tools Cauldron. After
> some thinking, I've decided to submit LRA now but only switched on for
> *x86/x86-64* target. T
Originally I was to submit LRA at the very beginning of stage1 for
gcc4.9 as it was discussed on this summer GNU Tools Cauldron. After
some thinking, I've decided to submit LRA now but only switched on for
*x86/x86-64* target. The reasons for that are
o I am already pretty confident in LRA f
52 matches
Mail list logo
