(replying to both messages)
On Fri, 24 Oct 2014, Jeff Law wrote:
[ https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01830.html ]
So I'm still trying to get comfortable with this patch. I guess my concerns
about having one of the undefined value SSA_NAMEs appearing in two
conflicting coalesce lists are alleviated by the twiddle to
coalesce_partitions where we essentially ignore them.
So in the end, they don't end up a part of any partition?
Without the liveness patch, their lifetime should mean that they don't
coalesce with anything. But I would expect they get their own partition
then (I am forgetting these details way too fast...). With the liveness
patch which gives them an empty lifetime, they should all coalesce with at
least one other ssa_name.
What happens when we expand them? I guess they get a new pseudo since
they're a distinct partition? If we had a sensible story for expansion,
then I could probably get on board with this patch.
As I mentioned in my message, I don't know. Last time I looked I couldn't
find how coalescing was actually performed. tree-outof-ssa.c has a
function rewrite_trees with a promising comment but an empty body :-/
I agree that we need to understand what happens at expansion time when the
variables are not coalesced before pushing a patch that prevents
coalescing. I was kind of hoping someone would have a pointer...
On Fri, 24 Oct 2014, Jeff Law wrote:
[ https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01787.html ]
On 10/17/14 14:41, Marc Glisse wrote:
Thinking about it some more, I don't think we should need any kind of
DCE here. The rewriting in update_ssa already does a form of forward
propagation that avoids generating dead assignments, the problem only
occurs if we explicitly introduce this new assignment. So I believe we
should go back to an earlier version, like the attached, which is less
work for the compiler.
And now I can go re-read the old discussion (apparently I should avoid
gsi_replace, and there may be other ways to handle the coalescing).
I'm starting to agree -- a later message indicated you wanted to drop the
unlink_stmt_vdef call and you wanted to avoid gsi_replace, that seems fine.
I'll approve once those things are taken care of.
I don't really want to avoid gsi_replace, but I am willing to do it if it
makes reviewers nervous to call such a high-level function in the cleanup
code between passes (Richard in particular was unhappy about it).
To clarify things so I know what to test and re-post, we are talking
about the patch in
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01787.html and we can forget
about the coalescing thing in
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01830.html ?
(I'd be happy with that :-)
Thanks,
--
Marc Glisse
