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
> 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 really
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 ba
> 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 () && rl78_far_
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 m
> 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 r
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
> is verified by the *pr
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 reloading the address
> > into
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 base register ...
>
> If
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 operand, but
> > I c
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 that's sufficient
> 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
memor
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, but ...
Reload cho
> 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
>
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 an
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
===
--- gcc/config/rl78/rl78-
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)
+++ gcc/confi
Steve Ellcey schrieb:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128
I was wondering if anyone could help me out with a mips target bug
involving debug info and register allocation / reload.
The initial problem was that when bootstrapping on a mips linux
box I got a compare failure with tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128
I was wondering if anyone could help me out with a mips target bug
involving debug info and register allocation / reload.
The initial problem was that when bootstrapping on a mips linux
box I got a compare failure with tree-data-ref.o, I have sin
Hello all,
I was making some modifications to picochip port and ran into a problem
with cse within reload and I think it is a bug. Can someone familiar
with reload let me know if it is indeed a bug. The c testcase that
caused the problem was
gcc-4.6.0/gcc/testsuite/./gcc.c-torture/execute/9912
Quoting Alex Turjan :
When Im compiling a loop with high register pressure the register
allocator does not allocate a register for the loop counter (i.e.,
operand 0) as it has a long life range. Thus operand 0 has to be
reloaded but then I get a failure in the reload:
...
Can anybody g
On 06/23/10 12:29, Alex Turjan wrote:
insns which branch are not allowed to have output
reloads. You must
support any kind of register as well as memory operands in
your insn for
the loop counter.
Thanks for answer but what do you suggest to do, as my architecture done not
support HW
> insns which branch are not allowed to have output
> reloads. You must
> support any kind of register as well as memory operands in
> your insn for
> the loop counter.
Thanks for answer but what do you suggest to do, as my architecture done not
support HW loops with memory operands?
Alex
On 06/23/10 11:22, Alex Turjan wrote:
Hi,
My port supports hardware loops generated by the following (do_end) pattern:
(set (pc) (if_then_else (ne (match_operand:HI 0 "general_register_operand" "d")
(const_int 0))
(label_ref (match_operand 1 ""
Hi,
My port supports hardware loops generated by the following (do_end) pattern:
(set (pc) (if_then_else (ne (match_operand:HI 0 "general_register_operand" "d")
(const_int 0))
(label_ref (match_operand 1 "" ""))
(pc)))
"Amker.Cheng" writes:
> Hi:
> as to page http://gcc.gnu.org/ml/gcc/2010-05/msg00091.html,
> If the fpu register can not copied to/from memory directly, I have
> to use intermediate GPR registers.
>
> In fact, I return GP_REGS if copying x to a register in class FP_REGS
> in any mode(including CC
Hi:
as to page http://gcc.gnu.org/ml/gcc/2010-05/msg00091.html,
If the fpu register can not copied to/from memory directly, I have
to use intermediate GPR registers.
In fact, I return GP_REGS if copying x to a register in class FP_REGS
in any mode(including CCmode), this results in infinite recu
Hi,
I'm developing a gcc based compiler and in a certain scenario I get the
following reload crash:
"error: unable to find a register to spill in class 'AB_REGS'"
I looked into it and it looks like it happens when all the AB_REGS registers
are taken as function arguments, and the prefered class
Pat Haugen <[EMAIL PROTECTED]> writes:
> I was thinking of reordering the if tests such that we check if op0 is
> already ok_for_base or op1 is ok_for_index before we check the inverse
> conditions (which result in swapping the classes of the operands). I would
> also change the default else leg s
Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 08/10/2007 07:17:21 PM:
>
> I'm not entirely clear: how do you propose changing the code?
>
I was thinking of reordering the if tests such that we check if op0 is
already ok_for_base or op1 is ok_for_index before we check the inverse
conditions (which
Pat Haugen wrote:
Is this being done on purpose (going on assumption that operands are
commutative), such as to allow more opportunities for a successful
allocation with reduced spill?
I think so, but reordering the "else if"s should improve the results.
I've also seen the same situation come
Pat Haugen <[EMAIL PROTECTED]> writes:
> I'm looking into a few cases where we're still getting the base/index
> operand ordering wrong on PowerPC for an indexed load/store instruction,
> even after the PTR_PLUS merge and fix for PR28690. One of the cases I
> observed was caused by reload picking
I'm looking into a few cases where we're still getting the base/index
operand ordering wrong on PowerPC for an indexed load/store instruction,
even after the PTR_PLUS merge and fix for PR28690. One of the cases I
observed was caused by reload picking r0 to use for the base reg opnd as a
result of
Ian Lance Taylor writes:
> I agree that gcc is not well designed to cope with an accumulator
> architecture. Reload can't cope.
I've had a fair amount of success with the approach I initially posted
(perturbing the emission order of reloads based on dependencies between
the operand they are asso
Look at the IP2K port. It's an 8-bit chip with a 16 bit accumulator
and VERY limited
registers and addressing. When I did this port originally, I mostlyh
hid the accumulator
from the register allocator. But I did implement extended precision
arithmetic as a pattern that
optimized use of the a
<[EMAIL PROTECTED]> writes:
> It will generate a lot of redundant moves to/from the accumulator because
> the accumulator is exposed much too late.
>
> Consider the 3AC code:
>
> add i,j,k
> add k,l,m
>
> it will be broken down into:
>
> mov i,a
> add j,a
> mov a,k
> mov k,a
> add l,a
> mov a,
On 22 Mar 2005, Ian Lance Taylor wrote:
> Miles Bader <[EMAIL PROTECTED]> writes:
>
> > I've defined SECONDARY_*_RELOAD_CLASS (and PREFERRED_* to try to help
> > things along), and am now running into more understandable reload
> > problems: "unable to find a register to spill in class" :-/
> >
Miles Bader <[EMAIL PROTECTED]> writes:
> I've defined SECONDARY_*_RELOAD_CLASS (and PREFERRED_* to try to help
> things along), and am now running into more understandable reload
> problems: "unable to find a register to spill in class" :-/
>
> The problem, as I understand, is that reload does
BTW, if anybody replies, could you keep me in the CC: header?
I do read this list, but it won't be convenient in the next few days.
Thanks,
-Miles
--
.Numeric stability is probably not all that important when you're guessing.
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Reload insns aren't themselves reloaded. You should look at the
> SECONDARY_*_RELOAD_CLASS; they'll probably let you do what you want.
Ah, thank you!
I've defined SECONDARY_*_RELOAD_CLASS (and PREFERRED_* to try to help
things along), and am now runni
Miles Bader wrote:
Say I've got a mov instruction that only works via an accumulator A, and
a two-operand add instruction. "r" regclass includes regs A,X,Y, and
"a" regclass only includes reg A.
So mov has constraints like: 0 = "g,a" 1 = "a,gi"
and add3 has constraints: 0 = "r" 1 = "0"
Hi,
I'm writing a new gcc port, and having problems making reload work.
Say I've got a mov instruction that only works via an accumulator A, and
a two-operand add instruction. "r" regclass includes regs A,X,Y, and
"a" regclass only includes reg A.
So mov has constraints like: 0 = "g,a" 1 = "
42 matches
Mail list logo
