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: [tuples][patch] Convert pass_fold_builtins to tuples and related fixes


On 3/13/08 2:37 PM, Bill Maddox wrote:

I made this change, though it was copied from existing code.  There are other
functions like fold_builtin_n which take the ignore argument and use
it.

Ah, yes, it's OK then.



Note that I already know that I'm dealing with an assignment, so this test
is simpler and corresponds better with the pre-tuples logic.  If you'd prefer
gimple_assign_copy_p(), I can do it that way.  The test here is an idiom that
I've frequently used, however, so there are others floating around.

Ah, good point.


I put the comment in because I was concerned that perhaps it *should* have been
used, perhaps in connection with the calls to
recompute_tree_invariant_for_add_expr().
If we are satisfied with the non-use, however, I'll gladly rip it out.

Yeah, at some point in the distant past this was useful.



Easier to call walk_gimple_op here.

Is this equivalent? It looks to me that walk_gimple_op does not visit embedded statements. The old code did this. Also, I need to take a GSI as an argument, though I can easily grab the statement for walk_gimple_op with a gsi_stmt().

Yeah, it is. It's a tiny bit faster since it knows it doesn't have to deal with a statement callback. The old code had no choice but to call walk_tree on the statement.



 > @@ -2722,6 +2722,8 @@ gimple_return_set_retval (gimple gs, tre
 >  {
 >    GIMPLE_CHECK (gs, GIMPLE_RETURN);
 >    gcc_assert (gs->with_ops.num_ops == 1);
 > +  /* FIXME tuples.  The check in gimple_build_return
 > +     is more restrictive.  Which one is correct?  */
 >    gcc_assert (is_gimple_operand (retval));

My bug. Change this to the gimple_build_return() check.

Done. I moved the check to gimple_return_set_retval, and gimple_build_return now gets the check when it calls gimple_return_set_retval. It is now possible to set the return value to NULL. Previously, a no-value GIMPLE_RETURN could be constructed afresh, but it was not possible to null out an existing result, as we have been able to do for GIMPLE_CALL.

Great, thanks.



Diego.



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