On 12/20/18 4:41 PM, Jeff Law wrote: > On 12/20/18 2:30 PM, Peter Bergner wrote: >> For stage1, I'd like to fix that conflict wart if I can. I have also >> wondered about adding a copy coalesce phase just before we enter RA, >> which would ensure the copies are removed, instead of hoping RA assigns >> the same reg to the source and destination of the copy making it a nop >> that can be removed. > The difficulty with coalescing is that if you get too aggressive then > you end up removing degrees of freedom from the allocator and you can > easily make the final results worse.
I agree, but being too aggressive leading to bad decisions/code is true for a lot of optimizations. :-) I do plan on first attacking the conservative conflict info for pseudos first and seeing what that buys us before attempting any coalescing. As for removing degrees of freedom for the allocator, sometimes that can be a good thing, if it can makes the allocator simpler. For example, I think we have forced the allocator to do too much by not only being an RA, but being an instruction selector as well. Doing both RA and instruction selection at the same time makes everything very complicated and I think we probably don't compute allocation costs correctly, since we seem to calculate costs on a per alternative per insn basis and I don't think we ever see what the ramifications of using an alternative in one insn has on the costs of another alternative in another insn. Sometimes using the cheapest alternative in one insn and the cheapest alternative in another insn can lead us into a situation that requires spilling to resolve the conflicting choices. I've wondered if running something like lra_constraints() (but using pseudos for fixups rather than hard regs) early in the rtl passes as a pseudo instruction selection pass wouldn't make things easier for the following passes like RA, etc? Peter
