On Jul 30, 2013, at 8:24 PM, DJ Delorie <d...@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). :-)
