Re: Non-optimal code generated for H8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The AVR example was interesting since it generates reasonable code.

After a few experiments I strongly believe that it is the call to __mulhi3 that stops GCC from doing CSE on the pointer expressions. If I add a fake mulhi3 insn CSE seems to do its work and just generates the address calculation once. But of course the code will not work since the instruction is not present in the hardware. I see at least three possible solutions:

1) Teach CSE to work even for calls to __mulhi3

2) Add an insn that generates the H8S mulxu.w (16x16 => 32) instruction in this case. "int" is 16-bit and the size of the struct is also small in this case.

3) Do something similar to AVR. It seems to have an mulhi3 insn that expands to a call to __mulhi3 after CSE.

Now the only problem is that I have no idea how to do any of the above;-) Any hints?

/Mikael





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux