TREE_NOTHROW regression introduced by gimple patches?

Richard Guenther rguenther@suse.de
Wed Mar 11 15:37:00 GMT 2009


On Wed, 11 Mar 2009, Richard Guenther wrote:

> On Wed, 11 Mar 2009, Ulrich Weigand wrote:
> 
> > Hi Richard,
> > 
> > in debugging an exception handling problem on the SPU I ran across an
> > (unrelated) difference between code generated for 4.3 and 4.4 that seems
> > to have been introduced by the patches to use the gimple data type.
> > 
> > The problem is that on the tree level, there are two potential locations
> > for the TREE_NOTRHOW bit:
> > 
> >  - on a FUNCTION_DECL to indicate that *no* call to this function throws
> >  - on a CALL_EXPR to indicate that *this* specific call does not throw
> > 
> > The latter is used e.g. by the C++ front-end in do_end_catch to mark
> > certain, but not all, calls to __cxa_end_catch as non-throwing.
> > 
> > However, on transformation into the gimple data type, it would appear
> > that the TREE_NOTHROW bit on CALL_EXPRs is simply ignored.  When
> > translating back out of gimple, the TREE_NOTHROW bit on CALL_EXPRs
> > is always *set* simply according to the bit on the FUNCTION_DECL of
> > the called function.
> > 
> > This causes the no-throw information on __cxa_end_catch calls to be
> > lost, and they are all considered potentially throwing.  This causes
> > additional exception regions (and associated code) to be generated.
> > 
> > Shouldn't the transformation into gimple preserve the TREE_NOTHROW
> > bit on CALL_EXPRs, just like other CALL_EXPR bits are preserved?
> 
> Yes, though there is no bit reserved for this in gimple_statement_base
> but instead the call flags are all looked up from the decl.  This
> was probably an oversight during tuplification...
> 
> On alias-improvements branch we have a spare bit, on trunk you
> may investigate whether nontemporal_move could be overloaded
> (it seems to be only used for GIMPLE_ASSIGN, though of course a call
> also may have a store which means this could be possibly a bug
> of tuplification as well, though likely only in pretty obscure
> cases).

I just noticed we use subcode for flags and there's many left.  See
GF_CALL_* in gimple.h.

Richard.



More information about the Gcc-patches mailing list