[EMAIL PROTECTED] wrote:
>> Plugins features. This addresses Richard Stallman's concerns, so he
>> no
>> longer objects to a Plugins feature.
>
> That is GREAT news!!!
I add my enthusiasm to the one of Brendon, this is really a great news !
Please, keep us informed of the progress of the plugins
> I got negative feedback on that patch (no, not regression
> results :) on IRC from David Edelsohn and understandably you
> held off your testing because of this, as for one the patch
> affects the rs6000 backend.
What kind of negative feedback?
> For CRIS (as well as other targets IIUC) the ca
> Date: Fri, 05 Sep 2008 12:55:17 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> > I got negative feedback on that patch (no, not regression
> > results :) on IRC from David Edelsohn and understandably you
> > held off your testing because of this, as for one the patch
> > affects the rs6000 ba
On Fri, Sep 5, 2008 at 7:25 AM, Hans-Peter Nilsson
<[EMAIL PROTECTED]> wrote:
>> Date: Fri, 05 Sep 2008 12:55:17 +0200
>> From: Paolo Bonzini <[EMAIL PROTECTED]>
> Nope, not if it's a (MINUS (symbol_ref sym2) (symbol_ref sym1)).
> *If* valid, that's a constant expression and *should* be wrapped
>
>> 3) adding a check that the MINUS is a legitimate address, and only wrap
>> it in CONST if it is.
>
> s/address/constant/; it's not clear that it's used as an address
> at that point; it's just two expressions that gcc tries to
> reduce.
Right.
> But I get the point; I'm leaning towards somet
> Date: Fri, 05 Sep 2008 14:42:11 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> We can do it incrementally. For now, only redefine
> LEGITIMATE_CONSTANT_P on CRIS and in the documentation, and use it in
> simplify_plus_minus. For 4.5, we can look at other places using
> gen_rtx_CONST and str
> Date: Fri, 5 Sep 2008 14:57:00 +0200
> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>
> Maybe as part of a change from target macro to target hook, with
> LEGITIMATE_CONSTANT_P as a default would fit, even at this
> stage?
Sorry, I mean CONSTANT_P, not LEGITIMATE_CONSTANT_P. Or maybe a
new macro
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%) and applu (~4%)
for 64-bit PPC.
There are other degradations that i'm still working on i
On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> Hi Vladimir,
>
> I was just going through some benchmarks on PPC and noticed that your
> patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
> caused a significant regression on both facerec (~17%) and appl
Adam Nemet wrote:
haifa-sched.c:
2302/* Let the target filter the search space. */
2303for (i = 1; i < ready->n_ready; i++)
2304 if (!ready_try[i])
2305{
2306 insn = ready_element (ready, i);
2307
2308 gcc_assert (INS
On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
> On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> > Hi Vladimir,
> >
> > I was just going through some benchmarks on PPC and noticed that your
> > patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
> > c
On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
> Daniel Berlin wrote:
>
>> It's listed on the wiki that explains how to maintain branches :)
>>
> I had no idea such a wiki even existed. It would really help future
> contributors, I'm sure, if, perhaps during copyright assignment
David Edelsohn wrote:
On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Meanwhile I am going to submit your second patch with an added
comment. The patch permits gcc to generate the same quality code as
before your first patch.
Why?
As Richard said before:
Luis Machado wrote:
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%) and applu (~4%)
for 64-bit PPC.
There are other degradations that
Hi.
My build attempts on sparc-sun-solaris2.10 haven't been working well
since the IRA merge, but given the scope of that change and the fixes
applied since the merge I'm certain the build will be in good shape
soon.
This morning's build attempt failed while compiling libgcc:
/export/home/arth/s
On Fri, 2008-09-05 at 09:03 -0700, H.J. Lu wrote:
> On Fri, Sep 5, 2008 at 8:01 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
> >> On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> >> > Hi Vladimir,
> >> >
> >> > I was jus
2008/9/5 Christopher Faylor <[EMAIL PROTECTED]>:
> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>> Daniel Berlin wrote:
>>
>>> It's listed on the wiki that explains how to maintain branches :)
>>>
>> I had no idea such a wiki even existed. It would really help future
>> contributo
On Fri, 2008-09-05 at 12:36 -0400, Vladimir Makarov wrote:
> Luis Machado wrote:
> > Hi Vladimir,
> >
> > I was just going through some benchmarks on PPC and noticed that your
> > patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
> > caused a significant regression on both face
On Fri, Sep 5, 2008 at 8:01 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
>> On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
>> > Hi Vladimir,
>> >
>> > I was just going through some benchmarks on PPC and noticed that your
>>
Luis Machado wrote:
This is a Power6 4.7Ghz (altivec supported)
Great. Now I have an access to power6. So I am going to try it too.
What options (especially march or mtune) you are using? IRA is very
sensitive to correct times of ld/st/moves in machine description.
I'm currentl
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
> H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
I won't apply any non-IRA related patches to ira-merge branch so
that you can get a fair comparison for IRA without regressions
introduced by
Art Haas <[EMAIL PROTECTED]> writes:
> My build attempts on sparc-sun-solaris2.10 haven't been working well
> since the IRA merge, but given the scope of that change and the fixes
> applied since the merge I'm certain the build will be in good shape
> soon.
>
> This morning's build attempt failed
Hi Doug, Jason suggested that I write to you about this. There seems
to be some confusion in the code in cp/pt.c between enum
unification_kind_t (DEDUCE_xxx) and a bitmask of UNIFY_ALLOW_xxx
values. The parameters are named "strict" for all functions, but in
some cases they are unification_kind_t
Christopher Faylor wrote:
On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
Daniel Berlin wrote:
It's listed on the wiki that explains how to maintain branches :)
I had no idea such a wiki even existed. It would really help future
contributors, I'm sure, if, per
Rainer Orth wrote:
Looks like a code generation bug to me. I'll try to start a reghunt asap.
Start around the 25/26th of August. IRA.
Since then it is borked.
Andreas
Maxim Kuvyrkov writes:
> Yes, the assert is really checking exactly that. Several pieces of
> haifa-sched.c assume that the instruction has been recognized during
> scheduler initialization to speed up checking if instruction is normal
> or some kind of use/clobber/asm.
Thanks for the info but
On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> Rainer Orth wrote:
>
>> Looks like a code generation bug to me. I'll try to start a reghunt asap.
>
> Start around the 25/26th of August. IRA.
>
> Since then it is borked.
>
Can you try ira-merge branch? It has all IRA b
I'll commit your patch.
On Fri, Sep 5, 2008 at 12:42 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/9/5 Christopher Faylor <[EMAIL PROTECTED]>:
>> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>>> Daniel Berlin wrote:
>>>
It's listed on the wiki that explains how to
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
Rainer Orth wrote:
Looks like a code generation bug to me. I'll try to start a reghunt asap.
Start around the 25/26th of August. IRA.
Since then it is borked.
Can you try ira-merge branch? It has al
On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
>>
>> On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Rainer Orth wrote:
>>>
Looks like a code generation bug to me. I'll try to start a reghunt
asap.
>>>
>>>
H.J. Lu wrote:
Can you try ira-merge branch? It has all IRA bug fixes without non-IRA
changes.
How is it named? ira-merge? If, I can't find it on
http://gcc.gnu.org/svn.html.
It is a temporary branch, branches/ira-merge, to track
IRA related problems.
Thanks, co right now.
Andreas
Adam Nemet wrote:
Maxim Kuvyrkov writes:
Yes, the assert is really checking exactly that. Several pieces of
haifa-sched.c assume that the instruction has been recognized during
scheduler initialization to speed up checking if instruction is normal
or some kind of use/clobber/asm.
Thanks for
Maxim Kuvyrkov writes:
> I'm not 100% sure about current state of things, considering recent
> merge of sel-sched, but before that it was:
>
> set_priorities() -> priority() -> dep_cost() -> recog_memoized().
I don't think that was the case for all insns even before the patch. The only
new thin
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler <[EMAIL PROTECTED]>
wrote:
Rainer Orth wrote:
Looks like a code generation bug to me. I'll try to start a reghunt
asap.
Start around the
On Fri, Sep 5, 2008 at 2:43 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
>>
>> On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler
<[EMAIL PROTECTED]>
wrote:
>
H.J. Lu wrote:
It is a temporary branch, branches/ira-merge, to track
IRA related problems.
Same issue.
Does trunk bootstrap with revision 139589?
No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042] (GCC)
Andreas
On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
>
>>>> It is a temporary branch, branches/ira-merge, to track
>>>> IRA related problems.
>>>>
>>> Same issue.
>>
>> Does trunk b
Snapshot gcc-4.4-20080905 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080905/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, Sep 05, 2008 at 01:34:08PM -0500, John Freeman wrote:
> Christopher Faylor wrote:
>> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>>
>>> Daniel Berlin wrote:
>>>
>>>
It's listed on the wiki that explains how to maintain branches :)
>>> I had no id
39 matches
Mail list logo
