Denis Chertykov wrote:
> 2011/7/8 Georg-Johann Lay :
>> CCed Eric and Bernd.
>>
>> Denis Chertykov wrote:
Did you decide about the fix for PR46779?
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00810.html
Is it ok to commit?
>>> I forgot about testsuite regressions for this
2011/7/8 Georg-Johann Lay :
> CCed Eric and Bernd.
>
> Denis Chertykov wrote:
>>> Did you decide about the fix for PR46779?
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00810.html
>>>
>>> Is it ok to commit?
>>
>> I forgot about testsuite regressions for this patch.
>>
>> Denis.
>
>
> There
CCed Eric and Bernd.
Denis Chertykov wrote:
>> Did you decide about the fix for PR46779?
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00810.html
>>
>> Is it ok to commit?
>
> I forgot about testsuite regressions for this patch.
>
> Denis.
There were no new regressions:
http://gcc.gnu.o
2011/7/7 Georg-Johann Lay :
> Denis Chertykov wrote:
>> 2011/6/27 Georg-Johann Lay:
>>> Denis Chertykov wrote:
>
The main problem for me is that the new addressing mode produce a
worse code in many tests.
>>> You have an example source?
>>
>> In attachment.
>>
>> Denis.
>
> Hi Denis.
>
>
Denis Chertykov wrote:
> 2011/6/27 Georg-Johann Lay:
>> Denis Chertykov wrote:
>>> The main problem for me is that the new addressing mode produce a
>>> worse code in many tests.
>> You have an example source?
>
> In attachment.
>
> Denis.
Hi Denis.
I had a look at the sources you sent.
sort.
2011/6/27 Georg-Johann Lay :
> Denis Chertykov wrote:
>> 2011/6/26 Georg-Johann Lay :
>>> Denis Chertykov schrieb:
2011/6/24 Richard Henderson :
> On 06/23/2011 01:15 PM, Denis Chertykov wrote:
>
>>> text data bss dec hex filename
>>> 10032 25 0
Denis Chertykov wrote:
> 2011/6/26 Georg-Johann Lay :
>> Denis Chertykov schrieb:
>>> 2011/6/24 Richard Henderson :
>>>
On 06/23/2011 01:15 PM, Denis Chertykov wrote:
>> textdata bss dec hex filename
>> 10032 25 0 100572749 bld-avr-orig/gcc/z.o
>>
2011/6/26 Georg-Johann Lay :
> Denis Chertykov schrieb:
>>
>> 2011/6/24 Richard Henderson :
>>
>>> On 06/23/2011 01:15 PM, Denis Chertykov wrote:
>>>
> text data bss dec hex filename
> 10032 25 0 10057 2749 bld-avr-orig/gcc/z.o
> 5816 25 0
Denis Chertykov schrieb:
2011/6/24 Richard Henderson :
On 06/23/2011 01:15 PM, Denis Chertykov wrote:
textdata bss dec hex filename
10032 25 0 100572749 bld-avr-orig/gcc/z.o
5816 25 0584116d1 bld-avr-new/gcc/z.o
Richard, can you send me
2011/6/24 Richard Henderson :
> On 06/23/2011 01:15 PM, Denis Chertykov wrote:
>>> text data bss dec hex filename
>>> 10032 25 0 10057 2749 bld-avr-orig/gcc/z.o
>>> 5816 25 0 5841 16d1 bld-avr-new/gcc/z.o
>>
>> Richard, can you send me this z.c f
On 06/23/2011 01:15 PM, Denis Chertykov wrote:
>> textdata bss dec hex filename
>> 10032 25 0 100572749 bld-avr-orig/gcc/z.o
>> 5816 25 0584116d1 bld-avr-new/gcc/z.o
>
> Richard, can you send me this z.c file ?
> Right now I'm notice that ne
2011/6/16 Richard Henderson :
> On 06/15/2011 02:58 PM, Richard Henderson wrote:
>> Indeed, I can work around this particular crash by either
>> hacking Z to be call-saved, or hacking the frame pointer to
>> not be required. The former of course changes the abi, and
>> the second produces awful co
Sorry for the earlier semi-empty mail (just quoting G-J), I
meant to cancel it. Happy midsummer.
brgds, H-P
On Wed, 22 Jun 2011, Georg-Johann Lay wrote:
> Hans-Peter Nilsson schrieb:
> > On Mon, 13 Jun 2011, Georg-Johann Lay wrote:
> >> [In CCing Richard Henderson]
> >> Denis Chertykov schrieb:
> >>> 2011/6/10 Georg-Johann Lay :
> >
> Then I observed trouble with DI patterns during libgcc build a
Hans-Peter Nilsson schrieb:
> On Mon, 13 Jun 2011, Georg-Johann Lay wrote:
>> [In CCing Richard Henderson]
>> Denis Chertykov schrieb:
>>> 2011/6/10 Georg-Johann Lay :
>
Then I observed trouble with DI patterns during libgcc build and had
to remove
* "zero_extendqidi2"
* "
On Mon, 13 Jun 2011, Georg-Johann Lay wrote:
> [In CCing Richard Henderson]
> Denis Chertykov schrieb:
> > 2011/6/10 Georg-Johann Lay :
> > > Then I observed trouble with DI patterns during libgcc build and had
> > > to remove
> > >
> > > * "zero_extendqidi2"
> > > * "zero_extendhidi2"
> > > * "ze
Do you think we can split the patch intended to fix PR46779
> PR target/46779
> * config/avr/avr.c (avr_hard_regno_mode_ok): Rewrite.
> In particular, allow 8-bit values in r28 and r29.
> (avr_hard_regno_scratch_ok): Disallow any register that might be
> part of the f
2011/6/16 Richard Henderson :
> On 06/16/2011 12:17 PM, Denis Chertykov wrote:
>> Are you working in public git repository ?
>> Can I chekout it ?
>>
>> If not then may be you can drop a full patch against svn.
>
> I've pushed it to
>
> git://gcc.gnu.org/git/gcc.git rth/avr-addressing
Thank you.
On 06/16/2011 12:17 PM, Denis Chertykov wrote:
> Are you working in public git repository ?
> Can I chekout it ?
>
> If not then may be you can drop a full patch against svn.
I've pushed it to
git://gcc.gnu.org/git/gcc.git rth/avr-addressing
As I said yesterday, there's still a crash in libg
2011/6/16 Richard Henderson :
> On 06/16/2011 11:09 AM, Denis Chertykov wrote:
>> Only one question why you removed avr_legitimize_address ?
>
> It doesn't actually do anything useful.
>
> All it does is, for a subset of inputs, force the address into
> a register. This is the same as the fallback
On 06/16/2011 11:09 AM, Denis Chertykov wrote:
> Only one question why you removed avr_legitimize_address ?
It doesn't actually do anything useful.
All it does is, for a subset of inputs, force the address into
a register. This is the same as the fallback action. That is,
any non-legitimate add
2011/6/16 Richard Henderson :
> On 06/16/2011 04:34 AM, Denis Chertykov wrote:
>> @rth (while you are diving into AVR microworld ;-)
>> May be you can give a suggestion to change the AVR abi.
>> I have tuned the abi for code size almost 13 years ago.
>> The register pressure to r18-r31 are very hig
2011/6/16 Richard Henderson :
> On 06/16/2011 04:46 AM, Denis Chertykov wrote:
>> I forgot to said that suggestion from Bernd Schmidt about
>> HARD_FRAME_POINTER_REGNUM seems very useful:
>>> Maybe it would help for your port to define a separate
>>> FRAME_POINTER_REGNUM, able to hold an HImode val
On 06/16/2011 07:35 AM, Bernd Schmidt wrote:
> Did you have a chance to look at the ia64 unwind code? I probably won't
> be able to get back to it for a while yet since I'm working on C6X tuning...
I was looking at it before I moved house a month ago, and then
totally forgot about it until today.
On 06/16/2011 04:25 PM, Richard Henderson wrote:
> That last point probably depends on Bernd Schmidt's work in
> dwarf2out for shrink-wrapping...
Did you have a chance to look at the ia64 unwind code? I probably won't
be able to get back to it for a while yet since I'm working on C6X tuning...
B
On 06/16/2011 04:34 AM, Denis Chertykov wrote:
> @rth (while you are diving into AVR microworld ;-)
> May be you can give a suggestion to change the AVR abi.
> I have tuned the abi for code size almost 13 years ago.
> The register pressure to r18-r31 are very high.
As far as I can see, the ABI is
On 06/16/2011 04:46 AM, Denis Chertykov wrote:
> I forgot to said that suggestion from Bernd Schmidt about
> HARD_FRAME_POINTER_REGNUM seems very useful:
>> Maybe it would help for your port to define a separate
>> FRAME_POINTER_REGNUM, able to hold an HImode value, which then gets
>> eliminated to
2011/6/16 Denis Chertykov :
> 2011/6/16 Richard Henderson :
>> On 06/15/2011 02:58 PM, Richard Henderson wrote:
>>> Indeed, I can work around this particular crash by either
>>> hacking Z to be call-saved, or hacking the frame pointer to
>>> not be required. The former of course changes the abi, a
2011/6/16 Richard Henderson :
> On 06/15/2011 02:58 PM, Richard Henderson wrote:
>> Indeed, I can work around this particular crash by either
>> hacking Z to be call-saved, or hacking the frame pointer to
>> not be required. The former of course changes the abi, and
>> the second produces awful co
On 06/15/2011 02:58 PM, Richard Henderson wrote:
> Indeed, I can work around this particular crash by either
> hacking Z to be call-saved, or hacking the frame pointer to
> not be required. The former of course changes the abi, and
> the second produces awful code due to too many copies from
> the
On 06/15/2011 01:40 PM, Georg-Johann Lay wrote:
> But I still wonder what's the very problem. Any architecture has
> limited reg+const addressing and limited number of address
> registers. I definetely saw architectures run out of registers and
> reload manages to access stack beyond reg+maxoff wit
Richard Henderson schrieb:
On 06/14/2011 02:29 PM, Georg-Johann Lay wrote:
I tested on some handcrafted examples and on the code attached to
PR46278. The generated code looked very good and so I started
regression testing but found at spill fail in
gcc.c-torture/compile/950612-1.c
I reproduc
On 06/14/2011 02:29 PM, Georg-Johann Lay wrote:
> I tested on some handcrafted examples and on the code attached to
> PR46278. The generated code looked very good and so I started
> regression testing but found at spill fail in
> gcc.c-torture/compile/950612-1.c
I reproduced this today.
The Pro
On 06/14/2011 02:29 PM, Georg-Johann Lay wrote:
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01029.html
It does look like a step in the right direction.
> I tested on some handcrafted examples and on the code attached to
> PR46278. The generated code looked very good and so I started
> regressi
Denis Chertykov schrieb:
2011/6/14 Georg-Johann Lay :
Denis Chertykov schrieb:
2011/6/13 Georg-Johann Lay :
So you think is is pointless/discouraged to give a more realistic
description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead
of BASE_REG_CLASS) resp. REGNO_MODE_CODE_
2011/6/14 Georg-Johann Lay :
> Denis Chertykov schrieb:
>> 2011/6/13 Georg-Johann Lay :
>>> So you think is is pointless/discouraged to give a more realistic
>>> description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead
>>> of BASE_REG_CLASS) resp. REGNO_MODE_CODE_OK_FOR_BASE_P?
>
Denis Chertykov schrieb:
> 2011/6/13 Georg-Johann Lay :
>> So you think is is pointless/discouraged to give a more realistic
>> description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead
>> of BASE_REG_CLASS) resp. REGNO_MODE_CODE_OK_FOR_BASE_P?
>>
>>> Look carefully at `out_movqi_
2011/6/13 Georg-Johann Lay :
>
> So you think is is pointless/discouraged to give a more realistic
> description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead
> of BASE_REG_CLASS) resp. REGNO_MODE_CODE_OK_FOR_BASE_P?
>
>> Look carefully at `out_movqi_r_mr'.
>> There are even two f
[In CCing Richard Henderson]
Denis Chertykov schrieb:
2011/6/10 Georg-Johann Lay :
Then I have a question on spill failures:
There is PR46278, an optimization flaw that goes as follows:
The avr BE defines fake addressing mode X+const that has to be written
down in asm as
X += const
a = *X
X
2011/6/10 Georg-Johann Lay :
> Then I have a question on spill failures:
>
> There is PR46278, an optimization flaw that goes as follows:
>
> The avr BE defines fake addressing mode X+const that has to be written
> down in asm as
> X += const
> a = *X
> X -= const
>
> The comment says that this
Denis Chertykov schrieb:
> 2011/6/9 Georg-Johann Lay :
>> Denis Chertykov schrieb:
>>> 2011/6/9 Georg-Johann Lay :
>> I agree with you. However, I think that the risk of spill failure
>> should be minimized. I have no idea how to fix a splill failure like
>> the following that occurs in testsuite (
Denis Chertykov schrieb:
> 2011/6/9 Georg-Johann Lay :
>> This is a tentative patch to fix PR46779 and hopefully also related
>> issues like PR45291.
>>
> - /* Disallow QImode in stack pointer regs. */
> - if ((regno == REG_SP || regno == (REG_SP + 1)) && mode == QImode)
> + /* Don't allocate d
Georg-Johann Lay schrieb:
Denis Chertykov schrieb:
2011/6/9 Georg-Johann Lay :
This is a tentative patch to fix PR46779 and hopefully also related
issues like PR45291.
- /* Disallow QImode in stack pointer regs. */
- if ((regno == REG_SP || regno == (REG_SP + 1)) && mode == QImode)
+ /
2011/6/9 Georg-Johann Lay :
> Denis Chertykov schrieb:
>> 2011/6/9 Georg-Johann Lay :
>>> This is a tentative patch to fix PR46779 and hopefully also related
>>> issues like PR45291.
>>>
>> - /* Disallow QImode in stack pointer regs. */
>> - if ((regno == REG_SP || regno == (REG_SP + 1)) && mode
Denis Chertykov schrieb:
> 2011/6/9 Georg-Johann Lay :
>> This is a tentative patch to fix PR46779 and hopefully also related
>> issues like PR45291.
>>
> - /* Disallow QImode in stack pointer regs. */
> - if ((regno == REG_SP || regno == (REG_SP + 1)) && mode == QImode)
> + /* Don't allocate d
2011/6/9 Georg-Johann Lay :
> This is a tentative patch to fix PR46779 and hopefully also related
> issues like PR45291.
>
- /* Disallow QImode in stack pointer regs. */
- if ((regno == REG_SP || regno == (REG_SP + 1)) && mode == QImode)
+ /* Don't allocate data to non-GENERAL_REGS registers.
This is a tentative patch to fix PR46779 and hopefully also related
issues like PR45291.
In the present version of avr_hard_regno_mode_ok, QImode is forbidden
in r29/r28. If a 16-bit value or composite is allocated to r28, this
can lead to odd subregs like
(set (subreg:QI (reg:HI r28) 0) ...)
Th
47 matches
Mail list logo
