Robert Dewar wrote:
> Richard Kenner wrote:
>
>> The issue is that we currently don't combine if volatile is anywhere in
>> sight, whether or not we'd be affecting that access. Just because you
>> have something volatile on the LHS doesn't mean we can't combine into
>> the RHS. A good example are addressing modes: if we have a MEM->MEM
>> copy with one side volatile, doing anything inside the addressing
>> computation of either (even the volatile one) is perfectly safe.
>
> OK, in that case you have to add to the list of restrictions that you
> never combine volatile references.
It's because of the complexity of thinking through all these issues that my
first suggestion was so conservative.
>I did not see that in the list.
Isn't it pretty much implied by point 1, "Not more than one volatile memory
ref appears in the instructions being considered"?
cheers,
DaveK
--
Can't think of a witty .sigline today....
