On Mon, Apr 20, 2015 at 01:11:41PM -0400, David Edelsohn wrote: > > @@ -6510,6 +6518,8 @@ offsettable_ok_by_alignment (rtx op, HOST_WIDE_INT > > return false; > > > > dsize = GET_MODE_SIZE (mode); > > + if (dsize > POWERPC64_TOC_POINTER_ALIGNMENT) > > + return false; > > Why do you immediately fail if the mode size is greater than the alignment?
The function is testing whether the address is offsettable within mode. To access components of the memory addressed, we might need to tack on an additional offset up to dsize-1 to the toc-relative offset. If the additional offset exceeds the known minimum toc pointer alignment then we might go over a n*64k+32k boundary. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810#c4 Now, if you were really asking "Why didn't you defer this test and instead take the lesser of the memory alignment and the toc pointer alignment in order to cover > But the DECL could be declared with less alignment. this case?", then the answer would be that I'm a dummy. I woke up this morning with a nagging feeling that the patch wasn't quite correct. So, given that Jakub has nixed the patch for 5.1, I may as well not rush this change. I'll spend some time first testing the linker fix and submit a better solution that has a configure test for POWERPC64_TOC_POINTER_ALIGNMENT. > VMX needs this sort of restriction, but VSX would function okay. > > Or, does the generated code assume that the offsets from the TOC are > units of the DECL size and not the TOC size? I'm not sure what you're asking here. Offsettable means we have a D-form instruction. As in the PR addis r9,r2,-2 lfd f24,32760(r9) lfd f25,-32768(r9) is bad. The patch I submitted changes this to addis r9,r2,-2 addi r9,r9,32760 lfd f24,0(r9) lfd f25,8(r9) -- Alan Modra Australia Development Lab, IBM
