> -Original Message-
> From: Mark Mitchell [mailto:m...@codesourcery.com]
> Sent: Monday, December 29, 2008 11:51 AM
> To: Andrew Haley
> Cc: Eric Botcazou; gcc@gcc.gnu.org; Georg-Johann Lay
> Subject: Re: Odd performance regression with -Os
>
> Andrew Haley
Andrew Haley wrote:
> Eric Botcazou wrote:
>>> Thanks. Are you holding this because we're in Stage 3?
>> The patch was written very recently so I wanted to let it go through a good
>> deal of internal testing. Moveover I haven't measured its impact on
>> anything
>> else than Ada benchmarks (a
On Tue, Dec 23, 2008 at 11:28 AM, Andrew Haley wrote:
> Eric Botcazou wrote:
>>> Thanks. Are you holding this because we're in Stage 3?
>>
>> The patch was written very recently so I wanted to let it go through a good
>> deal of internal testing. Moveover I haven't measured its impact on anythin
Eric Botcazou wrote:
>> Thanks. Are you holding this because we're in Stage 3?
>
> The patch was written very recently so I wanted to let it go through a good
> deal of internal testing. Moveover I haven't measured its impact on anything
> else than Ada benchmarks (and on a patched 4.3 branch)
> Thanks. Are you holding this because we're in Stage 3?
The patch was written very recently so I wanted to let it go through a good
deal of internal testing. Moveover I haven't measured its impact on anything
else than Ada benchmarks (and on a patched 4.3 branch). If people think that
it wou
> The problem here seems to be that the FE (or the GIMPLE generation)
> transforms
>
> addr + ((on_off-1)*2)
>
> into
>
> addr + ((1-on_off)*-2)
>
> and nothing in -Os has the wit to recover. This badly affects targets
> with no hardware multiplier, which end up calling libgcc to d
Here's a strange case of poor code generation with -Os.
unsigned short foo2 (unsigned char on_off, unsigned short *puls)
{
return puls[on_off-1];
}
With -O2, it's fine:
movzbl %dil, %edi
movzwl -2(%rsi,%rdi,2), %eax
ret
With -Os it's really weird:
movzbl %d
