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: Michael Meissner <meissner at linux dot vnet dot ibm 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>, richard dot earnshaw at arm dot com, 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 11:50:45 -0400
- Subject: Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax
- References: <f865508f0903130434i795ab1ck7c6d4e840951279@mail.gmail.com>
On Fri, Mar 13, 2009 at 12:34:49PM +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.
Note, one thing I encountered when doing the SSE5 work at AMD, is
SHIFT_COUNT_TRUNCATED really needs a mode argument (and ideally should be moved
into the gcc_target structure). In particular, shifts done in the general
purpose registers were not truncated, but vector shifts done in the SSE5
instructions were truncated (or vice versa).
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com