On Mon, 13 Feb 2012, Richard Henderson wrote: > On 02/13/2012 01:35 AM, Richard Guenther wrote: > > On Fri, 10 Feb 2012, Richard Henderson wrote: > > > >> On 02/10/2012 01:44 AM, Richard Guenther wrote: > >>> What is the reason to keep a GIMPLE_TRANSACTION stmt after > >>> TM lowering and not lower it to a builtin function call? > >> > >> Because "real" optimization hasn't happened yet, and we hold > >> out hope that we'll be able to delete stuff as unreachable. > >> Especially all instances of transaction_cancel. > >> > >>> It seems the body is empty after lowering (what's the label thing?) > >> > >> The label is the transaction cancel label. > >> > >> When we finally convert GIMPLE_TRANSACTION a builtin, we'll > >> generate different code layouts with and without a cancel. > > > > Ah, I see. But wouldn't a placeholder builtin function be > > effectively the same as using a new GIMPLE stmt kind? > > Except for the whole "need to hold on to a label" thing. > > Honestly, think about that for 10 seconds and tell me that > a builtin is better than simply re-tasking the gimple code > that we already have around.
I'm only worried about passes that would need to explicitely care about new gimple codes (like the DCE case you spotted). All passes have to handle calls already - and apart from the label thingie a call would work (well, you could pass the label by reference, but that would probably make it a possible target for a computed goto ...). So, well ... I guess a new gimple code is ok (we don't want to change that now), but in general trying a little harder to avoid new kinds of gimple in the optimizer IL is always good. Richard.
