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: Minor CCP improvement and add comments to tree.h


On Wed, 2004-09-22 at 09:52, Jeffrey A Law wrote:
> On Wed, 2004-09-22 at 05:44, Diego Novillo wrote:
> > On Wed, 2004-09-22 at 00:05, Jeffrey A Law wrote:
> > 
> > > This patch updates CCP to use any recorded equivalency information
> > > in SSA_NAME_EQUIV to seed the CCP values array and at the end of CCP,
> > > we transfer any equivalences discovered by CCP into the SSA_NAME_EQUIV
> > > field as well.
> > > 
> > Why not use SSA_NAME_VALUE?  PRE uses to store value handles, CCP and
> > copy-prop (will) use it for storing constant/copies.  Adding another
> > field to tree_ssa_name doesn't seem like a good idea.
> If we're using the field to communicate equivalency information across
> passes, then every pass needs to store the same kind of data in that
> field.  So the question I would have is does SSA_NAME_VALUE record
> an equivalency in PRE or is a "value handle" something different?
> 
Actually, I now realized that the field has the wrong semantics for what
you want to do.  SSA_NAME_VALUE is supposed to be a scratch pad.  The
propagator clears it as it starts, each pass uses it to store propagated
values and substitute_and_fold() replaces SSA_NAMEs with the contents of
SSA_NAME_VALUE.

Now, why would we care if an SSA_NAME already has a constant value in
CCP?  If DOM already replaced that SSA_NAME with its constant value,
then CCP should not find that name in the code.  I'm confused.


Diego.


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