Re: [tree-ssa] Gimplifying Java

[law at redhat dot com]

In message <Pine.LNX.4.44.0306131819150.6334-100000@ops2.one-point.com>, Jeff S
turm writes:
 >On 13 Jun 2003, Diego Novillo wrote:
 >> On Fri, 2003-06-13 at 17:17, Jeff Sturm wrote:
 >> > On Fri, 13 Jun 2003, Andrew Haley wrote:
 >> > > Is this one right?  I thought the copy-in and out of the temporary was
 >> > > necessary on some architectures.
 >> >
 >> > I expected these to be equivalent.  There's still a temporary involved.
 >> > The trouble with the old code is that a VAR_DECL all by itself doesn't
 >> > appear to be a valid GIMPLE expression and causes some odd looking tree
 >> > dumps.
 >> >
 >> Does the java gimplifier generate a GIMPLE statement that is nothing but
 >> a VAR_DECL?  That is not good (and we should probably have a check to
 >> ICE early)
 >
 >It did.  I had changed the equivalent of:
 >
 >  t = {int <tmp>; <tmp> = p->a; <tmp>}
 >
 >to:
 >
 >  t = {int <tmp>; <tmp> = p->a;}
 >
 >Andrew Haley says the latter might produce different code, and I suspect
 >he's right.  The idea is to not overwrite t if deferencing p causes an
 >exception.
 >
 >That said, I'm not sure how to correctly express the former in GIMPLE,
 >without introducing another temporary.
How funny -- I was just hashing through this issue with C++ calls which
throw exceptions.  My gut is telling me that another temporary is in
order for C++.

Calls store their result into a temporary which is then copied into the
user variable.  The CALL_EXPR will end a basic block, so the CALL_EXPR
and assignment to the user variable will be in different basic blocks
and assignment to the user variable does not occur if the CALL_EXPR
throws an exception (and because of how we build the CFG the optimizers
can figure this out trivially).

jeff