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 22:23:38 +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 #35 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Evandro from comment #32)
> (In reply to Ramana Radhakrishnan from comment #31)
> > (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.
>
> Because of side effects of the Haiffa scheduler, the loads now pile up, and
> the ADRPs may affect the load issue rate rather badly if not fused. At leas
> on our processor.
In straight line code I can imagine this happening - In loopy code I would have
expected the constants to be hoisted - atleast that's what I remember seeing in
my analysis. You have seen -mcprelative-literal-loads haven't you ?
>
> Which brings another point, shouldn't there be just one ADRP per BB or,
> ideally, per function? Or am I missing something?
That isn't really how this thing works. Well the constants are shared across
the program now as you say down thread.
>
> I'll investigate placing the constant after the function, as before, if the
> estimated function size allows for it. I think that eliminating the ADRPs
> could potentially be more beneficial to code size than merging constants in
> a common literal pool (v. http://bit.ly/1Ptc8nh).
I was actually surprised by the amount of constant sharing that was happening
in what I looked at.
Thanks,
Ramana