Jikes RVM / Bugs (Historic) / #501 Assertion failure in OPT

Ian Rogers - 2005-12-12

Logged In: YES
user_id=308843

Hi Robin,

which change did you back out? This is a bug caused by the
changes to the OSR_YieldPoints (I believe) which previously
didn't have their operands renamed during register
allocation. This led to OSR_YieldPoints refering to
registers that were no longer defined on Intel. I removed
the code that stopped renaming being applied to everything
but OSR_YieldPoints (in OPT_GenericStackManager) and that
stopped the problem of undefined registers being referenced
on Intel - so we passed more IR validation than we did
previously. Looking at the PowerPC OPT_StackManager the
needScratch method returns false for a OSR_YieldPoint but
true for everything else (there's a nice comment of "//
PowerPC does not support memory operands"). Reading the
javadoc this means that the OSR_YieldPoint on PowerPC
references memory operands (which the PowerPC doesn't have
and the comment points out). It seems the PowerPC
OPT_StackManager needScratch routine should always return
true regardless of the instruction operator, but this may
have a detrimental effect on register allocation which was
previously choosing to ignore these scratch registers. I
guess this was the cause of the conditional compilation
which was causing the odd behaviour I was seeing on Intel.
We could re-introduce the conditional compilation around the
VM._assert(NOT_REACHED) on line 1086 for PowerPC, but I
don't think this makes the code particularly intelligible.
We should probably make needScratch always return true for
PowerPC and then add a check around the spill register
creation code that says not to do it for PowerPC
YieldPoint_OSR instructions. But we should probably redefine
these operands to something sane to avoid the use with no
definition validation error. I don't understand why PowerPC
OSR_YieldPoint instructions are so special :-).

The whole of the register allocation is due for a (graph
colouring) rethink, but in the mean time the linear scan
algorithm needs patching up. Not fully understanding the
history behing all of the hacks/improvements may be someone
else can write the patch to fix this. For more hacks of the
register allocator see line 999 of OPT_GenericStackManager
whose bug tracking numbers don't appear to make sense when
you follow them through (2642 should be about a bug with the
ECX register but the new reference number 1147274 talks
about a bug with ESP).

Regards, Ian Rogers

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ian Rogers - 2005-12-12

Logged In: YES
user_id=308843

I should have read the comments more, the bug tracking on
line 999 do make sense but the dirty fix has been in place
for 3 years - bleugh :-(. This is all unrelated to the yield
point stuff anyway, I just remember not liking it when I was
trying to fix up the validation - primarily on Intel trying
to get to the cause of bug #1363830 so the loop versioning
could be enabled by default.

Ian

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave Grove - 2005-12-12

Logged In: YES
user_id=1215435

The assert in questions is a VM._assert(NOT_REACHED).

So, yes it should have been guarded by if
VM.VerifyAssertions, but we should never reach that program
point in any case.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave Grove - 2005-12-14

Logged In: YES
user_id=1215435

back out change to OPT_GenericStackManager for now.

Have to consider more carefully if this is actually the
right fix.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ian Rogers - 2005-12-14

Logged In: YES
user_id=308843

Why not back it out for the PowerPC, add the verify
assertions line and add some health warnings e.g.
in OPT_StackManager:
// for some reason PowerPC OSR_YieldPoint instructions think
they can have memory operands (?)
in OPT_GenericStackManager:
// ignore the PowerPC stack manager telling us it can have
memory operands here, it can't, so do nothing. HEALTH
WARNING: This will lead to uses of operands that haven't
been defined and will fail certain IR verifications.

It seems a shame to have this PowerPC botch making a mess of
allocation for Intel and regressing us so that we have
instructions referencing undefined operands again (imo).

Ian

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave Grove - 2005-12-21

Logged In: YES
user_id=1215435

To properly fix this, someone needs to take the time to go
through and understand how OSR_YieldPoint instructions are
being used in the backend to generate OSR maps. Once we
have a better grasp on that, it should be more clear what
the constraints on their operands need to be.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Assertion failure in OPT_GenericStackManager on PPC

Group

Searches

Help

#501 Assertion failure in OPT_GenericStackManager on PPC

Discussion