This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: tuples merge for GIMPLE_MODIFY_STMT
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com, jason at redhat dot com, pinskia at physics dot uc dot edu
- Date: Fri, 1 Dec 2006 07:40:44 -0400
- Subject: Re: RFA: tuples merge for GIMPLE_MODIFY_STMT
- References: <20061101152339.GA17409@redhat.com> <455366DF.6020805@redhat.com>
Hi Diego. Hi folks.
Sorry about the delay, but I'm now ready to address all the issues raised,
and hopefully start the merge march of death.
Diego, I have fixed everything you pointed out, with the exception of the
two (related) issues I will discuss below.
> > + /* If we re-gimplify a set to an SSA_NAME, we must change the
> > + SSA name's DEF_STMT link. */
> > + if (def_stmt_self_p)
> > + SSA_NAME_DEF_STMT (GIMPLE_STMT_OPERAND (*tp, 0)) = *tp;
> > +
> >
> But that would mean that the optimizers are generating MODIFY_EXPRs.
> Isn't this papering over something? We do allow the optimizers to
> emit non-GIMPLE code, but when they emit an assignment, it had better
> be a GIMPLE_MODIFY_STMT.
As I mentioned further in this thread, we are creating INIT_EXPRs after
gimplification in internal_get_tmp_var(). These end up as MODIFY_EXPRs
in statement annotations.
We can do one of two:
1. Leave things as they are.
2. Have internal_get_tmp_var() generate GIMPLE_MODIFY_STMT.
As pinskia has pointed out, we still perform optimizations on INIT_EXPRs,
so we will miss these. I am not overly concerned here because we are about
to convert INIT_EXPRs to MODIFY_EXPRs by this point anyhow.
Either #1 or #2 work, but perhaps Jason or you can comment?
> > + /* FIXME tuples: We need to gimplify into GIMPLE_MODIFY_STMT right
> > + away, so the helper functions below can be made to only handle
> > + GIMPLE_MODIFY_STMT's, not MODIFY_EXPR as well. */
> > +
> >
> What's needed to fix this one? I'd like to address these FIXMEs right
> away.
This FIXME turned out to be a non-issue. We can't convert to
GIMPLE_MODIFY_STMT right away, because we still want to preserve the
INIT_EXPR/{MODIFY_EXPR,GIMPLE_MODIFY_STMT} distinction this early on. So
even if we changed MODIFY_EXPRs to GIMPLE_MODIFY_STMTs early on, supporting
functions to gimplify_expr() would still need to handle INIT_EXPR with
PROTECTED_TREE_OPERAND (or GENERIC_TREE_OPERAND :)).
So... this FIXME isn't a fixme.
And that, good sirs, is hopefully it.
Aldy
p.s. There's the issue of PROTECTED_TREE_OPERAND vs GENERIC_TREE_OPERAND.
I'm testing a patch right now.