The x86 case differs from the msp430 case in that the x86 case makes
the count a *smaller* mode (SI->QI) where the msp430 case makes it
*bigger* (HI->SI). msp430 uses the "Handle expanding beyond a word"
case in convert_move() (msp430's word is HImode), ending in the
multiword-by-hand case.
On Wed, Apr 16, 2014 at 10:22:52PM -0400, DJ Delorie wrote:
> > + {
> > + other_amount
> > + = simplify_gen_unary (NEG, GET_MODE (op1),
> > + op1, GET_MODE (op1));
> > + other_amount
> > + = simplify_g
Doing some work on the msp430 failures, I discovered that this patch:
> --- gcc/expmed.c.jj 2013-05-07 10:26:46.0 +0200
> +++ gcc/expmed.c 2013-05-11 09:11:54.087412982 +0200
> @@ -2181,14 +2182,22 @@ expand_shift_1 (enum tree_code code, enu
> rtx temp1;
>
>
On Sat, 11 May 2013, Jakub Jelinek wrote:
> On Sat, May 11, 2013 at 09:05:52AM +0200, Jakub Jelinek wrote:
> > > Seems that we ought to have a testcase, even though it probably
> > > means scanning the tree dumps to pick up the undefined behaviour.
> > > Approved with a testcase.
> >
> > I have a
On Fri, May 10, 2013 at 05:18:34PM -0600, Jeff Law wrote:
> On 05/10/2013 08:53 AM, Jakub Jelinek wrote:
> >Hi!
> >
> >Our rotate expansion if rotate optab isn't present for the respective
> >mode looks unsafe for rotations by variable count if that count could
> >be 0, because then it invokes righ
On 05/10/2013 08:53 AM, Jakub Jelinek wrote:
Hi!
Our rotate expansion if rotate optab isn't present for the respective
mode looks unsafe for rotations by variable count if that count could
be 0, because then it invokes right or left shift by bitsize.
While on most targets the hw will probably do
