On Fri, Mar 27, 2015 at 03:04:05PM -0300, Alexandre Oliva wrote: > This patch reworks the out-of-ssa expander to enable coalescing of SSA > partitions that don't share the same base name. This is done only when > optimizing. > > The test we use to tell whether two partitions can be merged no longer > demands them to have the same base variable when optimizing, so they > become eligible for coalescing, as they would after copyrename. We then > compute the partitioning we'd get if all coalescible partitions were > coalesced, using this partition assignment to assign base vars numbers. > These base var numbers are then used to identify conflicts, which used > to be based on shared base vars or base types. > > We now propagate base var names during coalescing proper, only towards > the leader variable. I'm no longer sure this is still needed, but > something about handling variables and results led me this way and I > didn't revisit it. I might rework that with a later patch, or a later > revision of this patch; it would require other means to identify > partitions holding result_decls during merging, or allow that and deal > with param and result decls in a different way during expand proper. > > I had to fix two lingering bugs in order for the whole thing to work: we > perform conflict detection after abnormal coalescing, but we computed > live ranges involving only the partition leaders, so conflicts with > other names already coalesced wouldn't be detected. The other problem > was that we didn't track default defs for parms as live at entry, so > they might end up coalesced. I guess none of these problems would have > been exercised in practice, because we wouldn't even consider merging > ssa names associated with different variables. > > In the end, I verified that this fixed the codegen regression in the > PR64164 testcase, that failed to merge two partitions that could in > theory be merged, but that wasn't even considered due to differences in > the SSA var names. > > I'd agree that disregarding the var names and dropping 4 passes is too > much of a change to fix this one problem, but... it's something we > should have long tackled, and it gets this and other jobs done, so... > > Regstrapped on x86_64-linux-gnu native and on i686-pc-linux-gnu native > on x86_64, so without lto. Is this ok to install?
The patch that got committed as a result of this discussion causes a performance regression on s390[x]. Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695 Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
