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 was going to special case the load-byte/zero_extend pair that I've been
particularly targeting, but now ISTM that I could perhaps be more general:
would I be right to think that if
- recog_for_combine fails initially, but succeeds when you set volatile_ok
and try again,
... and ...
- the insns in question are two consecutive insns (this is simpler than
testing every intervening insn to see if it has a 'relevant' mem ref; a
slightly more complex and less conservative test would be to test every
intervening insn and just see if there were _any_ mem refs rather than none at
all),
... and ...
- there is only one mem ref in the two input insns and one in the combined
new pattern and that mem ref has the same mode (because that's simpler than
enumerating all the mem refs and recording their modes and worrying about
which order the various operands might be accessed in if the insns are
combined)
... then it's bound to be safe to let them combine?
BTW, I found this comment from try_combine rather confusing:
/* We come here when we are replacing a destination in I2 with the
destination of I3. */
validate_replacement:
...since whenever the code comes here in _my_ case, I find that what's
happening is that a source in I3 (which matches the dest of I2) is being
replaced by the source of I2. Is the comment just confusingly worded, or is
my understanding of what's happening here actually back-to-front in some way?
cheers,
DaveK
--
Can't think of a witty .sigline today....
