Fix a problem caused by #5653

[gita-omr]

#5653 caused a problem on a 32-bit Power platform because it created a MemoryReference to unresolved symbol that was never used. The memory reference constructor created an UnresolvedData snippet that did not have an address in the code to return to. That caused an ASSERT. We need to find a safe fix asap.

@aviansie-ben @rmnattas @AlenBadel @pshipton

[rmnattas]

Can't say I'm familiar with MemoryReference as I don't see how the fix doesn't also end up with a memory reference
with both an index register and an offset.

But, one fix I see that uses only 2 MemoryReferences is having the encoding of the MemoryReference inserting an addi indexReg indexReg offset when the MemoryReference is both an indexed and offset. And there's no P instructions that uses both index and offset that will get negatively effected.

Another solution is changing the MemoryReference constructor to not generate the snippet and generate it when we actually encode the MemoryReference and know that its in use, but I don't think it's safe to do for this next delivery.

[aviansie-ben]

Looking at the code in question, I'm not 100% sure if it's even valid to get there when performing a store to an unresolved symref. That code is only meant to handle stores known not to be volatile and I can't think of any situations where we would create a store to a symref that's unresolved but not marked as volatile.

Regardless, as this is a ppc32-only problem and the code in question is undergoing a lot of changes right now as part of #5652 which would result in any fix being undone if that PR is merged, I'm not inclined to treat this issue as a priority myself at the moment. If this is an issue for the upcoming OpenJ9/IBM SDK releases, you can probably revert #5653 in the release branches used by those projects as a temporary fix. The optimization this was meant to fix had to be disabled later for other reasons and so isn't currently active (see #5684 and #5685). I'm not sure whether the LoadStoreHandler work still has this issue, but if it does then a more permanent fix can be added on top of that.

@rmnattas The reason the old code would end up creating a MemoryReference with an index register and an offset is because forceIndexedForm was called on the first MemoryReference to change it from base+offset form into base+index form before constructing the second MemoryReference based on it. The fix was to construct both MemoryReferences based off of a separate MemoryReference that was not mutated in this way and so would remain in base+offset form.

[gita-omr]

Thanks @aviansie-ben for your response. It really helps! The issue does affect upcoming OpenJ9 and IBM SDK releases.

I can't think of any situations where we would create a store to a symref that's unresolved but not marked as volatile.

Interestingly, it's exactly what happens in this case: unresolved symbol is not a volatile (not sure why yet).