This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix *two* AVR backend bugs (PR19293 + PR19329)
- From: Paul Schlie <schlie at comcast dot net>
- To: Bernardo Innocenti <bernie at develer dot com>
- Cc: Giovanni Bajo <rasky at develer dot com>,<denisc at overta dot ru>,Stefano Fedrigo <aleph at develer dot com>,Marek Michalkiewicz <marekm at amelek dot gda dot pl>,<gcc-patches at gcc dot gnu dot org>
- Date: Sun, 23 Jan 2005 23:30:55 -0500
- Subject: Re: [PATCH] Fix *two* AVR backend bugs (PR19293 + PR19329)
> From: Paul Schlie <schlie@comcast.net>
>> From: Bernardo Innocenti <bernie@develer.com>
>> I agree. For all shift patterns, we should consistently:
>>
>> - return the input operand unchanged for shifts by 0;
>> - do the right thing for shifts between 1 and N-1;
>> - return 0 for out-of-range shifts;
>>
>> I will prepare an updated patch.
>
> If you're not going to treat positive out-of-range shift as a no-op,
> it might make sense to treat arithmetic right-shifts > mode-size as
> equivalent to it's maximum valid arithmetic right-shift, thereby:
>
> (((signed >> y) >> y) == ((signed) x >> (2 * y))
>
> Thereby effectively saturating all positive shifts; but wonder if <= 0 shifts
> might be most efficiently handled as a no-op, i.e. logically only shifting
> while count > 0 ?
>
> (but still wonder if GCC things the cc is set for shifts of 0 if not optimized
> away?)
For what it's worth, it appears that the middle-end's shift via an add-loop
behaves just this way; with the potential down-side that it will iterate as
many times than it's operand's shift count regardless of the operand's size;
but is most efficient if the shift count is less than it's bound, as it
doesn't test to see if it exceed it's bound initially.