JIT: see if jmp offset will fit in 32 bit displacement #25348
Conversation
On x86 we can always reach any IAT_PVALUE entry via a 32 bit indirect jump, and proper handling of jmp epilogs depends on this. So check if the target address is reachable in 32 bits, and if so, use the jmp [addr] form on x86, and the jmp [rip + disp] form for x64. Fixes #25345 Fixes #25346 Undoes the assertion change from dotnet#25302 Fixes #25286
|
@BruceForstall PTAL I sometimes forget x86 is full of special cases. We can't safely have a two instructions sequence for the terminal jmp on x86, and we don't need to, as 32 bits is enough to branch anywhere we need to go. |
BruceForstall
left a comment
There was a problem hiding this comment.
Did you see any asm diffs? I presume there is a fallback path where the VM will retry the compilation (without reloc hint of IMAGE_REL_BASED_REL32) if we fail to fit this during emission.
LGTM
|
Yes, x64 will first try and use a 32 bit displacement, and this may trigger a retry. So this will impact x64 codegen. It is a bit tricky to run PMI diffs on this currently -- I need to update jit-diff and friends to let us diff Tier0 code (which is where we'll see these IAT_PVALUE entries when jitting). But I can diff individual test runs (likely more useful here anyways, as |
…r#25348) On x86 we can always reach any IAT_PVALUE entry via a 32 bit indirect jump, and proper handling of jmp epilogs depends on this. So check if the target address is reachable in 32 bits, and if so, use the jmp [addr] form on x86, and the jmp [rip + disp] form for x64. Fixes dotnet/coreclr#25345 Fixes dotnet/coreclr#25346 Undoes the assertion change from dotnet/coreclr#25302 Fixes dotnet/coreclr#25286 Commit migrated from dotnet/coreclr@bad8d91
On x86 we can always reach any IAT_PVALUE entry via a 32 bit indirect
jump, and proper handling of jmp epilogs depends on this. So check if the
target address is reachable in 32 bits, and if so, use the jmp [addr] form
on x86, and the jmp [rip + disp] form for x64.
Fixes #25345
Fixes #25346
Undoes the assertion change from #25302
Fixes #25286