https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Matthew Malcomson from comment #29) > I've been working on a patch that does very similar to the draft patch posted > above, and I notice a few things I've tried to avoid in it. > I doubt there are any actual bugs, since I don't know if the patterns that > trigger actual faults can occur at the moment. > > -------- > > Using the `address_operand` predicate and 'p' constraint to ensure the > address > is a valid address would use the mode SImode of the operand rather than > checking > it's valid for the DImode of the emitted ldrd. Sure, but does it really matter? This is a post reload pattern created by the peephole2s, so nothing that can be matched out of the blue sky like combiner normally matches. So, if it didn't pass the conditions in the peephole2s, the patterns wouldn't be created. Are there any addresses that pass arm_legitimate_address_p (DImode, x, true) and fail address_operand (x, SImode)? From brief skimming I couldn't find anything. So, would you be happy if the && arm_legitimate_address_p (DImode, XEXP (operands[n], 0), true) condition is added to the insn conditions (after the rtx_equal_p check)? > There's a similar problem to the `address_operand` one above with using the > `arm_count_output_move_double_insns` function. > > It's called on the original operands, which means it eventually calls > `output_move_double` with the first two operands (which are in SImode). > > This function has some calls to `reg_overlap_mentioned_p`, which depends on > the > number of hard registers for a given registers mode. > > I've only found cases where the `arm_count_output_move_double_insns` function > returns something other than what it should in cases that only match because > of > the `address_operand` problem above. > > This could be replaced by a wrapper that generates DImode registers > specifically > for checking this. For non-vfp or iwmmxt, the length is always 8, are there cases in the vfp insn that the length is not 8? > I think generation of patterns of the form > (plus:SI (plus:SI (reg) (const_int)) (const_int)) > which can happen with these peepholes isn't very nice. Why? I've done that intentionally, so that it is easy to verify it is 4 bytes appart, otherwise one needs to handle all the different cases where address is this and that etc. This whole MEM isn't an operand in the instruction, just mere RTL. Combiner doesn't run after peephole2 and if something tries to canonicalize that some way, it will simply fail to be recognized and it will not try that canonicalization.
