This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: msp430 port
- From: Jeff Law <law at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 24 Jul 2013 15:26:14 -0600
- Subject: Re: msp430 port
- References: <51E700D1 dot 702 at redhat dot com> <201307192332 dot r6JNW2m8013830 at greed dot delorie dot com>
On 07/19/2013 05:32 PM, DJ Delorie wrote:
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).
Sorry, but I don't see how this is any different than what we've done
before. For example, the mn102 had 24bit address registers (PSImode),
but anytime you wanted to work on in SImode, you head to use a pair of
16 bit data registers.
What you need to do is explain the reload issue in enough detail that
someone can help guide you to what needs to be fixed either in reload or
in the port itself.
Converting between SImode and PSImode is
both nontrivial and very common (pointer math).
Yes, I'm painfully aware.
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.
Right. I'm not aware of anything that'll make adding int20_t a
tractable problem in GCC.
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?
Look at the x86, where we have all this pain as well.
My point is that by not modeling this right, you're running the risk of
having an insn which sets the carry flag get inserted right in between
these two insn sequences.
You might also get better code by keeping those two instruction
sequences as a single insn until after reload.
Jeff