RVM

Missing BURS rule?

Details

  • Type: Bug Bug
  • Status: In Progress In Progress
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: hg tip
  • Fix Version/s: 3.1.4
  • Component/s: Compiler: Optimizing
  • Labels:
    None
  • Environment:
    x86_64-linux and ia32-osx
  • Testcase included:
    yes
  • Number of attachments :
    2

Description

The attached patch is a snapshot of my Sapphire work based off 3.1.1. It complies cleanly (working is a whole different problem...) but when I apply a simple clean up to the mutator write barrier code (attached) it seems to break the Opt compiler.

Compiling with the following: $ant -Dhost.name=ia32-osx -Dconfig.name=ExtremeAssertionsOptAdaptiveSapphire
Gives the following (partial) output:

{{
[echo] Exception occurred in ConvertLIRtoMIR
[echo] org.jikesrvm.compilers.opt.OptimizingCompilerException: ERROR produced in module:BURS
[echo] rule missing in G call AF CF OF PF ZF ESP = t1628sa(Lorg/jikesrvm/ArchitectureSpecific$CodeArray, special_exact"< BootstrapCL, Lorg/mmtk/plan/sapphire/SapphireMutator; >.writeBarrierAssertions (Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/ObjectReference;)V",
[echo] <TRUEGUARD>, t1027sa(Lorg/jikesrvm/scheduler/RVMThread;,p), t1029sa(Lorg/vmmagic/unboxed/Address, t1780a(Lorg/mmtk/plan/ParallelCollectorGroup ESP
[echo] call
[echo] int_load
[echo] int_load
[echo] INT_CONSTANT 822608480
[echo] INT_CONSTANT 6424
[echo] INT_CONSTANT 336
[echo] other_operand
[echo] register
[echo] other_operand
[echo] int_add
[echo] INT_CONSTANT 20
[echo] register
[echo] int_load
[echo] INT_CONSTANT 822608480
[echo] INT_CONSTANT 7660
[echo]
[echo]
[echo] at org.jikesrvm.compilers.opt.lir2mir.ia32.BURS_STATE.mark(BURS_STATE.java:129)
}}

  1. GZip Archive
    sapphieSnapshot.patch.gz
    21/Aug/11 12:06 AM
    1.07 MB
    Laurence Hellyer
  2. Text File
    writeBarrierRefactor.patch
    21/Aug/11 12:06 AM
    1 kB
    Laurence Hellyer

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ian Rogers added a comment - - edited

You have constant offset from constant base, which is an absolute address, the two should have been combined before going to BURS.

Show
Ian Rogers added a comment - - edited You have constant offset from constant base, which is an absolute address, the two should have been combined before going to BURS.
Hide
Permalink
David Grove added a comment -

For the PPC backend, we run a final constant folding pass (line 292 of ppc variant of NormalizeConstants). 

      Simplifier.simplify(false, ir.regpool, ir.options, s);

We don't run this pass for the x86 backend because (at least in theory) the tree pattern matching rules are prepared to do the constant folding internally. As a quick workaround, you might try putting in a similar Simplifier call in the x86 version of NormalizeConstants.

Show
David Grove added a comment - For the PPC backend, we run a final constant folding pass (line 292 of ppc variant of NormalizeConstants). Simplifier.simplify( false , ir.regpool, ir.options, s); We don't run this pass for the x86 backend because (at least in theory) the tree pattern matching rules are prepared to do the constant folding internally. As a quick workaround, you might try putting in a similar Simplifier call in the x86 version of NormalizeConstants.
Hide
Permalink
David Grove added a comment -

I'm rusty...we do run Simplifier.simplify for x86, just in a slightly different place. In ConvertALUOps, which happens right before the NormalizeConstants phase. So my suggested quick hack is unlikely to do anything useful.

Show
David Grove added a comment - I'm rusty...we do run Simplifier.simplify for x86, just in a slightly different place. In ConvertALUOps, which happens right before the NormalizeConstants phase. So my suggested quick hack is unlikely to do anything useful.
Hide
Permalink
David Grove added a comment - - edited

Do you happen to know what patch sets you applied to get the FENCE instructions? I think they were added post 3.1.1 (at least 3.1.1 builds cleanly for me, and your patch applies cleanly to 3.1.1, but when I try to build the Saphire configuration it dies because FENCE and MFENCE aren't defined in the assemblers).

Update: ignore this. Apparently I don't know how to move along branches/tags in mercurial as well as I thought I did. Will have to take remedial lessons. The FENCE/MFENCE problem doesn't occur when I apply the patch to a release tarball instead of to a hg repo that I try to move to 3.1.1.

Show
David Grove added a comment - - edited Do you happen to know what patch sets you applied to get the FENCE instructions? I think they were added post 3.1.1 (at least 3.1.1 builds cleanly for me, and your patch applies cleanly to 3.1.1, but when I try to build the Saphire configuration it dies because FENCE and MFENCE aren't defined in the assemblers). Update: ignore this. Apparently I don't know how to move along branches/tags in mercurial as well as I thought I did. Will have to take remedial lessons. The FENCE/MFENCE problem doesn't occur when I apply the patch to a release tarball instead of to a hg repo that I try to move to 3.1.1.
Hide
Permalink
David Grove added a comment -

defer to 3.1.4

Show
David Grove added a comment - defer to 3.1.4

People

  • Assignee:
    David Grove
    Reporter:
    Laurence Hellyer
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: