On Tue, Jan 26, 2021 at 3:07 AM Joern Wolfgang Rennecke <joern.renne...@riscy-ip.com> wrote: > > esirisc has a sub-target that has DImode with 4 byte alignment, and > DFmode with 8 byte alignment. For code like g++.dg/torture/pr39713.C , > the optimizes changes the mode of a MEM from DImode to DFmode even if > the required alignment is not available. > > Appended is is the target-independent part of the fix. Required target > changes were to make sure that (subreg:DF: (mem:DI ...)) is handled or > rejected as an operandad as appropriate, and a secondary reload to a > suitable register and in a suitable mode are done where needed > (GENERAL_REGS in DImode in our case).
Hmm, IIRC the mode of a mem is only relevant if there's no MEM_ATTRs (because then the default attrs of the mode apply), targets are responsible to reject MEMs they do not implement because of alignment constraints. So I wonder whether the + if (GET_MODE_ALIGNMENT (omode) > GET_MODE_ALIGNMENT (imode) + && GET_MODE_ALIGNMENT (omode) > MEM_ALIGN (x)) + goto fail; changes do not paper over either a target failure to reject built mems or the optimizers not properly recognizing the result and thus verifying validity of the generated MEM? At least the above gen_lowpart_for_combine will also inhibit the transform on DImode -> DFmode on i?86 with -malign-double? I realize the condition is unusual (and thus unlikely to trigger), but still. Richard. > Bootstrapped and regression tested in gcc version > d6f1cf644c45b76a27b6a6869dedaa030e3c7570 on x86_64 GNU/Linux.
