On Aug 5, 2015, Richard Biener <richard.guent...@gmail.com> wrote: > 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?
Since we only coalesce variables whose promoted mode is the same, if one of them gets BLKmode and has to live in memory, so would all the others it might coalesce with. So, even though we have gimple_regs, we can't have pseudos. This was observed with vector types for which no native vector mode is available. It would still make sense to share them when possible, to reduce the number of mem-to-mem copies. And we don't want to copy incoming BLKmode parms to *another* memory location if we can help it. Now, maybe you're concerned about incoming parms passed by reference that *can* be held in pseudos. For those, we will perform a load from memory to a pseudo and use that, even if the pseudo ends up allocated in memory. > 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. Most of what changed now is who gets to choose the pseudo; it used to be assign_parms, now it's cfgexpand. The other significant change is that now, when cfgexpand detects a BLKmode parm, it will choose MEM, but it won't set up the address, so that assign_parms still does what it used to, namely, copy the incoming hard reg to a pseudo, and then use the pseudo as the MEM address. > But I guess you have eyed code-gen changes a bit anyway. Yeah. Not much has changed in the before parm_birth area; expected changes have to do with the pseudo numbering. IIRC, anything else would be unexpected. -- 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
