Re: Bug 14562 : copyrename & PRE

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2004-03-15 at 11:17, Daniel Berlin wrote:
>  On Mar 15, 2004, at 10:36 AM, Andrew MacLeod wrote:

>  Because PARM_DECL's don't have a bb_for_stmt(SSA_NAME_DEF_STMT
>  (PARM_DECL)), we special case them in PRE when it comes to seeing if
>  they are actually undefined or not.
> 
>  In reality, they should have a bb_for_stmt (SSA_NAME_DEF_STMT
>  (parm_decl)) of ENTRY_BLOCK_PTR for those live on entry, and proper
>  bb_for_stmt (SSA_NAME_DEF_STMT (parm_decl)) for others.
> 
>  People seemed to agree with this (Richard and Jeff, IIRC), i just never
>  got around to it.
> 

Yes, I agree it ought to be this way. 
>  The code in question that treats PARM_DECL special is:
> 
> 
>     /* This guards against moving around undefined variables.
>      However, PARM_DECL is special because it *IS* live on entry,
>      so it's not really undefined.  */
>         if (!defbb && TREE_CODE (SSA_NAME_VAR (use)) != PARM_DECL)
>     return true;
>         else if (!defbb && TREE_CODE (SSA_NAME_VAR (use)) == PARM_DECL)
>           return false;
>         if (dominated_by_p (CDI_DOMINATORS, bb, defbb))
>     return false;
> 
> 
>  Does copyrename make this no longer true somehow?
Did you ever make adjustments when default_def() was introduced? We have
a situation here where some versions of 'k' have default_dfef() set
because they are the incoming default value, and are live on entry.

Copy rename has in this case added a new defintion of 'k', k_29, which
although the base variable is a PARM, it does have a defined block.
>  If so, we probably should just make the bb_for_stmt (SSA_NAME_DEF_STMT
>  (PARM_DECL)) be ENTRY_BLOCK_PTR when it is approriate, and stop special
>  casing them, which is probably causing this bug.
> 

Maybe... I dont think thats this problem. But maybe it is :-)

>  This is the only place we special case PARM_DECL in all of PRE.
> 

Well, dont you try to reconstruct expressions based on the base variable
or something at some point?

We have a case where we have a PARM_DECL 'k', and there are 2 PHI nodes
in one block for K
# k<D1063>_1 = PHI <k<D1063>_29(0), k<D1063>_41(1)>;
# k<D1063>_26 = PHI <k<D1063>_2(0), k<D1063>_39(1)>;

and PRE makes one of them go away... Maybe you ought to take a quick
look at the test case, its not a very big one, and you understand PRE
far better than I.
The only transformation difference that matters (I think :-), is that
copyrename has renamed T.1_29 to be k_29.  It changed the base variable
for version 29 to 'k'. And PRE decided it should do something to it, and
appears to do something wrong.

It probably wouldn't take long for you to see what wrong. Either its
something I did about PARM_DECLs, or an assumption PRE is making, Im not
sure which.


Maybe pre has done things OK, and someone later is screwing it up, but
that fact the PRE looks at this expression now, and it didnt before
makes me suspicious :-)

Thanks

Andrew