[PATCH] D93849: [RISCV] Define vmclr.m/vmset.m intrinsics.

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

In D93849#2472514 <https://reviews.llvm.org/D93849#2472514>, @frasercrmck wrote:

> Out of curiosity, what would the pros/cons be between instead expanding these early in the ISel custom inserter vs. late in the expand-pseudos pass as you've done? I would imagine that the `vmxor` and `vmxnor` instructions will have better integration with the rest of the compiler (scheduling info, for instance) so we'd prefer to have those around. Otherwise we might have to add special-cases for these pseudos to treat them like their underlying instructions.

If we expand them early there's no guarantee the register allocator would pick the same register for the inputs as the output. Our downstream repo and probably BSC's repo was expanding them in a custom inserter and putting the same vreg on the inputs and the outputs with the input operands marked with undef. Which seemed to work, but I'm surprised that isn't flagged as a violation of SSA by the machine verifier. Expanding after register allocation allows us to force the source registers explicitly.

I would imagine a high performance out of order processor would want to detect these instructions as a special case of xor/xnor and not read the data from the input register. Whether they would check that the inputs and the output are the same register or just the inputs are the same register I'm not sure. X86 CPUs for many generations have recognized xor eax, eax as special zero idiom that doesn't have a dependency on the previous value of eax. The X86 backend also uses pseudos and a post RA expansion. For scheduling, X86 has various WriteZero classes the pseudos are assigned to and I believe there is special code in most of the scheduler models to detect xor with same input post RA.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93849/new/

https://reviews.llvm.org/D93849