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