Issue Details (XML | Word | Printable)

Key: RVM-467
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: David Grove
Reporter: Ian Rogers
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
RVM

BURS performing illegal reordering to before PEI

Created: 29/Apr/08 11:27 AM   Updated: 06/May/08 10:50 AM
Component/s: Compiler: Optimizing
Affects Version/s: None
Fix Version/s: 2.9.3

Time Tracking:
Not Specified

File Attachments: 1. Java Source File tNewInstance.java (2 kB)

Issue Links:
Supercedes
 


 Description  « Hide
BURS is converting the following code:

-3 LABEL9 Frequency: 1.0
4 int_add t421sa(Lorg/vmmagic/unboxed/Address = t291pa(Lorg/vmmagic/unboxed/Address, 12
5 int_store 0x6008cd54, t421sa(Ljava/lang/Object, -12, <unused>, <unused>
5 int_store 0, t421sa(Ljava/lang/Object, -4, <unused>, <unused>
-3 unint_end
62 EG null_check t20pv(GUARD) = l15pa(Ljava/lang/reflect/Constructor
1 int_load t76sa(Ljava/lang/reflect/VMConstructor;,d,p) = l15pa(Ljava/lang/reflect/Constructor, 4, <mem loc: Ljava/lang/reflect/Constructor;.cons>, t20pv(GUARD)
5 EG null_check t80sv(GUARD) = t76sa(Ljava/lang/reflect/VMConstructor;,d,p)
5 int_load t480a(Lorg/jikesrvm/objectmodel/VM_TIB = 0x60040288, 10360, <mem loc: JTOC @0x00002878>, <unused>
5 int_move t464sa(Lorg/jikesrvm/objectmodel/VM_TIB = t480a(Lorg/jikesrvm/objectmodel/VM_TIB
5 int_load t465sa(Lorg/jikesrvm/ArchitectureSpecific$VM_CodeArray = t464sa(Lorg/jikesrvm/objectmodel/VM_TIB, 92, <unused>, <TRUEGUARD>
5 EG call t79sa(Ljava/lang/Object AF CF OF PF ZF ESP = t465sa(Lorg/jikesrvm/ArchitectureSpecific$VM_CodeArray,
virtual_exact"< BootstrapCL, Ljava/lang/reflect/VMConstructor; >.construct ([Ljava/lang/Object;)Ljava/lang/Object;", t80sv(GUARD), t76sa(Ljava/lang/reflect/VMConstructor;,d,p), t421sa([Ljava/lang/Object;,x,p) ESP
12 int_load t481a(Lorg/jikesrvm/objectmodel/VM_TIB = 0x60040288, 44936, <mem loc: JTOC @0x0000af88>, <unused>
12 int_load t466sa(Lorg/jikesrvm/ArchitectureSpecific$VM_CodeArray = t481a(Lorg/jikesrvm/objectmodel/VM_TIB, 100, <unused>, <TRUEGUARD>
12 int_load t482a(Ljava/io/PrintStream = 0x60040288, 0x11058, <mem loc: JTOC @0x00011058>, <unused>
12 int_load t483a(Ljava/lang/String = 0x60040288, 0x14c34, <mem loc: JTOC @0x00014c34>, <unused>
12 EG call AF CF OF PF ZF ESP = t466sa(Lorg/jikesrvm/ArchitectureSpecific$VM_CodeArray, special_exact"< BootstrapCL, Ljava/io/PrintStream; >.print (Ljava/lang/String;Z)V",
<TRUEGUARD>, t482a(Ljava/io/PrintStream, t483a(Ljava/lang/String, 1 ESP
75 int_move l1pi(Z) = 1
-1 bbend BB9

into:

-3 LABEL9 Frequency: 1.0
4 ia32_lea t421sa(Lorg/vmmagic/unboxed/Address = <[t291pa(Lorg/vmmagic/unboxed/Address;)]+12>DW
5 ia32_mov <[t421sa(Ljava/lang/Object;)]+-12>DW = 0x6008cd54
5 ia32_mov <[t421sa(Ljava/lang/Object;)]+-4>DW = 0
-3 unint_end
62 EG null_check t20pv(GUARD) = l15pa(Ljava/lang/reflect/Constructor
75 ia32_mov l1pi(Z) = 1
1 ia32_mov t76sa(Ljava/lang/reflect/VMConstructor;,d,p) = <[l15pa(Ljava/lang/reflect/Constructor;)]+4>DW (<mem loc: Ljava/lang/reflect/Constructor;.cons>, t20pv(GUARD))
5 EG null_check t80sv(GUARD) = t76sa(Ljava/lang/reflect/VMConstructor;,d,p)
5 ia32_mov t480a(Lorg/jikesrvm/objectmodel/VM_TIB = <0+1610885888>DW (<mem loc: JTOC @0x00002878>)
5 ia32_mov t464sa(Lorg/jikesrvm/objectmodel/VM_TIB = t480a(Lorg/jikesrvm/objectmodel/VM_TIB
5 EG ia32_call t79sa(Ljava/lang/Object AF CF OF PF ZF ESP = <[t464sa(Lorg/jikesrvm/objectmodel/VM_TIB;)]+92>DW (<TRUEGUARD>),
virtual_exact"< BootstrapCL, Ljava/lang/reflect/VMConstructor; >.construct ([Ljava/lang/Object;)Ljava/lang/Object;", t76sa(Ljava/lang/reflect/VMConstructor;,d,p), t421sa([Ljava/lang/Object;,x,p) ESP
12 ia32_mov t482a(Ljava/io/PrintStream = <0+1610945248>DW (<mem loc: JTOC @0x00011058>)
12 ia32_mov t483a(Ljava/lang/String = <0+1610960572>DW (<mem loc: JTOC @0x00014c34>)
12 ia32_mov t481a(Lorg/jikesrvm/objectmodel/VM_TIB = <0+1610920464>DW (<mem loc: JTOC @0x0000af88>)
12 EG ia32_call AF CF OF PF ZF ESP = <[t481a(Lorg/jikesrvm/objectmodel/VM_TIB;)]+100>DW (<TRUEGUARD>), special_exact"< BootstrapCL, Ljava/io/PrintStream; >.print (Ljava/lang/String;Z)V",
t482a(Ljava/io/PrintStream, t483a(Ljava/lang/String, 1 ESP
-1 bbend BB9

notice the definition of l1 has been hoisted before the calls which are PEI, a subsequent test of l1 is then failing. This code is taken from tNewInstance. And can be reproduced by just opt compiling tNewInstance's main method:

./dist/prototype-opt_x86_64-linux/rvm org.jikesrvm.tools.oth.OptTestHarness -methodOpt tNewInstance main - -main tNewInstance

I have modified tNewInstance to print a message prior to l1 being set. We don't reorder the calls so the message is never printed. I have attached my modified tNewInstance.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
David Grove added a comment - 05/May/08 04:46 PM
We add edges in the dependence graph between PEIs and instructions that define variables that are live on entry to one of the blocks exception handlers. This is how BURs is instructed to constrain instruction re-orderings so that we respect ordering constrains of local variable assignments and PEIs.

I have to poke at this some more, but my initial wild guess from looking at the IR is that presence of OSR-guarded inlining "between" the use of l1 and the entry to the catch block might be confusing live analysis. It's likely the bug is that liveness is getting a little confused about what is actually live in the handler blocks and that is why the instruction is being illegally moved.

A brute force fix would be to treat all instructions that define a variable whose live range spans multiple basic blocks as if they were live in a handler block, but that would really constrain code motion (this is the reason why we are trying to identify just those variables that are live in the block's exception handlers and only adding edges between PEIs and them).


David Grove added a comment - 05/May/08 09:35 PM
Root cause is that the dependence graph construction is missing the edges in the dependence graph that are supposed to pin defs of registers potentially live in handler blocks below PEIs. Far as I can tell (assuming I actually managed to reconstruct how this is supposed to work), this has always been broken because the code that is supposed to insert these edges is one level of conditionals too deep in computeForwardDependenciesDef in OPT_DepGraph. It only fires when the register is defined more than once in the same basic block.

I have a fix for this particular problem, but want to inspect the rest of the dep graph construction logic for similar problems tomorrow morning before committing the fix.


David Grove added a comment - 06/May/08 10:50 AM
Fixed in r14192.