On Fri, Jul 20, 2012 at 12:05:28AM +0930, Alan Modra wrote: > On Thu, Jul 19, 2012 at 12:34:25PM +0930, Alan Modra wrote: > > and fixes pr54009. > > David, in looking over this today, I realised that this bug isn't > completely fixed. I stopped gcc emitting an offset of 32768, but that > isn't enough. lo_sum addresses can't be offset, except when you know > the alignment of the object being addressed guarantees that no part > crosses a 32k boundary. For example, given lis 9,x@ha; lwz 3,x@l(9); > lwz 4,x+4@l(9); we run into trouble if x happens to reside at > n*64k + 32764. The final address matters, not just the offset in the > insn. So I have some changes to mem_operand_gpr and > rs6000_secondary_reload. I'll post a patch on top of the previous > one.
Actually, maybe I won't. When I disabled offsetting LO_SUMs, except for tocrefs (which we know are aligned), I ran into an "insn does not satisfy its constraints" ICE on gcc.dg/pr28795-2. The cause: code in rs6000_legitimze_reload_address near the comment starting "/* Don't do this for TFmode". There we have a list of modes from which we make assumptions about the regs used, and get it wrong for ppc32. Reload decided to use 2 gprs for a DFmode. We've been doing this forever, and almost always the mem is aligned. So fixing an esoteric testcase like the one in pr54009 would come at the expense of normal code quality. Unless I can reliably figure out regs used and alignment of syms in rs6000_legitimize_reload_address, and as far as I can tell that isn't possible. > Another thing. I reckon we can do without the 'wY' constraint. I > implemented it because movtf_internal currently uses an "o" > constraint, but it seems to me that rs6000_legitimate_address_p > already prevents non-offsettable TFmode addresses for mems accessed by > fprs. Geoff introduced the "o" on movtf here: > http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00803.html > Thoughts? This on the other hand works. Please consider the patch amended to remove mem_operand_fpr, the 'wY' constraint, and uses thereof replaced with "m". -- Alan Modra Australia Development Lab, IBM
