This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] [alias, middle-end] Alias and data dependency export
I have made some of the fixes, so more questions/RFC follow.
- delaying delete_tree_ssa until pass_clean_state just works, the loop
over gimple bbs marked with FIXME in there can be removed, and bootstrap
still works (testing is in progress now);
- relying on SSA_NAME_PTR_INFO instead of saving it separately works,
too, with the only exception of TMR_ORIGINALs, which can be of
INDIRECT_REFs to VAR_DECLs, which ICEs in oracle helpers when trying to
get points-to info. This works if I bail out from helpers when seeing
not SSA_NAME and asserting we are not in GIMPLE. Besides these changes
to the helpers, all other oracle changes are gone. Testing is in
- stack slot partition handling. Your pseudocode assumes that there is
a decl-to-partition mapping, which is not the case. The code within
record_stack_partition_for actually tries to create such mapping and
uses it when recording expressions. It would do what you want if I make
sure that we fix points-to sets once per SSA_NAME instead of once per
expressions. I agree that the part unifying points-to sets of pointers
that got partitioned into the same stack slot is unneeded though, so I
removed it. Again, testing is in progress.
Other choice would be to create and maintain such bitmaps during
partitioning process, or to build them exclusively for this task and get
rid of them afterwards; I can do either of this if it seems cleaner to
you, but currently I don't see a big difference.
- finally, rewriting bases to INDIRECT_REFs (the only major change left)
vs. MEM_EXPR/MEM_ORIG_EXPR problem. Looking at how the old MEM_EXPR
field is used, I see that the decl from it is used within var-tracking.c
(in addition to nonoverlapping_memrefs_p in alias.c), so we'd probably
spoil debug info while doing rewrite (either to base partition decl,
like now, or to INDIRECT_REF). How important is this?
Also, if I would fail making rewrite work on-the-fly with bases from
expand_stack_vars and from expand for other exprs, I'd probably need an
extra walk to see all MEMs right after expand. (Should not be too bad
as I killed one walk in delete_tree_ssa :) Or we need to delay
expanding any variables until partition info is computed.