This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: msp430 port


> 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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]