msp430 port

[DJ Delorie]

> > Index: gcc/cfgexpand.c
> > ===================================================================
> > --- gcc/cfgexpand.c	(revision 201184)
> > +++ gcc/cfgexpand.c	(working copy)
> I thought I already approved this.  Go ahead and install it.

Sorry, I forgot to split out those three patches when I diffed.

> > Index: gcc/simplify-rtx.c
> > ===================================================================
> > --- gcc/simplify-rtx.c	(revision 201184)
> > +++ gcc/simplify-rtx.c	(working copy)
> Testcase?  Explanation?  This seems like you're papering over a bug.

Likewise.

> > Index: gcc/dwarf2cfi.c
> So was there a discussion of this patch?  Presumably BITS_PER_WORD is 16 
> and you've got 20 bit pointers which causes this problem, right?

I don't recall any discussion.  Right, pointers are bigger than words.

> I think you should go ahead and install this patch as well.

Ok.

> > +; Note: using POPM.A #1 is two bytes smaller than using POPX.A....
> > +
> > +(define_insn "movsipsi2"
> > +  [(set (match_operand:PSI            0 "register_operand" "=r")
> > +	(subreg:PSI (match_operand:SI 1 "register_operand" "r") 0))]
> > +  "TARGET_LARGE"
> > +  "PUSH.W %H1 { PUSH.W %1 { POPM.A #1, %0"
> > +)
> So how is this different fram
> (set (psi) (truncate:psi (si)))?

It should be the same, of course.  I typically look at what gcc *is*
generating, not what it *should* be generating, though ;-)

GCC does a lot of silly things these days.

> > +; This pattern is needed in order to avoid reload problems.
> > +; It takes an SI pair of registers, adds a value to them, and
> > +; then converts them into a single PSI register.
> > +
> > +(define_insn "addsipsi3"
> > +  [(set (subreg:SI (match_operand:PSI 0 "register_operand" "=&r") 0)
> > +	(plus:SI (match_operand:SI    1 "register_operand" "0")
> > +		 (match_operand       2 "general_operand" "rmi")))
> > +   (clobber (reg:CC CARRY))
> > +   ]
> > +  ""
> > +  "ADD.W\t%L2, %L0 { ADDC.W\t%H2, %H0 { PUSH.W %H0 { PUSH.W %L0 { POPM.A #1, %0"
> > +
> Is it possible the insns which resulted in adding this pattern came from 
> trying to zero/sign extend the frame pointer, then the frame pointer 
> gets eliminated and turns into a (plus (sp) (const_int)?

It's possible that's one case, but *all* pointer math happens in
SImode since the pointer_plus change went in.  So this pattern happens
a lot.