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 pl
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 complet
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
> 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'
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.
>>
> 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 objection
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
machine-sp
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
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 JU
> 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 R
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
f
13 matches
Mail list logo
