Hi! On Sat, Oct 12, 2019 at 10:13:16PM +0100, Iain Sandoe wrote: > (this is a bug reported against Fortran, but actually is a generic insn > selection problem for m64 powerpc-darwin. In fact, I’d say it renders > the 64b multilib unusable). > > The solution proposed is Darwin-local (it's a long-standing bug and it > would be intended to back-port it). However, I'd welcome views on it. > > The current Darwin load/store lo_sum patterns have neither predicate nor > constraint. This means that most parts of the backend, which rely on > recog() to validate the rtx, can produce invalid combinations/selections. > > For 32bit cases this isn't a problem since we can load/store to unaligned > addresses using D-mode insns.
Can you? -m32 -mpowerpc64? We did have a bug with this before, maybe six years ago or so... Alan, do you remember? It required some assembler work IIRC. > Conversely, for 64bit instructions that use DS mode, this can manifest as > assemble errors (for an assembler that checks the LO14 relocations), or as > crashes caused by wrong offsets (or worse, wrong content for the two LSBs). Resulting in a different insn than intended. Yeah. > Trying to find the right place to fix this has been tricky, there's > discussion in the PR trail. There doesn't seem to be any way to deal with > this in legitimize_address (since most of the damage is done by the wide open > patterns that are in effect after the legitimizer has run). Likewise, > extending the checks in legitimate_address_p() and mode_dependent_address > doesn't help if the constraint is not accurate in the end. > > What we want to check for "Y" on Darwin is: > - that the alignment of the Symbols' target is sufficient for DS mode > - that the offset is suitable for DS mode. > (while looking through the Mach-O PIC unspecs). > > Proposed: > > 1) Drop the Darwin-specific lo_sum patterns. Actually, this produces an > immediate progression in quite a number of tests, we begin using the > movdi_internal64 patterns. However there are also regressions caused by > instructions unable to satisfy their constraints. And code quality regressions? Or does it even improve? (One can dream...) > 2) To resolve this we need to extend the handling of the mem_operand_gpr to > allow looking through Mach-O PIC UNSPECs in the lo_sum cases. > > - note, that rs6000_offsettable_memref_p () will not handle these so that > would return early, producing the issue with unsatisfiable constraints. > > - I do wonder if that's also the case for some non-Darwin lo_sum cases. Not sure what exactly you mean here? Non-Darwin doesn't have issues with not looking through Darwin-specific unspecs, anywhere, so you mean something more general no doubt -- but what? > (some things might be hard to detect, since the code will generally fall > back to doing " la Rx xxx@l ; ld Ry 0(Rx)" so it won't fail - just be > less efficient than it could be). Oh, you are saying mem_operand_gpr does not allow lo_sum *at all*? > + /* If we don't know the alignment of the thing to which the symbol refers, > + we assume optimistically it is "enough". > + ??? maybe we should be pessimistic instead. */ > + unsigned align = 0; If you guess it is aligned enough but it isn't, the compile will fail. Not good. OTOH, when don't we know the alignment? Only for globals? Does the ABI guarantee alignment in that case? I'll have another looke through this (esp. the generic part) when I'm fresh awake (but not before coffee!). Alan, can you have a look as well please? Segher
