This is the mail archive of the gcc-bugs@gcc.gnu.org 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]

[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164

--- Comment #18 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #14)
> So, forgive me, but is -DOPT supposed to be the good or the bad code?

It's the good one.  As noted in comment 12, I had that backwards in comment 6.

(In reply to Richard Biener from comment #15)
> Because "coalescing" them doesn't do anything.  copyrename coalescing
> assigns the same underlying DECL to SSA names, thus makes SSA_NAME_VAR
> the same.  But when both SSA_NAME_VARs are NULL this won't do anything.

This may be true when you look at only one pair of SSA names, but when you have
2 such candidate pairs involving one common SSA name, it can, and it does make
a difference, as described in comment 6.

(In reply to Richard Biener from comment #16)
> And as I analyzed in comment #3 we chose the now different coalescing because
> it is more profitable (to the cost analysis we perform in out-of-SSA
> coalescing).

No, we don't even *consider* the coalescing performed in the -DOPT case,
because, as noted in comment 13, the SSA names ended up with different base
names, because copyrename wouldn't give them the same base name.

(In reply to Richard Biener from comment #17)
> To add to all this - IMHO copyrename should go

That's fine with me.

> Yes, out-of-SSA coalescing could be changed to allow coalescing of SSA names
> with a user-DECL and anonymous SSA names (or SSA names with a DECL_IGNORED_P
> decl).  But that will make the conflict graph much larger(?).

Ok, I'll give that a shot tomorrow (I'll be away for the whole day today).

> might happen that we end up coalescing things in a way
> that there ends up being no DECL for a register and thus we lose in debug
> quality (not sure if we could compensate by inserting debug stmts on the
> edges to compensate for that - we couldn't do that if it requires splitting
> the edge).

I'm not concerned about that.  Any debug stmts needed to make this work will
already be in place, after the actual assignments, and after early PHI nodes. 
Sure, edge insertions might separate the copies from the debug stmts inserted
after the PHI nodes, but ultimately the bindings should take care of it.

> So to avoid wrong debug we'd have to always coalesce to an anonymous
> entity

With debug stmts, we don't care what the base names are any more.  All the info
we need (for tracked auto variables) is in the debug stmts.


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