This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Roberto COSTA <roberto dot costa at st dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, Roger Sayle <roger at eyesopen dot com>, Ian Lance Taylor <ian at airs dot com>, Andrew MacLeod <amacleod at redhat dot com>, GCC patches mailing list <gcc-patches at gcc dot gnu dot org>, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Date: Mon, 27 Nov 2006 09:59:21 -0500
- Subject: Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes
- References: <45644716.6050701@redhat.com> <20061122132938.GA3683@atrey.karlin.mff.cuni.cz> <456ABF4D.4070905@st.com>
Roberto COSTA wrote on 11/27/06 05:34:
then, as a write-after-approval maintainer, I formally request the
approval to check in the patch.
The mere act of submitting a patch implies a formal request for approval.
Two different opinions do not imply consensus. I'm inclined to agree
with Zdenek, but I also wonder whether the savings are significant to
justify the added complexity sprinkled everywhere we need to support
COND_EXPRs.
Why is this better than just converting the IFs when needed? Similarly,
if we are going to support lval = COND_EXPR, are we *always* emitting
them? If the memory savings are significant, then I would argue that we
need to always emit them and make sure that all passes know how to deal
with them.
Would you be interested in gathering some stats so that we have
something concrete to argue with?