On 04/14/2013 03:43 AM, Eric Botcazou wrote:
I don't recall ever working on this aspect of reorg. The obvious worry
is that with reorg moving stuff around those notes may not be valid
anymore in the general case.
Yes, in the general case I agree that's too dangerous. In this particular
case,
I don't recall ever working on this aspect of reorg. The obvious worry
is that with reorg moving stuff around those notes may not be valid
anymore in the general case.
Yes, in the general case I agree that's too dangerous. In this particular
case, i.e. backward scan only, this might be
Ah, OK, yea, it makes perfect sense now. Approved.
Thanks.
If you wanted to get ambitious, rewriting reorg.c to compute and use
dependency links to drive its candidate selection instead of the insane
tracking code it uses would be a huge step forward, both in terms of
cleanliness. It'd
On Tue, Apr 9, 2013 at 6:15 PM, Eric Botcazou wrote:
If you wanted to get ambitious, rewriting reorg.c to compute and use
dependency links to drive its candidate selection instead of the insane
tracking code it uses would be a huge step forward, both in terms of
cleanliness. It'd also help
On 04/09/2013 10:15 AM, Eric Botcazou wrote:
Yes, I agree that it's quite convoluted but, as Steven already said, rewriting
it to use a more modern framework is hard because of SEQUENCEs and, frankly, I
have neither the real incentive nor the time to start such an endeavor.
I understand
Thinking about this some more: This could be fixed by inserting a
machine-specific pass just after delayed-branch scheduling, like in
the attached patch. I think the same is possible with the dbr_schedule
call in the MIPS backend.
Eric, what do you think of this approach?
No objections on
On Fri, Apr 5, 2013 at 10:22 AM, Eric Botcazou wrote:
Thinking about this some more: This could be fixed by inserting a
machine-specific pass just after delayed-branch scheduling, like in
the attached patch. I think the same is possible with the dbr_schedule
call in the MIPS backend.
Eric,
On Tue, Apr 2, 2013 at 6:56 PM, Steven Bosscher wrote:
The SPARC back
end also calls dbr_schedule() in its machine_reorg pass to work around
errata in Atmel AT697F chips (LEON2-like, i.e. fairly new, see
r179921).
Thinking about this some more: This could be fixed by inserting a
On Tue, Apr 2, 2013 at 5:00 AM, Jeff Law wrote:
On 04/01/2013 01:47 PM, Eric Botcazou wrote:
I'm not sure what this is supposed to do. How is pat == target ever
going to be true when ANY_RETURN_P (pat) is true? Isn't target supposed
to be a CODE_LABEL or NULL? What am I missing?
The
I'm not sure what this is supposed to do. How is pat == target ever
going to be true when ANY_RETURN_P (pat) is true? Isn't target supposed
to be a CODE_LABEL or NULL? What am I missing?
The simple_return change from Bernd. The JUMP_LABEL of a JUMP_INSN is now
either a CODE_LABEL or a
On 04/01/2013 01:47 PM, Eric Botcazou wrote:
I'm not sure what this is supposed to do. How is pat == target ever
going to be true when ANY_RETURN_P (pat) is true? Isn't target supposed
to be a CODE_LABEL or NULL? What am I missing?
The simple_return change from Bernd. The JUMP_LABEL of a
On 03/25/2013 05:25 AM, Eric Botcazou wrote:
Hi,
for a private port with conditional returns and delay slots, only the simple
algorithm (fill_simple_delay_slots) is able to fill the slots. It's because
get_branch_condition just punts on conditional returns.
Fixed thusly. While I investigated
Hi,
for a private port with conditional returns and delay slots, only the simple
algorithm (fill_simple_delay_slots) is able to fill the slots. It's because
get_branch_condition just punts on conditional returns.
Fixed thusly. While I investigated this, I realized that the block of code in
13 matches
Mail list logo
