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: [tree-ssa] COND_EXPR lowering


Hello,

> > thus getting j out of its scope.  Maybe jump threading should be testing
> > the scope when it adds the new phi entry, but since all of this scope
> > handling is (hopefully) just a temporary hack, I don't think it does
> > matter much.
> > 
> So what does it do if j isn't initialized to zero, say its something
> else which is calculated before we get to lab:
> goto label;
> 
> ...
> return;
> 
> label: ;
>   
> {
>   int j;
>   j = func ();
> 
> lab:
>   
>   j = foo (j);
> 
>   goto lab;   
> }
> 
> we end up with:
> 
> 
> goto label;
> xxx:;
> bar ();
> goto outside;
> label: ;
>  {
>   int j;
>   j_3 = func()
> lab:
>   j_1 = phi (j_3, j_2);
>   
>   j_2 = foo (j_1);
> 
>   goto lab;   
> }
> 
> what does jump threading do there? Does it elect to do nothing because
> there is a stmt between label and lab?

yes, it of course can thread over empty blocks only.

> SO presumably we only do this when the PHI argument is a constant that
> we would be replicating on the new edge? or do we replicate whatever
> variable might be there too?  I guess that seems safe as well since
> there is no code between label and lab.

yes, as long as the basic block is empty the jump threading is done.

> So it the insertion of constants/copies on these newly threaded edges
> which may now come from outside the scope that is the issue.
> 
> When we remove BIND_EXPR's, what happens to scoped things like j? Are
> they promoted to function level? If so, then yeah, this issue *should*
> just be a temporary hack :-) Whats the effect on debugging if we do
> that?

There are basically two things BIND_EXPRs are now used for:
1) Ensuring that all variable declarations are expanded.
2) Assignment of statements into scopes.

Assignment of scopes to variables is not quite related to it, as it is
done just through means of block tree (I am somehow missleadingly using
this term in connection with the hack we have now, but it in fact
just ensures that 1) works correctly).

See http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01962.html (and
preceding discussion, especially Richard Henderson's mails) for
details on how 1) and 2) are done once BIND_EXPRs are removed.

Zdenek


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