[Mono-dev] [PATCH] Initial (bad) attempt at making MonoInst.klass always meaningfu
massi at ximian.com
Thu Oct 6 10:02:55 EDT 2005
this code is needed by type based alias analysis.
In this kind of analysis we need to know as precisely as possible
the class of every managed pointer that refers to an object (those
referring to value types are not relevant here).
In our IR, this kind of info is stored in the "klass" field of the
However, this info is not properly maintained in the JIT.
This patch is an attempt to make that field accurate.
I am not ready to commit it because it has some problems, and I'm
seeking comments especially on the "FIXMEMASSI" issues.
One issue is really a trouble for me, and it is the one for which
(in debugging) I duplicated the "type_from_stack_type" function,
and introduced a silly "type_from_stack_type_safe" variant (which
in fact is just the original, unmodified "type_from_stack_type").
In my patch I just wanted to modify the "type_from_stack_type"
function, making it more explicit in case of "STACK_OBJ" values.
This appeared to work, but introduced subtle regressions when
inlining was activated.
I tried to track the issue down, and verified that the problem is
related to the "MonoInst"s laying on the evaluation stack and
used as arguments when inlining.
Somehow, their "klass" is not OK, and when "type_from_stack_type"
uses it very strange things happen, which generally generate
failures in some g_assert (not the same in different tests).
The idea is that the generated IR is illegal, or corrupted, but
I still did not debug this fully (there are too many places in the
code that put "MonoInst"s on the evaluation stack).
What I *did* verify (and could be a clue to those who know more
than me) is that reverting my change in exactly two places (the
ones that now call the silly "type_from_stack_type_safe" function)
fully eliminates the regressions.
Please, those who have clues, share them ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5097 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20051006/e2bca727/attachment.bin
More information about the Mono-devel-list