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
