Re: Reload pass ignores constraints. Why?

[Ian Lance Taylor <iant at google dot com>]

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.

> 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.

> greg treats the shift insn as if it was a movsi_insn. I still think
> it's not correct what is going on -- at least as far as I ungerstand
> the internals. They do not say a single word about that large
> const_int must not be expanded into insn sequences. They say an insn
> alternative was *always* safe if it allowed some kind of general
> register.

Sure, it's always safe if it allows some kind of general register, but
it is also true that the movMM insns must be able to materialize any
constant which is LEGITIMATE_CONSTANT_P, and when can_create_pseudo_p
returns false they must be able to do so without using any new
pseudo-registers.

Ian