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

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Tue, 2005-11-22 at 15:33, Dave Korn wrote:
> Richard Earnshaw wrote:
> > On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote:
> > 
> >> 
> >> 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.
> > 
> > It would also have to ensure that the volatile memory operation wasn't
> > moved across any other 'relevant' (for some suitable definition of
> > relevant) memory operation (combine can cause limited re-ordering of
> > load operations, for example).
> > 
> > R.
> 
> 
>   Hmm, I think I see.  Well, that should be a fairly easy thing to ensure in
> the case where we're combining two consecutive insns!  :-)

I think that is probably unreasonably restrictive.

AFAICT it is probably safe to do the combination provided (in addition
to the normal restrictions on combine) that:

1) Not more than one volatile memory ref appears in the insns being
considered (i1 i2 i3) (we can't guarantee ordering in that case)
2) A volatile load isn't moved across any other volatile load or store
3) A volatile load isn't moved across any store that may alias (though
I'd expect that to be volatile if there's a real risk of aliasning, so
maybe we could have another dimension in the 'may-alias' test here).
3) The volatile load isn't moved across any insn containing
unspec_volatile.
4) The act of combining doesn't change the mode of the access to memory
(it may not be valid to access a subreg of a volatile SImode object
using QImode, for example).

There may, of course, be other restrictions that I haven't thought of...
:-)

Of these, perhaps the hardest to test is the last one, since now all the
simplification rules that we have will need checking for validity
(unless we can do some final check after substitution has been
completed).

R.