update the location of assert for REG_ZR check

[kunalspathak]

This probably got exposed with #111451 because that makes more usages of SP than FP. While loading or storing from stack with an offset, we already encode SP -> ZR, but if we have to produce the offset using reserved register, we perform add or sub to populate it. The caller already encodes REG_SP as REG_ZR, but in add/sub, we were expecting the reg2 to be SP or GPR, but later we will encode it to ZR anyway. So, I have just moved the assert to take into account of that.

Fixes: #112278

[kunalspathak]

@dotnet/jit-contrib @amanasifkhalid

[amanasifkhalid]

LGTM, thanks!

[amanasifkhalid]

Suggested change

	// reg2 can be alread encoded to zero
	// reg2 can be already encoded to zero

[kunalspathak]

ok to fix in next batch? don't want to run CI again.

[amanasifkhalid]

Sure

[jakobbotsch]

but if we have to produce the offset using reserved register, we perform add or sub to populate it

Shouldn't the code that produces the add/sub be doing encodingZRtoSP instead when encoding it? I think it would be better to keep the requirement that reg2 is never ZR, since it's not a supported possible instruction.

[kunalspathak]

but if we have to produce the offset using reserved register, we perform add or sub to populate it

Shouldn't the code that produces the add/sub be doing encodingZRtoSP instead when encoding it? I think it would be better to keep the requirement that reg2 is never ZR, since it's not a supported possible instruction.

Yeah, the emitIns_R_R_I() is a very common method and was not sure if that's the right thing to do. But this is happening in scenario where we populate base address for predicate register, so let me point fix those 2 places only.

[amanasifkhalid]

Agreed that fixing the caller seems better