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

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

OK, I understand the concern better now, thanks.

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.

But I agree it would be good if this could be ensured by the machine verifier.

@hfinkel, you originally suggested use of MMOs --- any comments from your side on this issue?

Now, if we indeed cannot use MMOs to distinguish strict from non-strict FP operations, what could be the alternative?  I guess I can see:

- Different opcodes.   That certainly cannot be dropped by accident.  But it goes back to each target having to duplicate all FP patterns, which is exactly what we wanted to avoid ...

- Using MIFlags bits.  This may be nice since there's already many FP-related bits in there.  However, it seems that there's likewise no way to verify those bits aren't accidentally dropped.  (Also, we may run out of bits in the current uint16_t field.)

- Using a regular MachineOperand, not an MMO.   This operand would have to be of some new type, and would have to be inspected by code that currently looks at MMOs to determine dependencies etc.  Because this would be in the list of operands of the instruction pattern, its presence would be enforced by the verifier.  For non-strict FP instructions, the pattern might include a default no-op value.

- Making a MMO mandatory.  E.g. define that instructions with the mayAccessMemory flag *must* have at least one MMO, which is enforced by the verifier.   When initially emitting a non-strict FP MI, CodeGen would create a "dummy" MMO that counts as "no-access" to comply with the rule.

Thoughts?


Repository:
  rL LLVM

https://reviews.llvm.org/D52785