[PATCH] D52785: [PseudoSourceValue] New category to represent floating-point status

[Matt Arsenault via Phabricator via llvm-commits]

arsenm added a comment.

In https://reviews.llvm.org/D52785#1256226, @hfinkel wrote:

> > I'm not sure where it's documented, but MMOs are definitely not guaranteed to be preserved (except in global-isel, the verifier enforces this for some of the G_* instructions). I'm not aware of anywhere specifically dropping them, but code is not required to preserve them.
>
> Why do you say this?


Things like MachineInstr::hasOrderedMemoryRef() has handling such as:

  // Otherwise, if the instruction has no memory reference information,
  // conservatively assume it wasn't preserved.
  if (memoperands_empty())
    return true;

I always assumed thing were allowed to drop MMOs to avoid passes having to figure out what to do when an instruction had multiple memoperands.
There is also an explicit MachineInstr::dropMemRefs, which the outliner uses.

> 
> 
>> I had thought that we'd already need to preserve MMOs, since they contain flags like atomic, nontemporal, or volatile accesses, which likewise would change semantics if dropped.
> 
> Not all of these things are equivalent, as their semantics are assumed to be also part of the instruction. Volatile, however, is not, and that needs to be preserved. I believe that we depend on the fact that MachineInstr::isDereferenceableInvariantLoad returns false for volatile MMOs to prevent MachineCSE from removing some volatile loads.

Volatile needs to be preserved if the MMO is present, but if the MMO is missing entirely the operation can be conservatively assumed to be volatile (i.e. the handling in hasOrderedMemoryRef)


Repository:
  rL LLVM

https://reviews.llvm.org/D52785