msp430 port

[Jeff Law]

On 07/30/2013 09:24 PM, DJ Delorie 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.
I'd say it's not as simple as you make it out to be.  You can't blindly 
combine operations on volatile memory.  ie, the programmer may have 
written them as separate statements and if they're volatile you should 
leave them alone.  With this change a series of statements involving 
volatiles might be combined into a single insn.  That's not good.

So while you will get better optimization in the presence of volatile, 
you'll also eventually get a mis-optimization of a volatile reference. 
And debugging it will be an absolute nightmare because whether or not it 
causes a visible problem will be dependent on the state of some hardware 
widget.

I'll note that *NO* ports in the official GCC sources do this and that's 
because it's wrong.  Unfortunately, I missed this when looking at the 
port or I would have called it out earlier.  What you may have done for 
ports that are still in private trees is not pertinent.



Jeff