This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, bernd dot schmidt at analog dot com, hp at axis dot com, aldyh at redhat dot com, aoliva at redhat dot com, law at redhat dot com, nickc at redhat dot com, kazu at codesourcery dot com, ni1d at arrl dot net, kkojima at gcc dot gnu dot org, matt at 3am-software dot com
- Date: Fri, 13 Mar 2009 13:55:57 +0000
- Subject: Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax
- References: <f865508f0903130434i795ab1ck7c6d4e840951279@mail.gmail.com>
On Fri, 2009-03-13 at 12:34 +0100, Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact. Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
> I want it to mean "it is never truncated".
>
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.
>
> In addition, for arm and m68k I'd like to know whether bitfield
> instructions truncate the bit position the same as shifts (8 bits for
> arm, 6 bits for m68k).
>
> This information is particularly important for targets that do not
> have a simulator in src.
A number of years ago (probably more than 10 now) I tried to rework the
ARM backend code to use a QImode register to represent the shift. That
then fully described the behaviour of the shift operation. While this
made a small number of cases generate code the overall result was
overwhelmingly worse. Maybe I didn't push the tweaks far enough to
recover the lost cases, but I suspect that, at least at that time, GCC
just couldn't do a decent job with having a subreg in the shift operand
position.
Will have to check up on the bitfields question. I do know that the
rules for Neon instructions are not the same as those for ARM
instructions.
R.