On Sun, Jun 19, 2011 at 10:03 AM, Alan Modra <amo...@gmail.com> wrote: > I was alerted to a problem with large toc (-mcmodel=medium/large) code > a few days ago by warnings emitted during a binutils build. > > dwarf.c: In function 'display_debug_lines_raw': > dwarf.c:2409:1: note: non-delegitimized UNSPEC UNSPEC_TOCREL (44) found in > variable location > dwarf.c:2409:1: note: non-delegitimized UNSPEC UNSPEC_TOCREL (44) found in > variable location > > On investigating why this was happening, I found that these UNSPECs > were from the high part calculation of a toc-relative address that > didn't get a register. reload allocated the pseudo to a stack slot.. > The stack slot didn't match the tight pattern in delegitimize_address > which is why we have an UNSPEC left in the debug info. The real > problem of course is that reload should never allocate a stack slot > for a simple address calculation that can be rematerialised anywhere > in the function with just one instruction. So after quite a bit of > digging around in reload, I finally figured out that the problem has a > really easy solution. Simply tell reload that those high part address > calculations are constants. Which is true. > > That's what the create_TOC_reference change, and the rs6000.md changes > below do. (I also fix large-toc tls patterns.) The rest of the patch > just adjusts for the changed RTL. > > Bootstrap and regression tests powerpc64-linux in progress. OK to > apply mainline and 4.6 assuming no regressions? > > * config/rs6000/rs6000.c (create_TOC_reference): Wrap high part > of toc-relative address in CONST. > (rs6000_delegitimize_address): Recognize changed address. > (rs6000_legitimize_reload_address): Likewise. > (rs6000_emit_move): Don't force these constants to memory. > * config/rs6000/rs6000.md (tls_gd, tls_gd_high): Wrap high part of > toc-relative address in CONST. > (tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high): Likewise. > (tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewise.
Okay. Thanks, David
