On Aug 4, 2015, Richard Biener <richard.guent...@gmail.com> wrote: > Though I wonder on whether splitting the patch into a first one with disabling > coalescing of parms (their default defs(?)) and a followup implementing the > support for that.
We can't disable coalescing of parms altogether. With -O0, we must coalesce all SSA_NAMEs referencing each parm to a single partition. With optimization, we could coalesce parms in general, just not these special cases in which the parm is to live in a caller-supplied memory block. Now, it's not coalescing parms proper that brought so much risk to the patch, it is assigning rtl to SSA partitions, and having assign_parms* use that assignment. Considering that sometimes a single param necessarily ends up in more than one partition, requiring two assignments, and that assign_parms* can't deal with that, I don't see how to easily disable the cfgexpand logic when it comes to parms, so as to be able to leave assign_parms alone. How about, if further problems arise that justify reverting the patch one more time, I'll look into splitting the patch as you suggested, but otherwise, I'll save myself the trouble, ok? > So - is my observation correct that this is only about coalescing of the > default defs of parameters, not other SSA names based on parameter decls? It's more like the opposite, i.e., we *refrain* from coalescing other SSA_NAMEs related with byref params, so that we can easily tell when a partition references a byref param and whether that partition holds its default def. We could have coalesced any other names that ended up in different partitions, and even the partition holding the default def, if we had other means to identify partitions with default defs of byref params. For example, we could create a bitmap of byref param default def versions, and then, after partitioning, map those to the partitions they were assigned to. In fact, I might do that as a followup. > Do you think this splitting is feasible and my concern about the > code-gen issues warranted? It is feasible but not exactly easy. As for codegen, I hope to have covered all cases now, but should we find out I haven't, I'll try the split and see what that gets us. Did you have any special cases in mind that it looks like I may have missed? Thanks, -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
