On 11/7/23 17:15, Richard Sandiford wrote:
Thanks for the reviews.
Jeff Law <jeffreya...@gmail.com> writes:
On 11/5/23 11:48, Richard Sandiford wrote:
The mode-switching pass already had hooks to say what mode
an entity is in on entry to a function and what mode it must
be in on return. For SME, we also want to say what mode an
entity is guaranteed to be in on entry to an exception handler.
gcc/
* target.def (mode_switching.eh_handler): New hook.
* doc/tm.texi.in (TARGET_MODE_EH_HANDLER): New @hook.
* doc/tm.texi: Regenerate.
* mode-switching.cc (optimize_mode_switching): Use eh_handler
to get the mode on entry to an exception handler.
Can we ever have a path to the exception handler triggered by a normal
control flow and if so, presumably we want this to apply in that case too?
Not directly AFAIK. The handler has to handle the EH_DATA_REGNOs,
call __cxa_begin_catch, etc. So even if there is fall-through at
the source level, I think there'd always be a block that is only
reached through abnormal control flow. So...
It looks like that's the semantics of the implementation by way to using
bb_has_eh_pred. Just want to make sure that's the semantics you want in
that oddball case.
Assuming it is the semantics you want, it's OK for the trunk, though you
might want to twiddle the docs slightly to mention that case.
...I think these EH blocks are pure re-entry points. I suppose some
targets might have entities whose state is call-preserved, so that it's
not changed by EH edges. But that might also apply to other abnormal
control flow too, so it's probably a separate issue/feature.
OK. I wouldn't be surprised if there's state that wouldn't be correct
if we had code which jumped directly into the EH handler path. Makes me
wonder if the C++ language might actually prohibit such shenanigans.
Jeff
