https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- ...to be more specific: TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P explains the function of the hook from the perspective of someone who is implementing a register allocator, but there is no explanation whether it is a good idea (or even required) to implement it for some specific target. What form can "subst" take? When it's purpose it to avoid spills, then why not always true? (Nobody wants stills when they can be avoided). TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: How would I describe addressing capabilities for different named address-spaces? What kind of target code can I use to investigate the effect of the hook? Or can it inferred simply from the device's register layout? TARGET_SPILL_CLASS: Can't we just return GENERAL_REGS as a spill class? TARGET_COMPUTE_PRESSURE_CLASSES: Requests that we should compute pressure classes. Now I know everything about it ...kidding. Again it's from the perspective of someone who is writing a register allocator, but of no use for someone who has to provide an implementation. TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Similar issue. TARGET_REGISTER_PRIORITY: When some registers are preferred over others and hence we give them a higher priority, might that lead to more MOVs or spills? Finally: Who will fix fallout like ICEs (spill fails), performance issues, etc? Just reporting them here as PR will likely not help much, because AVR is ternary and hence any PR has priority P4 or less. For example, Newlib dropped AVR support because nobody did fix all the spill fail ICEs when building Newlib for AVR. lra just perform 2 rounds, and when it doesn't find an allocation it just bails out with spill fail ICE.
