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: [RFC] [alias, middle-end] Alias and data dependency export


Richard Guenther wrote:
Why do you need replace_var_in_datarefs?  Why do you need to unshare
the exprs anyway?
Originally, that was needed for remapping MEM_ORIG_EXPR to the correct
TMR_ORIGINAL when TARGET_MEM_REF was copied, then also it was needed with
unsharing.  Unsharing was needed so the saved expressions don't get gc'd, we
have set on this to use memory only for trees that are needed.

struct mem_attrs is GCed, so that should keep a reference to the trees used there and avoid them being GCed - no?
Well, it didn't work this way when I tried, but I'm not a GC expert -- maybe I was missing a GTY or something.

As of TMR_ORIGINAL I am not sure that using points-to info for them
is safe.  I have to look at the patch again to where you get it from.
Currently TMR_ORIGINAL is translated to a MEM_EXPR, no?
Yes.

I guess we should try to make the oracle cope with the TMR directly.
The replacement function was needed for ddg export, not for alias export. The pass that gathers datarefs before iv-opts associates them with expressions that later become TMR_ORIGINALs. So replacement was needed to associate with the correct TMR_ORIGINAL when TARGET_MEM_REF got copied, I've just reused it for unsharing later.


Why do you record points-to info for exprs?  Why not simply not release
SSA names and keep the information hanging off them?  Why not adjust
points-to sets wrt partitions at the time partitioning and stack var
expansion is done?  Same for the MEM_EXPRs.  (why is it all in a new file?)
I can try going with SSA_NAMEs (I have probably forgot to do this after merge
with expand from ssa).  We cannot adjust during expansion time because
sometimes we save a tree from within expand_stack_vars, when partitioning is
not yet known (see http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00664.html
with more details).  Any ideas on how to do that better are welcome.

Hm, I don't understand the problem. The partitioning is done in one place and is fixed. So you are saying that we create mem-attrs before we do that partitioning? That sounds weird. But maybe I am missing something...
Yes, there were calls to set_mem_attributes (I believe on a VAR_DECL) before partitioning figured out that the decl will be partitioned. This is a problem for rewriting bases only. Maybe I can fix all bases right after expand_stack_vars, and then catch the rest of expressions during normal expand.

Btw, I thought that all vars that ended up in the same partition should be equivalent from TBAA point of view (same alias sets), and thus rewriting should be fine, no? But I agree that rewriting to an INDIRECT_REF is better anyways because of points-to set handling.

I will start working on fixing stuff next week.
Andrey


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