On Thu, Jun 11, 2020 at 10:52 AM Martin Liška <mli...@suse.cz> wrote:
>
> On 6/9/20 3:42 PM, Richard Biener wrote:
> > I think we need to fix that before merging.
>
> There's updated version of the patch that should handle the EH properly.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

I think it would be better to avoid creating of a new edge and removing the old
by simply moving the condition stmt to the normal outgoing edge.  Thus in
expand_vector_condition do

   if (lookup_stmt_eh_lp (stmt) != 0)
     {
        maybe_clean_or_replace_eh_stmt (stmt, assign);
        gsi_remove (gsi, false);
        edge_iterator ei;
        edge e;
        FOR_EACH_EDGE (e, ei, gimple_bb (assign)->succs)
           if (e->flags & EDGE_EH)
             break;
        if (e)
          {
             gsi_remove (gsi, false);
             gsi_insert_on_edge_immediate (e, stmt);
          }
        else
           gsi_remove (gsi, true);
     }

a twist is probably the following which shows how we wrongly
make 'res' available in the catch block.  The above would
break (your variant as well) since SSA form is broken afterwards.
This of course solves itself when we not start with the broken
IL in the first place.  We could also try to "solve" this in the
SSA renamer, but then I'm not sure if gimplification doesn't
already break it.

typedef double v2df __attribute__((vector_size(16)));

v2df foo (v2df a, v2df b, v2df c, v2df d)
{
 v2df res;
  try
  {
     res = a < b ? c : d;
    return res; // replace with gcc_unreachable () for more twists
    }
    catch (...)
    {
    return res;
    }
}

So ... how far are you with enforcing a split VEC_COND_EXPR?
Thus can we avoid the above completely (even as intermediate
state)?

Thanks,
Richard.

> Thanks,
> Martin

Reply via email to