This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] [alias, middle-end] Alias and data dependency export
Richard Guenther wrote:
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.
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?
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?
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.
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
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
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.