On Wed, Aug 5, 2015 at 2:38 AM, Alexandre Oliva <aol...@redhat.com> wrote: > 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?
Sure. >> 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? It was just a hunch when you talked about BLKmode and params in memory. As coalescing is about SSA name (thus register) coalescing I was thinking that if you coalesce a register with incoming memory you'll end up with more memory accesses? But maybe I'm completely off here. I also thought of the RTL expansion thing we do with at first copying the hardreg incoming args to pseudos and how that interacts with coalescing. But I guess you have eyed code-gen changes a bit anyway. Thanks, Richard. > 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
