Hans-Peter Nilsson schrieb:
Oleg Endo wrote:
Georg-Johann Lay wrote:
The change is definitely in the right direction, but I wonder
how it helps to fix code bloats of 300%-400% as in PR52543?
I'm not familiar with the AVR parts.
BTW, There was a small change in lower-subreg which required some
Oleg Endo wrote:
> On Thu, 2012-09-06 at 14:41 +0200, Georg-Johann Lay wrote:
> > The change is definitely in the right direction, but I wonder
> > how it helps to fix code bloats of 300%-400% as in PR52543?
>
> I'm not familiar with the AVR parts.
> BTW, There was a small change in lower-subreg wh
On Thu, 2012-09-06 at 14:41 +0200, Georg-Johann Lay wrote:
> Oleg Endo schrieb:
> > On Wed, 2012-09-05 at 14:39 -0400, DJ Delorie wrote:
> >> I don't feel the m32c change needs my specific ack, it's a harmless
> >> change that goes with the ack for the feature itself.
> >>
> >> However, I will note
Oleg Endo schrieb:
On Wed, 2012-09-05 at 14:39 -0400, DJ Delorie wrote:
I don't feel the m32c change needs my specific ack, it's a harmless
change that goes with the ack for the feature itself.
However, I will note that m32c does have different costs for addresses
in different address spaces, a
On 6 Sep 2012, at 11:18, domi...@lps.ens.fr (Dominique Dhumieres) wrote:
Could you please commit this (I can't at the moment)?
Sorry, I don't have write access.
OK, then I will commit it later today.
Cheers,
Oleg
> Could you please commit this (I can't at the moment)?
Sorry, I don't have write access.
Dominique
On Thu, 2012-09-06 at 09:49 +0200, Dominique Dhumieres wrote:
> Oleg,
>
> Bootstrap fails at revision 190996 on powerpc-apple-darwin9 with:
>
> g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
> -Wno-long
Oleg,
Bootstrap fails at revision 190996 on powerpc-apple-darwin9 with:
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFI
On Wed, 2012-09-05 at 14:39 -0400, DJ Delorie wrote:
> I don't feel the m32c change needs my specific ack, it's a harmless
> change that goes with the ack for the feature itself.
>
> However, I will note that m32c does have different costs for addresses
> in different address spaces, at least when
I don't feel the m32c change needs my specific ack, it's a harmless
change that goes with the ack for the feature itself.
However, I will note that m32c does have different costs for addresses
in different address spaces, at least when -Os.
On Wed, 2012-09-05 at 13:44 +0400, Denis Chertykov wrote:
> 2012/9/5 Oleg Endo :
> > Updated ACK table:
> >
> > [x] target-independent bits
> > [ ] alpha [x] arm [ ] avr [ ] bfin
> > [ ] cr16 [x] cris [x] epiphany[ ] i386
> > [ ] ia64 [x] iq2000[ ] lm32
2012/9/5 Oleg Endo :
> Updated ACK table:
>
> [x] target-independent bits
> [ ] alpha [x] arm [ ] avr [ ] bfin
> [ ] cr16 [x] cris [x] epiphany[ ] i386
> [ ] ia64 [x] iq2000[ ] lm32[ ] m32c
> [x] m32r [x] mcore [ ] mep [x] microblaze
On 05/09/12 09:16, Oleg Endo wrote:
> Updated ACK table:
>
> [x] target-independent bits
> [ ] alpha [x] arm [ ] avr [ ] bfin
> [ ] cr16 [x] cris [x] epiphany[ ] i386
> [ ] ia64 [x] iq2000[ ] lm32[ ] m32c
> [x] m32r [x] mcore [ ] mep
On Wed, Sep 5, 2012 at 10:16 AM, Oleg Endo wrote:
> Updated ACK table:
>
> [x] target-independent bits
> [ ] alpha [x] arm [ ] avr [ ] bfin
> [ ] cr16 [x] cris [x] epiphany[ ] i386
> [ ] ia64 [x] iq2000[ ] lm32[ ] m32c
> [x] m32r [x] mcore
Updated ACK table:
[x] target-independent bits
[ ] alpha [x] arm [ ] avr [ ] bfin
[ ] cr16 [x] cris [x] epiphany[ ] i386
[ ] ia64 [x] iq2000[ ] lm32[ ] m32c
[x] m32r [x] mcore [ ] mep [x] microblaze
[x] mips [x] mmix [x] m
Joern Rennecke:
David Edelsohn:
Oleg Endo:
Hmm .. the ACK status so far is:
Not sure if we are supposed to acknowledge all the straigtforward argument
additions... at any rate, the epiphany hunk is OK.
I think I'll make use of the new functionality eventually, but prefer
to be able to test
On Tue, 4 Sep 2012, Oleg Endo wrote:
> On Mon, 2012-09-03 at 01:58 +0200, Oleg Endo wrote:
> > OKOK -- I'll do it :)
> > (within the next couple of days)
> >
>
> And so I did. Attached is an updated patch that adds the address space
> parameter to the address_cost function. I hope that this chan
Quoting David Edelsohn :
On Tue, Sep 4, 2012 at 2:57 PM, Oleg Endo wrote:
Hmm .. the ACK status so far is:
Not sure if we are supposed to acknowledge all the straigtforward argument
additions... at any rate, the epiphany hunk is OK.
I think I'll make use of the new functionality eventually
On Tue, Sep 4, 2012 at 2:57 PM, Oleg Endo wrote:
> Hmm .. the ACK status so far is:
>
> [x] target-independent bits
> [ ] alpha [x] arm [ ] avr [ ] bfin
> [ ] cr16 [ ] cris [ ] epiphany[ ] i386
> [ ] ia64 [x] iq2000[ ] lm32[ ] m32c
> [x] m32r
On Tue, 2012-09-04 at 12:02 -0300, Alexandre Oliva wrote:
> > Index: gcc/config/mn10300/mn10300.c
>
> > - total = mn10300_address_cost (XEXP (x, 0), speed);
> > + total = mn10300_address_cost (XEXP (x, 0), GET_MODE (x),
> > + ADDR_SPACE_GENERIC, speed);
>
Oleg Endo writes:
> On Mon, 2012-09-03 at 01:58 +0200, Oleg Endo wrote:
>> OKOK -- I'll do it :)
>> (within the next couple of days)
>>
>
> And so I did. Attached is an updated patch that adds the address space
> parameter to the address_cost function. I hope that this change does
> not reset t
On Sep 4, 2012, Oleg Endo wrote:
> * config/mn10300/mn10300.c (mn10300_address_cost): Add
> machine_mode and address space arguments. Use GET_MODE (x) and
> ADDR_SPACE_GENERIC in recursive invocation.
Ok with a change, see below.
> * config/sh/sh.c (sh_address_cost)
On Tue, Sep 4, 2012 at 12:38 PM, Paolo Bonzini wrote:
> Il 04/09/2012 09:52, Oleg Endo ha scritto:
>> [x] target-independent bits
>> [ ] alpha [ ] arm [ ] avr [ ] bfin
>> [ ] cr16 [ ] cris [ ] epiphany[ ] i386
>> [ ] ia64 [ ] iq2000[ ] lm32[ ] m32c
Il 04/09/2012 09:52, Oleg Endo ha scritto:
> [x] target-independent bits
> [ ] alpha [ ] arm [ ] avr [ ] bfin
> [ ] cr16 [ ] cris [ ] epiphany[ ] i386
> [ ] ia64 [ ] iq2000[ ] lm32[ ] m32c
> [ ] m32r [ ] mcore [ ] mep [x] microblaze
On 04/09/12 08:52, Oleg Endo wrote:
> On Mon, 2012-09-03 at 01:58 +0200, Oleg Endo wrote:
>> OKOK -- I'll do it :)
>> (within the next couple of days)
>>
>
> And so I did. Attached is an updated patch that adds the address space
> parameter to the address_cost function. I hope that this change d
Hi Oleg,
And so I did. Attached is an updated patch that adds the address space
parameter to the address_cost function. I hope that this change does
not reset the ACKs so far:
[x] target-independent bits
[ ] alpha [ ] arm [ ] avr [ ] bfin
[ ] cr16 [ ] cris [ ] epip
On Mon, 2012-09-03 at 01:58 +0200, Oleg Endo wrote:
> OKOK -- I'll do it :)
> (within the next couple of days)
>
And so I did. Attached is an updated patch that adds the address space
parameter to the address_cost function. I hope that this change does
not reset the ACKs so far:
[x] target-ind
On Sun, 2012-09-02 at 12:32 +0200, Georg-Johann Lay wrote:
> Richard Sandiford schrieb:
> > Oleg Endo writes:
> >> On Sat, 2012-09-01 at 10:10 +0100, Richard Sandiford wrote:
> >>
> >>> Thanks for doing this. We should perhaps add the address space too,
> >>> but if you don't feel like redoing th
Richard Sandiford schrieb:
Oleg Endo writes:
On Sat, 2012-09-01 at 10:10 +0100, Richard Sandiford wrote:
Thanks for doing this. We should perhaps add the address space too,
but if you don't feel like redoing the whole patch, that can wait until
someone wants it.
I just had a look at the add
Oleg Endo writes:
> On Sat, 2012-09-01 at 10:10 +0100, Richard Sandiford wrote:
>
>> Thanks for doing this. We should perhaps add the address space too,
>> but if you don't feel like redoing the whole patch, that can wait until
>> someone wants it.
>
> I just had a look at the address space thing
On Sat, 2012-09-01 at 10:10 +0100, Richard Sandiford wrote:
> Thanks for doing this. We should perhaps add the address space too,
> but if you don't feel like redoing the whole patch, that can wait until
> someone wants it.
I just had a look at the address space thing...
There are already target
Oleg Endo writes:
> While experimenting a little bit with an idea for an address mode
> selection RTL pass for SH, I realized that SH's sh_address_cost function
> is quite broken. When trying to fix it, I ran against a wall, since the
> mode of the MEM is not passed to the target hook function, a
On Aug 29, 2012, Oleg Endo wrote:
> * config/mn10300/mn10300.c (mn10300_address_cost): Add
> machine_mode argument. Use GET_MODE (x) in recursive
> invocation.
> * config/sh/sh.c (sh_address_cost): Likewise.
These are ok, thanks.
--
Alexandre Oliva, freedom fighter
On 08/29/2012 05:46 PM, Oleg Endo wrote:
Hello,
While experimenting a little bit with an idea for an address mode
selection RTL pass for SH, I realized that SH's sh_address_cost function
is quite broken. When trying to fix it, I ran against a wall, since the
mode of the MEM is not passed to the
Hello,
While experimenting a little bit with an idea for an address mode
selection RTL pass for SH, I realized that SH's sh_address_cost function
is quite broken. When trying to fix it, I ran against a wall, since the
mode of the MEM is not passed to the target hook function, as it is e.g.
in leg
35 matches
Mail list logo
