This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/63304] Aarch64 pc-relative load offset out of range
- From: "ramana at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 06 Nov 2015 19:52:37 +0000
- Subject: [Bug target/63304] Aarch64 pc-relative load offset out of range
- Auto-submitted: auto-generated
- References: <bug-63304-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #31 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Evandro from comment #30)
> The performance impact of always referring to constants as if they were far
> away is significant on targets which do not fuse ADRP and LDR together.
What happens if you split them up and schedule them appropriately ? I didn't
see any significant impact in my benchmarking on implementations that did not
implement such fusion. Where people want performance in these cases they can
well use -mpc-relative-literal-loads or -mcmodel=tiny - it's in there already.
> What's the status of the solution that evaluates the function size?
I am not working on that follow-up as I didn't see the real need for it in the
benchmarking results I was looking at. You are welcome to investigate.
> Should
> this be optionally enabled only?
It is enabled by default for -mcmodel=small and -mcmodel=large.
And no because it has been done after quite a lot of complaints from the
general user community that people are unable to build large software bases
with the compiler.
> Could the assembler be left to address this issue by
> relaxing such loads? :-P
No...