jrtc27 wrote: > > Hm, what's the justification between x5-x7? Those don't seem fundamental > > like x1/x2 i.e. ra/sp? > > The linked bug shows x6. x5 is used for tail calls in msave-restore and the > outliner. x7 is used for lpad labels.
Ok, so I think we have two cases: 1. We are just lazy about register allocation, and hard-code things / don't properly reserve things when we should (PseudoTAIL falls into this category, t1 isn't required, it's just the default for the `tail` mnemonic) 2. Certain enabled extensions / enabled options / language features being compiled require specific registers (x4 for references to thread-local storage duration objects, x5 for -msave-restore, x7 for landing pads) We then have several choices to make: 1. Just make it work (only an option for case 1 above) 2. Make it fail if that feature is used (more aimed at case 2 above; whilst technically you could fail if you end up optimising to a tail call for -ffixed-x6, that seems quite bad UX) 3. Make that -ffixed-xN not exist at all, ever My primary concern is that, as new architecture and ABI comes in, more meaning gets assigned to existing registers, and if our response every time is "ok nobody gets to reserve that register anymore", that seems like a bad slippery slope, rug pull, etc. For example, if I'm not using -msave-restore, nor landing pads, why *shouldn't* I be able to continue on as before reserving registers that aren't required to not be reserved? Whilst I understand that fixing these things properly can be awkward and perhaps disproportionate effort for the potential utility, I fear this is a rather big hammer being applied to the problem. If we're not prepared to keep -ffixed-xN working in newer versions, we should just rip out all of them now other than those we truly can commit to supporting for the foreseeable future, rather than pretending to ourselves and our users that these are actual options they can use and rely on. https://github.com/llvm/llvm-project/pull/237500 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
