Jakub Jelinek <ja...@redhat.com> wrote:
>On Mon, Dec 30, 2013 at 05:56:04PM +0100, Richard Biener wrote:
>> Jakub Jelinek <ja...@redhat.com> wrote:
>> >Setting gimple_call_set_fndecl of a random method call to
>> >__bultin_unreachable can't work properly, the method call probably
>> >passes in arguments that __builtin_unreachable doesn't expect, and
>if
>> >the method call has LHS, we'll ICE, because __builtin_unreachable
>> >doesn't
>> >have a LHS.  Fixed by not doing anything for fold_stmt_inplace and
>> >for fold_stmt just adding a new __buitin_unreachable () call before
>the
>> >method call, DCE will DTRT then and we don't have to bother with
>adding
>> >some dummy stmt to set up the lhs etc.
>> >
>> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>> 
>> You could re-set the number of arguments and the LHS though.
>
>While we have gimple_set_num_ops, I'd find that very ugly and
>apparently
>nothing in the compiler does that for calls right now.
>
>> But with a LHS and a not dead consumer both approaches will probably
>ice.
>> You'd need to replace all uses with a default def.
>
>Also, I think it could be quite surprising if fold_stmt changed other
>stmts
>(users of lhs), plus the lhs doesn't have to be in SSA form yet.

Yes.  Also affecting other statements isn't allowed.

>One would need to also unlink vdefs and release the vdef SSA_NAME, and
>not
>sure if fold_stmt_inplace callers would be even prepared for the stmt
>to
>become noreturn, and no longer throwing, etc.

That I think they have to.  Vdef handling is done by the caller which is 
required to update_stmt and to remove eh side effects if required.

>What would be the advantages of doing all that over the posted patch?

Not sure why this transform is in fold at all rather than in a pass that 
expects this kind of control flow changes.

That said, your patch still requires all callers of statement folding to run 
control flow graph cleanup. That's undesired I think, so moving the transform 
elsewhere is better IMHO.  I suggest dce.

Richard.

>       Jakub


Reply via email to