This is the mail archive of the
mailing list for the GCC project.
Re: msp430 port
- From: DJ Delorie <dj at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 19 Jul 2013 19:32:02 -0400
- Subject: Re: msp430 port
- References: <51E700D1 dot 702 at redhat dot com>
> 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.
Most of them are just optimizations, but the problem with reload is
that an SImode register *can't* hold a PSImode value. Registers are
20 bits; a PSImode value is 20 bits. SImode values require two
registers (16 bits each). Converting between SImode and PSImode is
both nontrivial and very common (pointer math).
What I really need is an int20_t type in the core of gcc, so I can set
Pmode to *that*, to avoid the SImode stuff completely. But that's a
core change, not a target change.
> 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'll try again, but last time I put all the carry logic in all the
insns, and code size grew quite a bit, and I couldn't figure out why.
Do I need two patterns for each insn? One that clobbers the carry,
and one that sets it?
> I don't see any atomics? Not supported on this target?
None. Limited opcode set, no multi-core, just a simple MCU...