Re: [Jikesrvm-core] "Valid" IR

[Ian R. <ian...@ma...>]

Ian Rogers wrote:
> On a related topic, should OPT_Operand.instruction always be a 
> non-null handle back to the containing instruction? 
> OPT_CallingConventions breaks this. If the back link must always be 
> valid then should the instruction format setNAME method assign the 
> instruction to the operand?
Aha, it does! There is a problem instead in 
OPT_Instruction.getClearOperand which clears an operand of its 
instruction but not an instruction of its operand. This is simple to fix 
but possibly introduces problems.
> Also, load elimination breaks the SSA form and then uses EnterSSA to 
> fix it again. Obviously this is a mess, but why is it necessary? I 
> don't know why the original registers can't be recycled in the load 
> elimination?
Still holds, anyone any clues?
> I'm also checking if unreachable basic blocks are created then the IR 
> isn't valid. This is because they interact with enter SSA the 
> dominator tree and the dominance frontier, usually resulting in a null 
> pointer exception for a missing dominance frontier. Are unreachable 
> basic blocks invalid IR or is this a bug with enter SSA?
Having created a check and found bugs that IR.verify was missing, I 
believe dead basic blocks in the IR are invalid.

Sorry to post like this. I think the things I'm finding are an important 
heads up for people tracking bugs such as 1213816. I will keep a list of 
the minor bugs I'm finding on bug id 1274081 and submit the patch when 
the verify is working. If people can think of other things to check in 
the IR then please let me know.

Regards,

Ian