This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [JAVA PATCH] SAVE_EXPR evaluate-once semantics in jcf-write.c


Roger Sayle writes:
 > 
 > > So this ia a work-around, but the real fix is to stop
 > > generating SAVE_EXPRs while constant-folding.
 > 
 > I (mostly) disagree.  Constant folding rarely generates SAVE_EXPRs
 > and when it does they tend to be extremely useful, i.e. constant
 > folding's use of save_expr is appropriate.  The far more common
 > occurrence of SAVE_EXPR in GCJ, is the Java front-ends misguided
 > abuse of it to affect evaluation order.

Well, if we can prevent the middle end from reordering evaluations, we
won't need to generate the SAVE_EXPRs any more.

 > See my recent patch that introduced flag_evaluation_order,
 > http://gcc.gnu.org/ml/gcc-patches/2003-09/msg01882.html,

This is a useful improvement, and should allow us to simplify the
front end.

 > prior to which the java front-end was calling save_expr for almost
 > every binary operator!  It still calls save_expr for most function
 > arguments!

 > > What we should do is use a "let expression":
 > >
 > > LET tmp := expression IN f(use tmp, use tmp)
 > >
 > > This provides an explicit well-defined scope for the temporary.
 > 
 > As mentioned above, this may be a good idea.

Yes, indeed.  This does seem to be more civilized than SAVE_EXPR.

 > I'll let the GIMPLE folks argue of the merits of allowing a form of
 > SCOPE_EXPR within expressions.

I would have thought that expanding an inline function generates
something similar.

 > To conclude, this patch is certainly not a workaround.  Whenever
 > generate_bytecode_insns encounters a SAVE_EXPR it has to ensure
 > that its only ever evaluated once.  Those are the semantics of
 > SAVE_EXPR.  Even if we eventually manage to remove/replace all
 > SAVE_EXPRs from the tree, the SAVE_EXPR case of this switch either
 > needs the implementation proposed by my patch or to call abort.
 > The current scheme of silently generating bad code is "right out".

True.  I'm minded to accept this patch, but I'll defer to Per.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]