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
