Re: Reload pass ignores constraints. Why?

[Georg-Johann Lay <avr at gjlay dot de>]

Ian Lance Taylor schrieb:
> Georg-Johann Lay <avr@gjlay.de> writes:
>
> > > that--if LEGITIMATE_CONSTANT_P accepts 0xffffff--then you need to ensure
> > > that your movsi insn will handle 0xffffff directly, without using any
> > > pseudo-registers when can_create_pseudo_p returns false.
> > That works, of course. But I must admit that I prefer to express what
> > is going on in terms of algebra, i.e. in terms of RTL instead of
> > acting as if the core could handle the constant and just printng out
> > some asm sequencs. movsi expands constants that cannot be loaded in
> > one machine instruction to a movesi_insn and an arithmetic insn, and
> > movsi_insn therefore allows only constants that are easy to load.
>
> You shouldn't print out some asm sequence, you should make movsi a
> define_expand which emits a sequence of insns which do not require new
> pseudo-registers.  See, e.g., mips_move_integer which is called
> (indirectly) by the mov<mode> define_expand in mips.md.

Up to now, I see the following stategies:

i)   Expand to a single insn that matched by *movsi_insn:
     Bad, because not optimal and the insn output will print several
     asm statements en bloc (the movsi expander does not print
     anything, of course)

ii)  Expand into MOV+LSHIFTRT and deny the resulting const in
     *movsi_insn predicate and condition:
     Bad, because it crashes reload (as we saw above)

iii) Expand into MOV+LSHIFTRT and allow the resulting const in
     *movsi_insn:
     CSE et. al. will reconstruct the original constant and
     replace MOV+LSHIFTRT with a single SET:
     Bad: expanding was in vain and we Goto i)

iv)  Expand into MOV+LSHIFTRT and remove the const from
     LEGITIMATE_CONSTANT_P:
     Bad, because constant will end up in constant pool.

v)   Expand into MOV+ADD sequence. Works(?), but
     Bad: Code bloat of 100% compared to optimum.
     Ok, I could catch it in a peep2...
     The difference is that in contrast to lshiftrt the add
     can handle the required addition without need of reloads.

vi)  Expand into MOV+LSHIFTRT and allow the constand only if
     reload_in_progress||reload_completed:
     Bad: runs into ICE
     I didn't follow this path any further. Looks too hacky.

The movMM expa
> > What I do not understand is that a MOV/ADD sequence (which covers
> > large constants) works on RTL level, whereas MOV/SHIFTRT (which is
> > more efficient in some cases) shreds global alloc. Other strategies
> > could be MOV/[AND|IOR|XOR|BSWAP...] which won't work either, though.
>
> I don't know exactly what is going on.  But it is most likely just a
> coincidence that it is failing when using SHIFTRT.  There is probably
> some way to make it fail in other ways as well.

Would state it like this: If the movMM expander expands the move into
several insns, each insn must be able to handle an alternative (which
reload might select) without needing a reload.

Georg-Johann