Having spent yesterday distracted thinking I had my own bug, I found I was actually looking at this bug I have a concrete example of the problem in that we simplify:
3 get_obj_tib t913sa([Ljava/lang/Object = t528psa(Ljava/util/Collection;,p), <TRUEGUARD>
3 ref_move t913sa([Ljava/lang/Object = tib "java.util.Collection"
However, a Collection is an interface so it's TIB won't really be the TIB we're after. What has confused the simplifier is that the register is marked as having a precise type. This should mean the value of the register was created by a new. But a collection is an interface which you can't possibly allocate or have as precise!
The bug occurs in java.security.CodeSource.<init> which inlines the Collection version of HashMaps constructor (inlining must be enabled for the bug to occur ). The culprit of incorrectly specifying the precise type on the register appears to be OPT_BranchOptimizations.
I'd suggest that we:
1) disable folding get_obj_tib on registers (constants should be ok)
2) create an IR verifier that when we check register operands of instructions, if a register operand is marked as precise it can't be an interface or abstract class
3) fix all the places this shows the precise type information has become corrupt
which is quite a bit of work, but it's better we're strict about register properties prior to re-introducing all the O3 optimization phases (that probably violate them as well). This won't stop all possible corruptions of register precise type information (corruptions from a class to another class will be possible), but hopefully we have enough test cases that we will find all our bugs.