2007/11/13, Diego Novillo <[EMAIL PROTECTED]>: > On Nov 13, 2007 1:38 PM, Fran Baena <[EMAIL PROTECTED]> wrote: > > > 1. Convert the function into GIMPLE form. Implemented in gimplify.c > > and c-simplify.c. > > 2. Find variable references in the code. Implemented in tree-dfa.c. > > 3. Build a control-flow graph (CFG). Implemented in tree-cfg.c. > > This implementation uses the same basic_block structure used by the > > RTL optimizers. This allows us to share most of the existing CFG code. > > 4. Rewrite the tree in SSA form. Implemented in tree-ssa.c. > > [....] > > > > But i still doubt about the process, in some ways: > > > > * Is the step #2 related to the alias analysis? > > Yes, though this documentation is fairly old. Finding referenced > variables is needed to determine what symbols are of interest. > > > That is hold with the > > def-use chains, and SMT / NMT structures. And, make any sense doing > > these step before the SSA variable versioning? If positive answer, > > why? > > Sorry, I don't understand this question.
I mean that, if that structures (def-use chains, SMT, NMT, etc) are constructed before the SSA step where the program variables are versioned, after the variable versioning we will get that these structures are not congruent with the new variables generated in the mentioned step. The issue i dont understand is why alias analysis is done before the SSA pass, and, if all the structures created within these analysis are used in next optimization passes (dead code elimination, constant propagation.........) Thanks for all Fran
