[PATCH] D122582: StackMap: Fix assertion on undef operands for anyregc

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 29 12:30:06 PDT 2022


arsenm added a comment.

In D122582#3414700 <https://reviews.llvm.org/D122582#3414700>, @dantrushin wrote:

> 0xFEFEFEFE is a special sentinel value which means dead pointer. Now you just passing garbage to GC. (Theoretically this might be OK, practically I don't think so)

It seems to me like you are blessing undef registers with special semantics, which is not what undef is for. If the value was undefined, it's undefined. The undef marker just informs the register liveness tracking of this. It doesn't make sense to have a lowering pass try to fix up the undefined value to something to avoid a crash. Transforming this is basically creating a mini-sanitizer/hardening.

> PATCHPOINT is special pseudo with fancy encoding requirements. With `anyregcc` convention it requires function return value and arguments to be encoded in StackMap as well.
> Obviously, it has different encoding requirements for THAT part.
>
> I don't know if you really use PATHPOINT instruction or simply fixing some artificial test, but we use STATEPOINT instructions as described and you just broke it.

I don't use it and an simply trying to fix lit test failures after an unrelated patch.

> And, by the way, you test case does not make any sens to me. Is it correct to have a `dead` DEF with `undef` USE?  What that would mean?

Yes. These flags maintain liveness and don't imply any particular semantic meaning. It means there's no relation between the def and the use and the register is available between the two points. In the cases I'm trying to fix, the liveness is artificial. The register allocation failed, so the liveness information is essentially garbage. My patch will produce flags like this to avoid triggering verifier errors after fatal compile errors.


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

https://reviews.llvm.org/D122582



More information about the llvm-commits mailing list