This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: msp430 port
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: DJ Delorie <dj at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, rth at redhat dot com, nickc at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Mon, 19 Aug 2013 23:39:50 +0200
- Subject: Re: msp430 port
- References: <51E700D1 dot 702 at redhat dot com> <201307232208 dot r6NM8QpY018297 at greed dot delorie dot com> <51F81F81 dot 4070303 at redhat dot com> <201307310324 dot r6V3OkjY005420 at greed dot delorie dot com> <52127E4D dot 1030901 at redhat dot com> <201308192049 dot r7JKnS2E029457 at greed dot delorie dot com>
On Mon, 2013-08-19 at 16:49 -0400, DJ Delorie wrote:
> > I'd say it's not as simple as you make it out to be. You can't blindly
> > combine operations on volatile memory.
>
> I'm not blindly combining them, I'm combining them when I know the
> hardware will do the volatile-correct thing.
>
> > ie, the programmer may have written them as separate statements and
> > if they're volatile you should leave them alone.
>
> Most of the programmers I know would expect "port |= 0x80;" to do a
> hardware-specific "set bits" operation, not a series of
> volatile-pedantic operations, especially when the ISA has a set of
> insns specifically designed to do bit operations on volatile I/O
> registers.
>
> > With this change a series of statements involving
> > volatiles might be combined into a single insn. That's not good.
>
> If the insn does exactly the same thing as the operations, just
> faster, why is it not good?
>
> > I'll note that *NO* ports in the official GCC sources do this and that's
> > because it's wrong.
>
> m32c, rl78, and sh do this (to varying degrees) in the official
> sources.
Just a note regarding the issue in SH:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52483
In this case, the problem is that the volatile handling in
'general_operand' prevents matching of 'complex' addresses and sign
extending mem loads.
The recent SH volatile mem load fix doesn't play with the 'volatile_ok'
variable before invoking 'general_operand', but rather avoids it
altogether, by not using 'general_operand' for matching mems. In this
case it should be fine, since it's done in the predicate
'general_movsrc_operand' which is used for mem loads only and not in
arithmetic insns. Maybe it would be better to handle this in a general
way somehow instead of having to do workarounds in each target.
Cheers,
Oleg