You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Assertion failed '!node->OperIs(GT_CALL) || (node->AsCall()->gtCallType == CT_HELPER)' during 'Optimize index checks' #91862
Since [000064] doesn't have the GT_ASG side-effect flag, we hit this assert. The comment says that we should be considering the side-effect of GT_CALLregardless of them_flags` passed, but code doesn't seem to be behaving that way.
Since [000064] doesn't have the GT_ASG side-effect flag, we hit this assert.
It does have GTF_ASG in your dump (A flag). I guess the caller is optRemoveRangeCheck that is trying to extract just GTF_ASG, which seems odd. I would assume it should extract all side effects, since it will otherwise discard some side effects (like exception throws or calls here).
It looks like in this case we are looking at GetElement(x, y & 5), which creates a bounds check that (y & 5) < 8. We are able to prove that this bounds check always passes, but y involves the call that needs to be extracted.
I'm not sure why we wouldn't see the same issue with regular array indexing, like for example x[M() % x.Length] or x[M() & 5] for a x with a known array length, might be worth to check that out.
I'm not sure why we wouldn't see the same issue with regular array indexing, like for example x[M() % x.Length] or x[M() & 5] for a x with a known array length, might be worth to check that out.
Looks like fgMorphIndexAddr always spills complex indexing expressions to a new local, so that's why we don't see it for normal indexing. We don't see it for Span indexing because even if the result is discarded, we still end up with a pattern that blocks forward sub.
Activity
kunalspathak commentedon Sep 11, 2023
We tend to extract the side-effect for
[000064]for the flagGT_ASG:Since
[000064]doesn't have the GT_ASG side-effect flag, we hit this assert. The comment says that we should be considering the side-effect of GT_CALLregardless of them_flags` passed, but code doesn't seem to be behaving that way.runtime/src/coreclr/jit/gentree.cpp
Lines 16780 to 16783 in f18d6b6
jakobbotsch commentedon Sep 11, 2023
It does have
GTF_ASGin your dump (A flag). I guess the caller isoptRemoveRangeCheckthat is trying to extract justGTF_ASG, which seems odd. I would assume it should extract all side effects, since it will otherwise discard some side effects (like exception throws or calls here).It looks like in this case we are looking at
GetElement(x, y & 5), which creates a bounds check that(y & 5) < 8. We are able to prove that this bounds check always passes, butyinvolves the call that needs to be extracted.I'm not sure why we wouldn't see the same issue with regular array indexing, like for example
x[M() % x.Length]orx[M() & 5]for axwith a known array length, might be worth to check that out.jakobbotsch commentedon Sep 11, 2023
Looks like
fgMorphIndexAddralways spills complex indexing expressions to a new local, so that's why we don't see it for normal indexing. We don't see it forSpanindexing because even if the result is discarded, we still end up with a pattern that blocks forward sub.BruceForstall commentedon Sep 13, 2023
@jakobbotsch Can you take this one?
JIT: Extract all side effects of the index in optRemoveRangeCheck (#9…
JIT: Extract all side effects of the index in optRemoveRangeCheck
JIT: Extract all side effects of the index in optRemoveRangeCheck (#9…