Re: GCC hacking questions (peepholes etc.)

[Michael Meissner <meissner at cygnus dot com>]

On Wed, Jul 26, 2000 at 09:09:59AM +0200, Marek Michalkiewicz wrote:
> Hello,
> 
> I have a few questions about GCC internals (I'm hacking the AVR port,
> which is quite a learning experience, but I think these questions are
> general enough to ask here).
> 
>  - is it allowed to mix both define_peephole and define_peephole2 in
>    one md file?  The manual says define_peephole is deprecated, but
>    the AVR port currently uses it, and I see some possible optimizations
>    that would be easier done with define_peephole2 - but I'm running
>    into various strange bugs if I do it: operands that don't satisfy
>    HARD_REGNO_MODE_OK resulting in invalid asm output, abort() in
>    insn-extract.c, segfault in final.c cleanup_subreg_operands() etc.
>    (If I use -fno-peephole, or remove all define_peephole2 added,
>    everything is stable again; but just making the conditions of all
>    define_peephole2 always 0 doesn't help - this means I can't make
>    the unsafe changes optional, enabled with -m...)

No idea on this one.

>  - if the answer to the above is "no", is it possible for define_peephole
>    to request a scratch register (as documented for define_peephole2)?
>    What I'm trying to do is to optimize loading immediate constants
>    to registers - can be done directly only to r16-r31, not to r0-r15,
>    so currently there are no such alternatives in movM patterns, and
>    the constants are loaded from memory, which is expensive.  Even for
>    loading SImode constants (to 4 registers), only one QImode register
>    from r16-r31 is enough, and likely available even if 4 consecutive
>    registers (to hold SImode) are not.  (I tried secondary reload, but
>    that is not generally a win, as we unconditionally lose a register.
>    It seems better to optimize only if a scratch register is available.)
> 
>  - how to tell GCC that it is cheaper to load constants to a certain
>    register class (r16-r31) than to other registers (r0-r15)?
>    It often loads a constant to a low register (from memory) only to
>    copy it to a high register in the next insn.  Using a peephole to
>    detect this sequence (and change it so that the constant is loaded
>    to the high register, then copied to the low one) would not catch
>    cases with unrelated insns between the two - is there a better way
>    to do this?  (The CONST_COSTS macro doesn't know which register is
>    going to be loaded with the constant, which makes a big difference.)

You use the ?! constraints, see the multiple alternative constraints chapter in
the manual.  For example, lets say you use the `I' constraint for the class of
integer constants that is faster to load in the registers denoted by the `d'
register class:

	(define_insn "movsi"
	  [(set (match_operand:SI 0 "general_operand" "=r,d,?r,m,r")
	        (match_operand:SI 1 "general_operand"  "r,I, i,r,m"))]
	  ""
	  "@
	    mov %0, %1
	    fast_ldi %0, %1
	    ldi %0, %1
	    store %0, %1
	    load %0, %1")

>  - is it safe to use a constraint letter for which REG_CLASS_FROM_LETTER
>    returns either GENERAL_REGS or NO_REGS depending on target_flags, to
>    optionally enable some alternatives in a define_insn?
>    (It seems to work correctly, but I'm just making sure.)

Yes, though it will cause a slight amount of extra work.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482