https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166
--- Comment #4 from dave.anglin at bell dot net --- On 2016-10-31 1:32 PM, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166 > > --- Comment #3 from Jeffrey A. Law <law at redhat dot com> --- > Hmm, clearly it helps to read the old thread. > > Canonicalization rules are that outside a MEM we use ASHIFT and within a MEM > we > use MULT. So recognizing the MULT seems reasonable. So presumably what's > happening is we want to reload the address expression. That means emitting > something like Currently,we allow scaled-indexed DFmode memory operands for 32-bit targets. So, the address needs reloading when the value needs loading to an integer register. We don't allow these for DImode as reloading would almost always be needed. Still, we have the shift-add instructions to handle this case, so maybe this would generate better code in the end. Probably, I changed this causing the regression. > > (set (temp) (address expression)) We could change pa_emit_move_sequence, but it's already very complex. Essentially, the stuff that you added to hppa_legitimize_address would be needed > > Which means we want to emit using the ASHIFT rather than the MULT form. Ugh. > I'm not sure teaching reload about that is wise. Let me think a bit. And, > no > LEGITIMIZE_RELOAD_ADDRESS is not the answer ;-) > Thought's what I thought. I don't know how to direct reload to generate ASHIFT instead of MULT. Adding the MULT patterns fixes the compile error. Dave