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]: Patch to add component_ref ref's


On Thu, 2002-11-21 at 21:58, Diego Novillo wrote:
> On Thu, 21 Nov 2002, Daniel Berlin wrote:
> 
> > The partial defs are only necessary so that a full structure use (ie 
> > a = b, where b is a structure) gets the right reaching definition when 
> > it's fields are defined.  If one felt like teaching SSA-CCP this, and 
> > making the optimizers know this in general, you could remove the partial 
> > defs.
> > 
> You will also need to model partial uses.  See below.  In fact,
> what if we made the structure a may-alias of all its fields?
If you like.

> That way, we wouldn't have to create additional /partial
> references and could model it using the may-alias handling in the
> SSA builder.  I seem to remember discussing this with you
> privately, but I don't recall why we decided to keep the partial
> refs.

I suggested we throw them out entirely, and only create refs for the
actual component_refs, and let aliasing take care of the rest.
You never answered.
:)

> 
> > Creating the right references at the right times  under these constraints 
> > is not easy, thus, the extra argument to find_refs_in_expr.
> > The main trick cases are involving component_refs with array and 
> > indirect refs embedded in them (thus, the reason we can't just *not* 
> > recurse, instead, we have to just skip creating refs for that part).
> > 
> I'm not sure I understand this.  Could you include an example?
> 
Sure. It all comes down to CCP deciding to cutely replace a.b[5] with
a.48[5], or something like this.
Unlike that particular example (which couldn't be valid), it was a
technically valid replacement that really confused c_expand_expr. :)

I'll bootstrap removing the crap for creating partial refs, and modeling
using aliasing and paste the testcase and the problem, if it still
happens.


> > Clobbering due to union *field* assignment is not implemented right now, 
> > but it's trivial to add (In fact, if the rest of this patch is okay, I can 
> > add it before committing it).
> > 
> OK.  But the same principle as the partial refs applies.  Could
> we not make the union fields alias of each other instead of
> creating extra references?
> 
Sure.
> I've not looked at the code yet.  But consider the following
> case:
> 
> -----------------------------------------------------------------------------
>      1	struct A
>      2	{
>      3	  int a;
>      4	  int b;
>      5	};
>      6	
>      7	int foo (struct A);
>      8	
>      9	main()
>     10	{
>     11	  struct A a, b;
>     12	
>     13	  a.a = 5;
>     14	  a.b = 6;
>     15	  foo (a);
>     16	  b = a;
>     17	}
> -----------------------------------------------------------------------------
> 
> Both definitions to a.a and a.b get no uses. 

Because they have no uses. They aren't clobbered by the call unless a is
passed by reference.
They happen to may-alias a, so that the assignment to b should cause
them to stay live.
But they shouldn't have *any* actual uses in refs.
>  This is wrong
> because DCE will remove both assignments. 
>  Also, the assignment
> to a.b is clobbering a.a?  That makes no sense.
Not a problem anymore, i'm already working on the patch to model it by
aliasing.
> -----------------------------------------------------------------------------
> Variable: a.a
>     V_DEF(a.a): line 13, bb 0, id 1, a.a = 5 immediate uses:
> 
>     V_DEF/clobber(a.a): line 14, bb 0, id 3, a.b = 6 immediate uses:

> 
> Variable: a.b
>     V_DEF(a.b): line 14, bb 0, id 4, a.b = 6 immediate uses:
> -----------------------------------------------------------------------------
> 
> 
> I'm starting to think that /partial needs to disappear.  
It does. I told you it was just a waste of time and memory.
If you make it go away for array_refs, i can do component_refs without
it.

> We
> should model that with the may-alias mechanism.
> 
> Also, if you make b an alias for b.a and b.b, then the assignment
> to b at line 16 will naturally reach any uses of b.a and b.b that
> may exist after it.
> 

> 
> Diego.
-- 
Daniel Berlin <dberlin@dberlin.org>


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