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


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 progress, too.

- 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.


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