Hi again,
i have been studing gcc docs to undestand SSA and steps to take to get
SSA form. In one GCC online document:
http://gcc.gnu.org/projects/tree-ssa/#ssa, the steps to translate to
SSA form are listed. Here, i copy and paste the mentioned text:
[....]
Conversion to SSA form is a three step process driven from tree-optimize.c:
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? 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?
Thanks in advance
Fran.
2007/10/26, Diego Novillo <[EMAIL PROTECTED]>:
> On 10/26/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>
> > What is the matter if the 'b' var. is unused and
> > optimally removed by the SSA algorithm?
>
> In this case, it will not be removed. If any of the p_i pointers is
> ever dereferenced in this code, that will be considered a use of
> variable 'b'.
>
>
> > int a;
> > int b;
> >
> > a = 2;
> > p_4 = phi(a)
>
> Is this 'phi' as in a PHI function or a function in your code? If the
> former, then it's wrong, you can never have such a phi function in
> this code snippet.
>
> > // b doesn't used here
> > if (...)
> > p_1 = &a;
> > else
> > p_2 = &b;
> > endif
> > p_3 = phi (p_1, p_2)
> >
> > points-to (p_1) = { a }
> > points-to (p_2) = { b }
> > points-to (p_3) = { a b }
> >
> > In this case, should exist hidden p_5 = phi(b) although 'b' is not used
> > but yes used his reference to phantom cell 'b'. It's weird for me.
>
> I recommend that you read about the SSA form. PHI nodes are special
> constructs that exist only where multiple control flow paths reach a
> common join node. The getting started section of the wiki has links
> to books and articles about it. Morgan's book on compiler
> optimization is fairly good.
>
> > I've not idea WHERE put "hidden p_5 = phi(b)"!
>
> No such thing exists.
>
>
> > Too it's possible to ocurr *p_2 = c where 'b' will be hidden used through
> > the pointer p_2. It's too weird for me.
>
> Yes, that is possible, an that is precisely what alias analysis tells
> the compiler. We know from the analysis that reading/writing to
> '*p_2' is exactly the same as reading/writing to 'b'.
>
