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: Paolo Bonzini <bonzini at gnu dot org>
- To: Bernd Schmidt <bernds_cb1 at t-online dot de>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, richard dot earnshaw at arm 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 14:37:01 +0100
- Subject: Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax
- References: <f865508f0903130434i795ab1ck7c6d4e840951279@mail.gmail.com> <49BA5C4A.7030609@t-online.de>
> The Blackfin does not truncate shift counts. The documentation
> specifies that e.g. for "Dx >>= Dy" instructions, shift counts greater
> than 31 produce a result of zero. Other shift instructions use a sign
> extended part of the shift count to shift either left or right. "I
> don't know" is probably the best answer we can give the compiler.
In my plan, the truncation of shifts is used to canonicalize RTL created
with out of range shift counts. This is useful because such out of
range RTL can appear because of unrolling or inlining. Then the answer
should be based on this: would a "typical" C programmer expect a left
and a right shift from this:
int f(int a)
{
return 0x4000 << a;
}
int x, y;
int main()
{
x = f(1);
y = f(-1);
}
If the C program above can be reasonably considered undefined with
Blackfin, saying "shifts are not truncated" is okay. This is because
the variable left/right shifts can still be described as rtl like
(set A (if_then_else (lt B (const_int 0))
(lshiftrt A (minus (const_int 0) B))
(lshift A B)))
so that the actual arguments are LSHIFT/LSHIFTRT are positive.
Paolo