On Fri, Oct 20, 2017 at 9:18 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Fri, Oct 20, 2017 at 10:12 AM, Richard Biener >> How do other targets handle this situation? Naiively I'd have handled >> the splitting at reload/LRA time ... (which would make the flag >> to test reload_completed) >> >> There are quite a number of targets using lo_sum but I'm not sure they >> share the issue with symbolic constants. > > sparc for example has in sparc_legitimate_address_p: > > /* During reload, accept the HIGH+LO_SUM construct generated by > sparc_legitimize_reload_address. */ > if (reload_in_progress > && GET_CODE (rs1) == HIGH > && XEXP (rs1, 0) == imm1) > return 1; > > and it seems that sparc_legitimize_reload_address performs the splitting > (sparc uses LRA now so this part looks dead code to me -- maybe LRA > can do this magically somehow but I see nios2 still uses reload so the > code maybe a recipie to follow).
I remember a patch to LRA to get this done with high / lo_sum targeting MIPS go in during the gcc 7 time frame which seemed to help. We've had similar issues with high and lo_sums in the Arm and AArch64 ports. Delaying splitting has helped but we've not found a case to go as fine grained as what Sandra is attempting here but that maybe something to further investigate on these ports. Ramana > > Richard. > >> Otherwise defering the splitting of course looks like the correct thing to >> do. >> >> Richard. >> >>> This patch series also includes general improvements to the cost model >>> to get better CSE results -- in particular, the nios2 backend has been >>> completely missing an implementation for TARGET_ADDRESS_COST. I also found >>> that making TARGET_LEGITIMIZE_ADDRESS smarter resulted in better >>> address cost modeling by the ivopts pass. >>> >>> All together, this resulted in about a 7% code size improvement on the >>> customer-provided test case I was using for tuning purposes. >>> >>> Patches in this set are broken down as follows: >>> >>> 1: Switch to LRA. >>> 2: Detect when splitting has been completed. >>> 3: Add splitters and recognize the new address modes. >>> 4: Cost model improvements. >>> 5: Test cases. >>> >>> Part 2 is the piece that relates to the discussion linked above. As >>> implemented, it works fine, but it's maybe not the best design. I'll >>> hold off on committing the entire set for at least a few days in case >>> somebody wants to suggest a better solution. >>> >>> -Sandra >>>