This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: msp430 port
- From: Mike Stump <mikestump at comcast dot net>
- To: DJ Delorie <dj at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, nickc at redhat dot com, law at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Wed, 31 Jul 2013 10:49:19 -0700
- 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>
On Jul 30, 2013, at 8:24 PM, DJ Delorie <dj@redhat.com> wrote:
> [nickc added for comments about the bits he wrote]
>
>> ... define these as
>>
>> (define_predicate "msp_general_operand"
>> (match_code "mem,reg,subreg,const_int,const,symbol_ref,label_ref"
>> {
>> int save_volatile_ok = volatile_ok;
>> volatile_ok = 1;
>> int ret = general_operand (op, mode);
>> volatile_ok = save_volatile_ok;
>> return ret;
>> })
>>
>> That said, why do they exist?
>
> Because gcc refuses to optimize operations with volatile memory
> references, even when the target has opcodes that follow the volatile
> memory rules. "set bit in memory" for example. I've had to do
> something like this for every port I've written, for the same reason,
> despite arguing against gcc's pedantry about volatile memory accesses.
So, I prefer having a target hook that says, this port is volatile clean, go ahead and fully optimize volatile. Then, a port that would want to do this, can simply turn it on, fix all the bugs, and get on with life. The default for a port, should be to say, this port is volatile clean. All the old ports can say, unclean. In time, hopefully they will all be deleted (for fixed). :-)