This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] [alias, middle-end] Alias and data dependency export
On Wed, 20 May 2009, Andrey Belevantsev wrote:
> Richard Guenther wrote:
> > Instead of saving the ESCAPED/CALLUSED solutions (where is the latter?)
> > please move them to struct function instead so they persist.
> Callused is not used by the oracle (no?), so I didn't touch it.
It's used by the stmt_* interfaces. But keeping gimple_df intact
makes my point moot anyway.
> > In addition to adjusting the points-to sets wrt stack partitions you need
> > to make sure that all variables in a stack partitions have the same
> > TREE_ADDRESSABLE setting (thus, if one is addressable all should be
> > marked so).
> Isn't the hunk in union_stack_vars enough for that?
Hm, maybe. If partitioned vars are replaced by an INDIRECT_REF it
shouldn't matter at all.
> > 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.
> > 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...
> New file was just easier/cleaner -- any suggestions on where to put the stuff?
Well, let's see how much we can shrink it first.
> >
> > Why do you need MEM_ORIG_EXPR? Is using MEM_EXPR not enough? Why?
> That comes from first version of the patch. It was done simply to avoid
> touching all disambiguating logic that relies on MEM_EXPR. If you want, I can
> go for this after I fix all the remaining stuff. I hoped though that this can
> be done as a followup :)
Heh. Adding MEM_ORIG_EXPR also touches many places (I don't really see
the fundamental difference between them).
> > add_partitioned_vars_to_ptset and record_stack_var_partition_for look
> > redundant.
> The former came from fixing a miscompile, we disambiguated because of no
> DECL_UID in the pt-set (there was an UID of other variable that got the same
> stack slot, of course). I don't quite understand what you mean by the latter.
Both IOR points-to solution bitmaps. I would have expected to see code
doing
for (i=1; i < num_ssa_names; ++i)
{
tree name = ssa_name (i);
if (name && POINTER_TYPE_P (TREE_TYPE (name)))
{
EXECUTE_IF_AND_IN_BITMAP (bitmap-of-partitioned-vars,
points-to-set-of-name, ..., i)
bitmap_set_bit (tmp, partition-leader-of-i);
EXECUTE_IF_SET_IN_BITMAP (tmp, ... j)
bitmap_ior_into (temp, pt-vars-of-j);
pt-vars-of-name = temp;
}
}
(pseudocode)
at a single place, and once for escaped and callused.
> > It would be nice to have data-dependence export as a separate patch.
> > IMHO we should always export points-to information.
> I will do that after fixing the rest.
Thanks.
> > I don't like the way you handle stack partitions wrt replacing
> > ref bases with the partition representative. A more scalable
> > and correct (wrt TBAA) way would be to replace the bases
> > with an INDIRECT_REF of a new pointer that you would assign
> > a points-to set to covering all members of the partition.
> > That should simplify the points-to set adjustments as well.
> I can do that, too.
I think this and keeping the SSA names will be the most useful
cleanups.
> > *************** ptr_deref_may_alias_decl_p (tree ptr, tr
> > *** 172,181 ****
> > || TREE_CODE (ptr) == INTEGER_CST)
> > return true;
> > ! gcc_assert (TREE_CODE (ptr) == SSA_NAME
> > ! && (TREE_CODE (decl) == VAR_DECL
> > ! || TREE_CODE (decl) == PARM_DECL
> > ! || TREE_CODE (decl) == RESULT_DECL));
> > /* Non-aliased variables can not be pointed to. */
> > if (!may_be_aliased (decl))
> > --- 180,190 ----
> > || TREE_CODE (ptr) == INTEGER_CST)
> > return true;
> > ! gcc_assert ((TREE_CODE (ptr) == SSA_NAME
> > ! && (TREE_CODE (decl) == VAR_DECL
> > ! || TREE_CODE (decl) == PARM_DECL
> > ! || TREE_CODE (decl) == RESULT_DECL))
> > ! || current_ir_type () != IR_GIMPLE);
> >
> > why that? This and later changes should be not necessary if you
> > simply kept SSA_NAMEs around?
> Well, I'm not sure, as this would not change the type of trees that I give to
> the oracle, so I'd presumably see the same ICEs that resulted in this and
> similar hunks. I will recheck what was the tree that caused this, I don't
> remember offhand.
The asserts are there because the oracle doesn't handle anything else
correctly, so accepting anything for !gimple IR seems odd.
> > I would suggest to simply move delete_tree_ssa to after we finished
> > assembling the functions. That also makes moving the escaped/callused
> > solutions to struct function unnecessary.
> I'm fine with this, I was just worrying about memory use.
As we have only one function in RTL form at a time I do not worry
about this at all.
Richard.