On 02/10/13 09:34, Oleksandr Redchuk wrote:
> 2013/10/2 Georg-Johann Lay mailto:a...@gjlay.de>>
>
> David Brown schrieb:
>
> In general, it would be a good thing to delay the zeroing of r1,
> and it
> is worth searching the issue database for previous issues and
>
2013/10/2 Georg-Johann Lay
> David Brown schrieb:
>
>> In general, it would be a good thing to delay the zeroing of r1, and it
>> is worth searching the issue database for previous issues and filing a
>> new "missed optimisation" issue if it is not there already:
>>
>
> IMHO everyone working on t
David Brown schrieb:
On 01/10/13 09:41, Simon Kirby wrote:
Hello!
How difficult would it be to convince avr-gcc to not re-zero r1 instantly
after mul, but delay it until a zero is actually needed? For example,
see this actual avr-gcc output:
Vneutral = (uint16_t)Vbus * t >> 8;
->
On 01/10/13 09:41, Simon Kirby wrote:
> Hello!
>
> How difficult would it be to convince avr-gcc to not re-zero r1 instantly
> after mul, but delay it until a zero is actually needed? For example,
> see this actual avr-gcc output:
>
> Vneutral = (uint16_t)Vbus * t >> 8;
> ->
> lds
ubject: [avr-gcc-list] Optimization around mul and restoring r1
>
> Hello!
>
> How difficult would it be to convince avr-gcc to not re-zero r1
> instantly
> after mul, but delay it until a zero is actually needed?
Patches to avr-gcc are welcome.
Eric
_
Hello!
How difficult would it be to convince avr-gcc to not re-zero r1 instantly
after mul, but delay it until a zero is actually needed? For example,
see this actual avr-gcc output:
Vneutral = (uint16_t)Vbus * t >> 8;
->
lds r25, 0x20FD
mul r24, r25
movw
