Hi Richard, > Are we actually planning to do any linker relaxations here, or is this > purely theoretical? If doing relaxations is a realistic possiblity then > I agree that would be a good/legitimate reason to use a single define_insn > for both instructions. In that case though, there should be a comment > above the define_insn explaining that linker relaxation is the reason > for keeping the instructions together.
Yes, enabling linker relaxations is a key goal of this patch - it's a chicken and egg problem since compilers split the instructions and schedule them apart for no good reason, making such relaxations impossible. It turns out that splitting early is very bad for code quality, so we can achieve smaller and faster code as well. I'll merge in the .md changes of the previous version so we don't need scheduling fusion. Cheers, Wilco
