This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/78166] [6/7 Regression] hash.c:1887:1: error: unrecognizable insn


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]