[M3devel] narrow still failing..
Rodney M. Bates
rodney_bates at lcwb.coop
Thu Jan 23 16:25:59 CET 2014
On 01/22/2014 02:47 PM, mika at async.caltech.edu wrote:
> Aha so declaring the type as <: ROOT will probably work as a workaround?
I'm not sure whether that would do it or not. In my pared-down case, I had
moved BDD.T and BDD.Root into main, but left the REFANY variables. That made
the failures go away.
Until it is fixed, I think the best workaround is TYPECASE with a binding:
OF BDD.T(b) =>
This is known to be working now. You've probably thought about this, but
this way requires only a single runtime type test. Either TYPECASE without
the binding of b, or ISTYPE, will require an additional recheck of the same
thing when the narrow, implicit or explicit, happens. I doubt even a
pretty good optimizing compiler could remove this. For ISTYPE, it would have
to know that the runtime routine (e.g. CheckIsType) was a pure function. Pretty
unlikely. Even worse for TYPECASE, where it would have to know a lot about the
relation between CheckIsType and ScanTypecase.
> Thank you for looking into this.
> "Rodney M. Bates" writes:
>> Some more info:
>> The front end is generating incorrect narrow code, only
>> where the type T is an unrevealed <: REFANY. When T and Root
>> are known, it calls RTHooks.CheckIsType for ISTYPE, NARROW,
>> and implicit narrow in an assignment.
>> When opaque, for explicit and implicit narrow, it simply compares
>> the typecode of x to a single typecode (no doubt for T) and demands
>> they be equal. In this case, the actual allocated type of x is Root,
>> a proper subtype of T.
>> For ISTYPE, it does call CheckIsType even when the types are opaque.
>> The fact that it happens only when the types are opaque lends
>> credibility to the fact that this bug has gone unnoticed at least
>> as far back as PM3.
More information about the M3devel