2011/7/28 Georg-Johann Lay :
> Richard Henderson wrote:
>> On 07/27/2011 06:21 AM, Georg-Johann Lay wrote:
>>> +(define_insn_and_split "*mulsi3"
>>> + [(set (match_operand:SI 0 "pseudo_register_operand"
>>> "=r")
>>> + (mult:SI (match_operand:SI 1 "pseudo_register_oper
Richard Henderson wrote:
> On 07/27/2011 06:21 AM, Georg-Johann Lay wrote:
>> +(define_insn_and_split "*mulsi3"
>> + [(set (match_operand:SI 0 "pseudo_register_operand"
>> "=r")
>> +(mult:SI (match_operand:SI 1 "pseudo_register_operand"
>> "r")
>> +
On 07/28/2011 07:59 AM, Georg-Johann Lay wrote:
> So it appears that IRA is not as smart as we thought and not
> prepared for this...
>
> Or did I do something fundamentally wrong?
It sure doesn't look like you've done anything wrong.
r~
Weddington, Eric wrote:
>> Subject: Re: [Patch,AVR]: PR49687 (better widening 32-bit mul)
>>
>>> I didn't review the asm code, but the rest of the patch look ok to me.
>>>
>>> r~
>> Thanks, Eric will review the asm part :-)
>
> LOL
>
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Wednesday, July 27, 2011 3:00 PM
> To: Richard Henderson
> Cc: Weddington, Eric; gcc-patches@gcc.gnu.org; Anatoly Sokolov; Denis
> Chertykov
> Subject: Re: [Patch,AVR]: PR49687 (bette
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02391.html
Richard Henderson schrieb:
On 07/27/2011 08:57 AM, Georg-Johann Lay wrote:
You'll probably end up with quite a few register classes
out of this, but hopefully reload can do a better job than
you can manually...
Agreed.
insns that wil
On 07/27/2011 08:57 AM, Georg-Johann Lay wrote:
>> > You'll probably end up with quite a few register classes
>> > out of this, but hopefully reload can do a better job than
>> > you can manually...
> Agreed.
>
> insns that will benefit are insns with two input operands that
> commute, i.e. mulsi
Richard Henderson wrote:
> On 07/27/2011 06:21 AM, Georg-Johann Lay wrote:
>> +(define_insn_and_split "*mulsi3"
>> + [(set (match_operand:SI 0 "pseudo_register_operand"
>> "=r")
>> +(mult:SI (match_operand:SI 1 "pseudo_register_operand"
>> "r")
>> +
On 07/27/2011 06:21 AM, Georg-Johann Lay wrote:
> +(define_insn_and_split "*mulsi3"
> + [(set (match_operand:SI 0 "pseudo_register_operand"
> "=r")
> +(mult:SI (match_operand:SI 1 "pseudo_register_operand"
> "r")
> + (match_operand:SI 2 "
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02113.html
Weddington, Eric wrote:
>
>> -Original Message-
>> From: Georg-Johann Lay
>>
>> This means that a pure __mulsi3 will have 30+30+20 = 80 bytes (+18).
>>
>> If all functions are used they occupy 116 bytes (-4), so they actually
>> save
Georg-Johann Lay wrote:
> I found that too painful, and on devices with >= 8k flash the
> self-tail-call will just save 4 bytes.
That' not correct: even on devices >= 8k an rcall will always reach
the destination, so that the self tail-call always saves 6 bytes.
Johann
Eric Weddington a écrit:
__umulhisi3 reads:
DEFUN __umulhisi3
mul A0, B0
movwC0, r0
mul A1, B1
movwC2, r0
mul A0, B1
add C1, r0
adc C2, r1
clr __zero_reg__
adc C3, __zero_reg__
mul A1, B0
add C1, r0
adc C2, r1
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Monday, July 25, 2011 10:29 AM
> To: Weddington, Eric
> Cc: gcc-patches@gcc.gnu.org; Anatoly Sokolov; Denis Chertykov; Richard
> Henderson
> Subject: Re: [Patch,AVR]: PR49687 (bette
Weddington, Eric wrote:
>
>> Eric, can you review the assembler routines and say if such reuse is ok or
>> if you'd prefer a
>> speed-optimized version of __mulsi3 like in the current libgcc?
>
> Hi Johann,
>
> Typically a penalty on speed is preferred over a penalty on code size. Do you
> alr
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Monday, July 25, 2011 3:32 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Anatoly Sokolov; Denis Chertykov; Weddington, Eric; Richard Henderson
> Subject: [Patch,AVR]: PR49687 (better widening 32-bit mul)
>
> Eric, can
15 matches
Mail list logo
