This is the mail archive of the 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:
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.

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?

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.

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 with more details). Any ideas on how to do that better are welcome.

New file was just easier/cleaner -- any suggestions on where to put the stuff?

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 :)

add_partitioned_vars_to_ptset and record_stack_var_partition_for look
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.

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.

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.

*************** ptr_deref_may_alias_decl_p (tree ptr, tr
*** 172,181 ****
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 ----
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.

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.


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