Add typing details for cmpxchg and other rmw operations #92
Conversation
In particular, clarify that the type of the expected value operand to cmpxchg can be a supertype of the field type. This gives optimizers like Binaryen more leeway to refine field types because they are constrained by only the type of the replacement operand and not by the type of the expected value operand.
| C |- struct.atomic.rmw.add x y : [(ref null x) t] -> [t] | ||
| - C.types[x] = struct fields | ||
| - fields[i] = mut t |
There was a problem hiding this comment.
where is i coming from here?
| C |- struct.atomic.rmw.cmpxchg x y : [(ref null x) t1 t2] -> [t2] | ||
| - C.types[x] = struct fields | ||
| - fields[i] = mut t2 |
There was a problem hiding this comment.
Oops, should be y. Will fix.
Just to double check, this comes for free from subsumption and isn't a semantic change, right? |
This comes for free from subsumption given the described typing rule, but not from an alternative simpler rule where the "expected" operand also has to be a subtype of the field type, just like the "replacement" operand. With that rule, an optimizer could only refine the field type to be the LUB of the expected and replacement operand types. |
Both passes use StructUtils::StructScanner to analyze struct operations. Add support for RMW operations to this utility and update its users to provide the new `noteRMW` hook. Test that GTO and TypeRefining optimizations work as expected in the presence of RMW operations, but leave a proper implementation in ConstantFieldPropagation to a later PR. To allow TypeRefining to refine field types based only on the "replacement" operand and not the "expected" operand of cmpxchg operations, update validation to allow the "expected" field to be a supertype of the accessed field type as long as it is still equality comparable. WebAssembly/shared-everything-threads#92 clarifies this intended typing in the upstream proposal.
Both passes use StructUtils::StructScanner to analyze struct operations. Add support for RMW operations to this utility and update its users to provide the new `noteRMW` hook. Test that GTO and TypeRefining optimizations work as expected in the presence of RMW operations, but leave a proper implementation in ConstantFieldPropagation to a later PR. To allow TypeRefining to refine field types based only on the "replacement" operand and not the "expected" operand of cmpxchg operations, update validation to allow the "expected" field to be a supertype of the accessed field type as long as it is still equality comparable. WebAssembly/shared-everything-threads#92 clarifies this intended typing in the upstream proposal.
|
ping @conrad-watt |
3 participants
In particular, clarify that the type of the expected value operand to
cmpxchg can be a supertype of the field type. This gives optimizers like
Binaryen more leeway to refine field types because they are constrained
by only the type of the replacement operand and not by the type of the
expected value operand.