Avoid storing PassThrough nodes to temps when splitting blocks

[jdmpapin]

With fixupCommoning, any node commoned across the split point is stored into a temp, and occurrences after the split are replaced with a load.

If this happened with a PassThrough node, we would generate BadILOp because PassThrough claims to have type NoType. In particular, the store would be BadILOp, and it would appear that a conversion is needed at the load, and the conversion would also be BadILOp.

While determining which nodes are commoned across the split point, any PassThrough node encountered with refcount greater than 1 will now be replaced with a fresh PassThrough node with refcount 1. This way, no PassThrough node will be found to commoned across the split point.

[jdmpapin]

@vijaysun-omr, could you please review?

[jdmpapin]

Recently @hzongaro mentioned that I was working on a fix for eclipse-openj9/openj9#21286, and I believe he meant this one. I haven't been able to establish for myself that that's necessarily the same problem as the one I was looking at, but I did see some commonalities in a jitdump, so I'm hopeful that it is. In particular, a BadILOp appeared at top-level with a child that loads the component type of a class, and another BadILOp appeared beneath top-level in a separate block not too far away.

[vijaysun-omr]

Jenkins build all

[jdmpapin]

Jenkins build amac,win

[jdmpapin]

Mac is failing a port library test related to setting an address space limit:

/Users/omr/workspace/Build/fvtest/porttest/si.cpp line  695: omrsysinfo_test_sysinfo_set_limit_ADDRESS_SPACE omrsysinfo_set_limit set ADDRESS_SPACE soft max FAILED

		LastErrorNumber: -113
		LastErrorMessage: Invalid argument

/Users/omr/workspace/Build/fvtest/porttest/testHelpers.cpp:109: Failure
Value of: 0 == numberFailedTestsInComponent
  Actual: false
Expected: true
Test failed!
[  FAILED  ] PortSysinfoTest.sysinfo_test_sysinfo_set_limit_ADDRESS_SPACE (0 ms)
originalSoftLimit=61440
originalHardLimit=61440
soft set to hard limit=61440

I don't see a current known issue, but this has been seen before (#6924) and was thought to be fixed. For some reason, the limit couldn't be set to anything less than about 390 GiB at the time. Maybe there's been another OS level update that affects which values are accepted.

In any case, I'm certain that this failure is unrelated to the changes in this PR.

[AdamBrousseau]

That failure is due to mac15 upgrade. Fixed by #7687. You got caught in the middle when we were testing the PR on the new machines.

[AdamBrousseau]

Jenkins build amac

[jdmpapin]

@vijaysun-omr, all checks have passed.