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] Aliasing issues revisited


> On Sun, 2003-11-23 at 05:28, Jan Hubicka wrote:
> 
> > 	Temporary hack to save addressable flags & fixes to mustalias.
> > 	* tree-dfa.c (referenced_vars_addressable_p): New.
> > 	(add_referenced_vars): Save addressable flag.
> >	  * tree-flow.h (referenced_vars_addressable_p): Declare
> > 	* tree-ssa.c (init_tree_ssa): Initialize new referenced_vars_addressable_p.
> > 	(delete_tree_ssa): Restore addressable flags.
> > 
> I don't feel comfortable with this change.  I'd rather take the opposite
> approach.  Let's just remove the hacks we already have in must-alias and
> deal with the breakage properly.  This will only hide the problems. 
> This is what I'm working on now.
OK, please apply the dupication patch.  That one solves all sorts of
other failures related to mustalias.  I will apply it to mainline once I
finish testing.

My plan has been to remove those hacks as incremental step.  This needs
Daniel's ssa-pre fix to bootstrap i686, so I didn't included it in this
patch.  With the saving hack, Daniels patch and FIXMEs removed I was
able to properly bootstrap in the past.

Finally the expanders changes are not completely trivial to deal with -
if we want to go the correct way, we ought to kill addressof and always
put nonscalarized aggregates into memory.  This causes perfomrance loss
on architectures passing arrays/structures in registers, like x86-64 is,
as we are not able to scalarize argument set/argument load for now, se
we allocate redundant stack slot.

So this is getting involved and is reason why I would like to deal with
issues one by one, but perhaps you will find some other workable
compromise.
> 
> > 	* tree-mustalias.c (find_addressable_vars): Deal with complex addresses.
> >
> Have you added an abort() in all these cases and figured out why weren't
> these expressions folded?  For instance, we get a foldable PLUS_EXPR in

These can not be folded.  &a+10 is constant and can not be simplified.
This is all what the code is trying to deal with.  We also don't fold
&a[1] into &a+4 by design (per Richard's comment).

> c-cppbuiltin.c.  Handling complex addresses here papers over the
> problem.
> 
> > 	(promote_var): Clear may_point_to_global_mem.
> >
> This is OK.  Does it fix an existing test case.  If not, could you add
> one?
It does not fix any testcase until the FIXME code for pointers is
removed.  It is just one of reasons we can't do that.
I will test and commit this fix separately now.

Honza
> 
> 
> Diego.
> 


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