Follow-on work for IP2State table improvements

[sivadeilra]

As requested in review for #144745, this issue tracks further improvements for how exception-handling tables for Windows are handled on AMD64.

Specifically:

• Can NOP padding be avoided in more situations? There is some discussion of whether UEFI should or should not use NOP padding.
• Can we use INT3 instead of NOP when we know that a CALL is for a no-return function? This information is a little harder to get at the MachineFunction level, so it may require propagating more information.
• Can we avoid NOP padding when a CALL is before an SEH epilogue but the CALL is within a null region? Null regions don't require any cleanup, so the NOP can be avoided.

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: None (sivadeilra)

As requested in review for #144745, this issue tracks further improvements for how exception-handling tables for Windows are handled on AMD64.

Specifically:

• Can NOP padding be avoided in more situations? There is some discussion of whether UEFI should or should not use NOP padding.
• Can we use INT3 instead of NOP when we know that a CALL is for a no-return function? This information is a little harder to get at the MachineFunction level, so it may require propagating more information.
• Can we avoid NOP padding when a CALL is before an SEH epilogue but the CALL is within a null region? Null regions don't require any cleanup, so the NOP can be avoided.