Re: reload question about unmet constraints

DJ Delorie wrote: > For such constraints that are memory operands but not > define_memory_constraint, you need to use '*' to keep reload from > trying to guess a register class from them (it guesses wrong for > rl78). > > I.e. use "*Wfr" instead of "Wfr". Huh? That seems weird. It should make

Re: reload question about unmet constraints

> So in general, it's really not safe to mark a constraint that accepts > only far memory as "memory constraint" with current reload. > > Note that *not* marking the constraint as memory constraint actually > does not prevent reload from fixing up illegitimate addresses, so you > shouldn't

Re: reload question about unmet constraints

DJ Delorie wrote: > > And in fact, you should be able to decide at *expand* time which > > of the two you need for the given set of operands. > > I already check for multiple fars at expand, and force all but one of > them to registers. OK, that's good. > Somewhere before reload they get put

Re: reload question about unmet constraints

> And in fact, you should be able to decide at *expand* time which > of the two you need for the given set of operands. I already check for multiple fars at expand, and force all but one of them to registers. Somewhere before reload they get put back in. >"rl78_virt_insns_ok () &&

Re: reload question about unmet constraints

DJ Delorie wrote: > > 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

Re: reload question about unmet constraints

> You would need some way to indicate that while Y does accept a mem, > this particular mem can't be reloaded to match. We don't have a way > to do that. As a test, I added this API. It seems to work. I suppose there could be a better API where we determine if a constrain matches various

Re: reload question about unmet constraints

On Mon, Sep 14, 2015 at 11:05 PM, DJ Delorie wrote: > As a test, I added this API. It seems to work. I suppose there could > be a better API where we determine if a constrain matches various > memory spaces, then compare with the memory space of the operand, but > I can't prove

Re: reload question about unmet constraints

On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand wrote: > But the only difference between define_memory_constraint and a plain > define_constraint is just that define_memory_constraint guarantees > that any memory operand can be made valid by reloading the address > into a

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

Re: reload question about unmet constraints

Jim Wilson wrote: > On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand wrote: > > But the only difference between define_memory_constraint and a plain > > define_constraint is just that define_memory_constraint guarantees > > that any memory operand can be made valid by

Re: reload question about unmet constraints

On Tue, Sep 15, 2015 at 8:53 AM, Ulrich Weigand wrote: > Jim Wilson wrote: > 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 >

Re: reload question about unmet constraints

Jim Wilson wrote: > On Mon, Sep 14, 2015 at 11:05 PM, DJ Delorie wrote: > > As a test, I added this API. It seems to work. I suppose there could > > be a better API where we determine if a constrain matches various > > memory spaces, then compare with the memory space of the

reload question about unmet constraints

Given this test case for rl78-elf: extern __far int a, b; void ffr (int x) { a = b + x; } I'm trying to use this patch: Index: gcc/config/rl78/rl78-virt.md === --- gcc/config/rl78/rl78-virt.md (revision 227360) +++

Re: reload question about unmet constraints

On Tue, Sep 1, 2015 at 6:20 PM, DJ Delorie wrote: > >> It did match the first alternative (alternative 0), but it matched the >> constraints Y/Y/m. > > It shouldn't match Y as those are for near addresses (unless it's only > matching MEM==MEM), and the ones in the insn are far,

Re: reload question about unmet constraints

> It did match the first alternative (alternative 0), but it matched the > constraints Y/Y/m. It shouldn't match Y as those are for near addresses (unless it's only matching MEM==MEM), and the ones in the insn are far, but ... > Reload doesn't have any concept of two different kinds of memory >

Re: reload question about unmet constraints

On 09/01/2015 12:44 AM, DJ Delorie wrote: > I expected gcc to see that the operation doesn't meet the constraints, > and move operands into registers to make it work (alternative 1, > "v/v/v"). It did match the first alternative (alternative 0), but it matched the constraints Y/Y/m. Operands 1

Re: reload question about unmet constraints

On 09/01/2015 01:44 AM, DJ Delorie wrote: Given this test case for rl78-elf: extern __far int a, b; void ffr (int x) { a = b + x; } I'm trying to use this patch: Index: gcc/config/rl78/rl78-virt.md === ---