[llvm] [AVR] Force relocations for jumps and calls (PR #118015)
Ben Shi via llvm-commits
llvm-commits at lists.llvm.org
Tue Dec 3 18:24:49 PST 2024
benshi001 wrote:
> > Is there a strong reason for us to strictly follow avr-gcc?
>
> No, I don't think so - I'm up for avoiding relocations as well 🙂
>
> > If you have no time for my suggested solution, I will try it later this month.
>
> I can do that, no problem - I'm just reflecting on the approach:
>
> * Option A: Create a new feature (like `RjmpWrap`) and enable it for the smaller (8 kB) microcontrollers,
> * Option B: Teach LLVM flash sizes of _all_ of the AVRs and implement logic that automatically applies the memory wrapping trick.
>
> Option A is simpler to implement, while option B (as described in the `Alternatives` approach at the top) is potentially more versatile (we'll be able to apply the wrapping trick even for larger microcontrollers, if we happen to generate a branch large enough). Note that for larger uCs this trick is just a program-size optimization, not a requirement.
>
> I'm leaning towards option B, since it feels less hacky to me, but I don't have any strong preference here - care to choose?
I prefer A to B, because:
1. It is simpler, and less code changes.
2. For larger devices, we use long `JMP`, and let the linker to do the branch relaxation.
What's more,
1. we only add this new TargetFeature to devices with larger flash but without long `JMP`. Devices with flash size less than 4KB or with long `JMP` are unnecessary.
2. Generally I prefer `force relocation`, but if the devices have a unique flash size (for example 8KB), I also accept hard coding it into `adjustRelativeBranch` and in your 'Alternatives'.
https://github.com/llvm/llvm-project/pull/118015
More information about the llvm-commits
mailing list