------- Comment #6 from amylaar at gcc dot gnu dot org 2006-08-24 15:32 -------
(In reply to comment #5)
> > I think the only sane way to handle this is not to emit any mode
> > switching code for exception edges at the potential trapping site,
> > and make the exception handling code assume no particular mode is
> > present (unless the compiler can prove that an exception handler can only
> > be reached from throwing/trapping sites that all have the same mode).
>
> Although the mode switching code beyonds me,
I don't think the MODE_AFTER hack works - it fails to affect transparency
and anticipatability.
> how does the exception
> handling code have no particular mode at its start?
Actually, this code seems to attempt to do that already:
/* Pretend the mode is clobbered across abnormal edges. */
{
edge_iterator ei;
edge e;
FOR_EACH_EDGE (e, ei, bb->preds)
if (e->flags & EDGE_COMPLEX)
break;
if (e)
RESET_BIT (transp[bb->index], j);
}
However, this is not safe in case BB has a locally anticipatable mode.
In addition to the REST_BIT invocation, it needs:
ptr = new_seginfo (no_mode, insn, bb->index, live_now);
add_seginfo (info + bb->index, ptr);
so that we won't show an anticipatable mode.
> By calling make_preds_opaque for the corresponding BB and set
> no_mode to seginfo->mode?
No, although calling make_preds_opaque on the successor block should work,
that would be a gross pessimization.
make_preds_opaque is called when we effetively move a mode set upwards
in the flowgraph to one or more 'earliest' locations, and thus the mode
information in the mode-switchable entity becomes live on all the paths
upwards from the use of the mode to the sets of the required mode. Thus,
we know that we may not switch the mode-switchable entity to any other
mode on these paths.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
