Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Ian Lance Taylor <ian at airs dot com>]

"Dave Korn" <dave.korn@artimi.com> writes:

>   Looking at it, this seems to be quite deliberate: combine_instructions()
> calls init_recog_no_volatile() before it runs the combine pass and
> init_recog() afterward.  I haven't delved into the morass of machine-generated
> loveliness that is insn-recog.c, but by modifying recog_for_combine() to try
> calling recog() twice, once with volatiles disabled, and once with them
> enabled, I've been able to determine that that's definitely the cause that
> prevents the volatile loads from being combined with the zero_extend
> operations.

When gcc sees a volatile memory reference, it has to make sure that it
dereferences the memory exactly as described in the source code.  But
it's easy for combine to combine two instructions which dereference
memory into one.  So combine simply disables combining instructions
which use volatile memory references.

>   What's a decent solution here?  Should I come up with a new version of
> general_operand, call it general_or_volatile_operand, that would accept mem/v
> references, and use it for the movXX patterns in my md?  Or, given that this
> is likely to be the most common case and perhaps the only one I'm going to
> care about, should I just define a pattern that matches the (set:SI
> (zero_extend:SI (mem:QI))) insn directly?  Or how about the dodgy hacks that
> temporarily reenable volatile_ok and then clear it again after calling the
> recognizer?

In principle the combiner could make sure that the same number and
type of volatile memory references occur both before and after the
combination, and reject it if not.

Ian