Adding new IL Opcode xrdbar/xrdbari

[cathyzhyi]

We are proposing to add xrdbar/xrdbari opcodes because 2 recent development items need to monitor instance or static fields reads and writes. One is field watch in debugging mode where we need to report fields accesses to the VM. The other one is pauseless GC where every instance field accesses might need to call to the GC to fix up the pointer. In both cases, the load have side affects and we need new opcodes to represent this situation.

The xrdbar/xrdbari need to represent both the side effects of the load as well as the value of the load. They are the same as the corresponding xload/xloadi except that read barrier nodes need to be anchored under a treetop or chk at their point of first evaluation (like a call). Then they can be referenced in subsequent trees.

The children and symbol of indirect read barriers are the same as their corresponding load. It would be something like:

treetop
  xrdbari <#xxx A.instanceB>
    aload <auto 3>
...
  ==>xrdbari

The children and symbol of direct read barriers are the same as their corresponding load with one additional child which is static field class. The extra child is for simplifying code evaluation for unresolved case where the load of unresolved static field class hangs under a treetop.

resolved case:
treetop
  xrdbar <#xxx A.staticB>
     Class of A
...
  ==>xrdbar

unresolved case:
ResolveCHK
    loadaddr  Class of A (unresolved static)
ResolveCHK
    irdbar
      ==>loadaddr
...
  ==>xrdbar

#2875

[mstoodle]

Presumably these are typed like xload/xloadi ?

[cathyzhyi]

@mstoodle yes. updated the description.

[cathyzhyi]

Documenting here the discussion at the architecture meeting #2817 about the rdbar opcodes

• the opcode should be able to be commoned or moved and the optimizations applies to loads should be able to apply to rdbars as well.
• the only difference between the rdbars and loads is that a rdbar has to hang under a treetop before the first use to represent the side effect it's gonna have on evalutor. We want to avoid the complication of dealing with a call in the middle of evaluating another treetop.
• If there are any restrictions on optimizations coming from different modes, debugging mode etc, they should be addressed under different mode rather than property of the opcode. The optimizations like LocalCSE, PRE, loop versioner might need to special case rdbar under those different modes. The special case should be grouped into properties (or queries??) rather than adding another | to a group of other opcode values. Aliasing can be different depending on modes as well.
• Use the load evaluators as the default evaluators for rdbars in omr.
• Need to think about how to write test case for the rdbar opcodes.
• Will need to fill in a new opcode template for new opcode proposal.