[15] RFR: 8237894: CTW: C1 compilation fails with assert(x->type()->tag() == f->type()->tag()) failed: should have same type

[Jamsheed C M]

Hi Tobias,

On 17/02/2020 17:04, Tobias Hartmann wrote:
> On 17.02.20 12:08, Jamsheed C M wrote:
>> On 17/02/2020 15:17, Tobias Hartmann wrote:
>>> Why? You are matching on the tag(), shouldn't that be the same (i.e., objectTag) for super- and
>>> subtype?
>> Yes it is, that's all i can do with instruction types, if i need further distinction i may need to
>> go for exact/declared type*.
>>
>> *LoadIndexed doesn't have it saved somewhere at present.
> So why is it "awkward for subtypes" then? Could you give an example?

i meant for null object field access or indexed access, the instruction 
can match across subtypes*  and get eliminated. which can still put us 
in awkward situation if we try checking exact/declared types, which we 
normally don't do.

*(as instruction types are erased types)

>>> And given that, does your solution actually work with Object arrays?
>> Yes, as we are asserting on elem instruction type for indexed access.
> But isn't it the case that with your change, a null from an MyObject1[] load still has the same hash
> as a null from a MyObject2[] load because type()->tag() is the same? And wouldn't that still trigger
> the assert?
it wouldn't, instruction types are erased types. so sub types all would 
match
>
>> so this fix is just for suppressing asserts that i am encountering now.
> Yes, I got that. I'm just concerned that the fix has a negative impact in other cases.
>> but, if you think disabling is best idea, and bailout  inlining through nulls, i can try that.
> No, I don't think that would help. In your latest test, you are not inlining through a null receiver
> but just pass null as an argument to an inlined method. You don't want to disable that
>
> Best regards,
> Tobias