🚀 go-pugleaf

Hi, 

I'm not having a problem, but rather want to propose some
enhancements to the GCC. It's neither a bug nor I'm needing help,
so I don't know exactly where to put my proposal. Be so
kind and send it the right box. Thanks.

1.
Some processors (like mine) have special loop instructions, similar
to load immediate and dbra. Im my case the load immediate initializes
a register that contains also the target address of the dbra 
instruction. Using this method speeds up the loop, but the
load immediate needs to be the last instruction before the
loop label. Constants that are moved out of loops are normally placed
between these instructions and disturb the insn order. Is there a way
to tie the load imm to the label or to move the constants to a place
before the loop counter init?

2.
The expression expander is able to expand mults even if there are only
smaller mults. My processor supports mulhisi3 and mulhi, for address 
calculation a signed SI mul is performed. The expander is building
correct code, but in the most common cases like indexing in an array
of HI or SI with an HI index, it produces rather ineffective code.
The expander treats the mul with the const_int 2 like a mul
with an unknown and produces code like mul Rx,0,RY (multiplication
by zero and addition by zero, shifting 2 right by 15) 
for the intermediates.

I propose to check the expansions of ALU-Ops for constants at 
RTX-Level in addition to the cse pass or at least to check the mul
sythesizing parts of the expander for such simplifications.

Further I propose to check for shifts in multiplication cases where
otherwise the multiplication would be sythesized. These muls are
not combinable to valid address expressions and don't need to be kept
as muls.

Thanks in advance
Martin