This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reload question about unmet constraints

> I see.  Is it correct then to say that reload will never be able to
> change a near mem into a far mem or vice versa?  If that is true, there
> doesn't appear to be any real benefit to having both near and far mem
> operations as *alternatives* to the same insn pattern.

The RL78 has a segment register, much like the x86.  The segment
register allows you to have a 20-bit address instead of a 16-bit
address.  However, due to details of the port, you can only have *one*
segment register override per operation, even if it applies to more
than one (identical) operand.  So, you can add two near pointers, but
you can't add two different far pointers, but you can add something to
a far pointer (i.e. x += 5).

> In that case, you might be able to fix the bug by splitting the
> offending insns into two patterns, one only handling near mems
> and one handling one far mems, where the near/far-ness of the mem
> is verified by the *predicate* and not the constraints.

But this means that when reload needs to, it moves far mems into
registers, which changes which insn is matched...  It also adds a
*lot* of new patterns, since any of the three operands can be far, and
'0' constraints on far are allowed also - and most insns allow far
this way, so could be up to seven times as many patterns.

You can see why I'd rather not do that :-)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]