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

[Tobias Hartmann]

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?
>> 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?

> 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