This is the mail archive of the 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: IPA merge part 1: localize SSA variables

Jan Hubicka wrote on 10/21/06 15:42:

I took same path as with localizing CFG some time ago by adding cfun->ssa
structure and using accestor macros.  This avoids need to rewrite all
apperances of the variables in the sources. At time of merging CFG we discussed
plan to replace those by direct references to cfun->cfg structure.  This part
of plan sadly never matherialized, I sent patch replacing
ENTRY_BLOCK/EXIT_BLOCK, but there didn't seem to be good time for fitting it in
(it is painful for open branches).  I can update that one too and proceed with
other cfun->cfg/cfun->ssa fields in incremental patches.

Well, I think it must be done now.  We will always have active
branches and if we keep using this excuse, the Right Thing will never
get done.

Where the polution of namespace would be really anoying, like for aliasing
info, I already took path of using direct references.  Also note that the patch

No, let's please use the accessors qualified by CFUN. That is,

s/cfun->ssa->blah/blah (cfun)/

! struct ssa GTY(()) {

I would prefer to call this 'df' or 'dataflow'.  The term SSA is more
specific and this structure contains information about dataflow in

! #define referenced_vars cfun->ssa->x_referenced_vars
! #define ssa_names cfun->ssa->x_ssa_names
! #define modified_noreturn_calls cfun->ssa->x_modified_noreturn_calls
! #define global_var cfun->ssa->x_global_var
! #define nonlocal_all cfun->ssa->x_nonlocal_all
! #define aliases_computed_p cfun->ssa->x_aliases_computed_p
! #define in_ssa_p (cfun->ssa && cfun->ssa->x_in_ssa_p)
I don't think I like this.  When doing IPA, we will likely want to
access different things at the same time.  I like the idea of
accessors, but I would prefer them to have 'cfun' as an argument:

#define referenced_vars(FN) FN->ssa->x_referenced_vars

I think there is a practical limit about how much we can worry about
other active branches.  This usage of referenced_vars, ssa_names, etc
without specifying the CFUN you are referring to is a bit troublesome.
I have been bitten by it when doing the OMP expansion code.  It's easy
to use the traditional non-parameterized names and get burnt when
operating in IPA mode.

I would much rather we just switch to parameterize all these
identifiers with CFUN.  And I mean ALL of them.

! /* FIXME: Little rewrite of tree-ssa-operands could probably make those shared
!    across all functions avoiding need to privatize them.  Envolving
!    tree-ssa-operands implementation however makes this step bit impractircal.
! */
! #define free_defs (cfun->ssa->x_free_defs)
! #define free_uses (cfun->ssa->x_free_uses)
! #define free_vuses (cfun->ssa->x_free_vuses)
! #define free_maydefs (cfun->ssa->x_free_maydefs)
! #define free_mustdefs (cfun->ssa->x_free_mustdefs)
! #define free_ssanames (cfun->ssa->x_free_ssanames)
! #define operand_memory (cfun->ssa->x_operand_memory)
! #define operand_memory_index (cfun->ssa->x_operand_memory_index)
Likewise here.  Why is it that you need to privatize these caches?  I
don't think I followed your reasoning.

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