Might as well clarify copyright status on *all* the msp430 files in
libgcc. While one might claim some are so trivially small and thus not
suitable for copyright protection, I'd rather not rely on that for
anything in libgcc since those bits get included into user code and
lawyers look at them very carefully. Others are (C) Red Hat with
nonstandard language -- I don't see the value in doing something
nonstandard here.
GPL + exception seems like the way to go, except in those cases where
the code is coming from a 3rd party.
I'm assuming you documented all the MSP430 options. I didn't check them
closely. I'm also assuming the libgcc functions are reasonably correct.
For popm, why not define a new output modifier instead of using %I, per
the comments. That seems cleaner to me.
movqihi seems wrong. You really should determine why the standard
methods for handling automatic elimination of extensions when loading
from memory isn't working. I believe most RISC port in GCC uses those
mechanisms successfully.
Every pattern that is using (subreg:SI (thing:PSI)) needs to be
explained on this list and given an explicit clearance. It really looks
like you're just papering over problems elsewhere.
As the comment in addhi_cy mentions, that is truly dangerous and wrong.
You can't let that stay in the port without proving GCC won't do a
code motion that causes problems. Just because sub, cmp, shift, etc
haven't shown up in your tests doesn't mean they can't happen, they just
didn't show up in your tests.
I don't see any atomics? Not supported on this target?
Jeff
