On Tuesday 05 July 2005 20:30, Vladimir Makarov wrote:
> Andrey Belevantsev wrote:
> > Vladimir Makarov wrote:
> >> I'll look at this PR today.
> >
> > We've looked today at this issue. We think the problem is that
> > proposed patch of sched_get_condition() treats conditional jumps
> > likely to C
Andrey Belevantsev wrote:
Vladimir Makarov wrote:
I'll look at this PR today.
We've looked today at this issue. We think the problem is that
proposed patch of sched_get_condition() treats conditional jumps
likely to COND_EXECs, but it doesn't fix other places in sched-deps,
where COND_EX
On Friday 01 July 2005 01:05, Vladimir Makarov wrote:
> Andrey Belevantsev wrote:
> > Vladimir Makarov wrote:
> >> I'll look at this PR today.
> >
> > We've looked today at this issue. We think the problem is that
> > proposed patch of sched_get_condition() treats conditional jumps
> > likely to CO
On Friday 01 July 2005 01:05, Vladimir Makarov wrote:
> Andrey Belevantsev wrote:
> > Vladimir Makarov wrote:
> >> I'll look at this PR today.
> >
> > We've looked today at this issue. We think the problem is that
> > proposed patch of sched_get_condition() treats conditional jumps
> > likely to CO
Andrey Belevantsev wrote:
Vladimir Makarov wrote:
I'll look at this PR today.
We've looked today at this issue. We think the problem is that
proposed patch of sched_get_condition() treats conditional jumps
likely to COND_EXECs, but it doesn't fix other places in sched-deps,
where COND_EX
Andrey Belevantsev wrote:
We've also found that current mainline ICEs compiling the testcase with
"-O0 -fschedule-insns -fschedule-insns2".
I suspect this is a bug in ia64_reorg in ia64.c. It shouldn't be trying
to schedule during a non-optimizing compile. So the line
if (ia64_flag_schedu
Steven Bosscher wrote:
Are predicate checks free, or should there be some post-pass to
clean up this kind of useless predication?
On IA-64, predicate checks are free in terms of run-time. There is the
problem that unnecessary predicate checks might increase register
lifetimes, causing extra
On Thursday 30 June 2005 16:18, Andrey Belevantsev wrote:
> Vladimir Makarov wrote:
> > I'll look at this PR today.
>
> We've looked today at this issue. We think the problem is that proposed
> patch of sched_get_condition() treats conditional jumps likely to
> COND_EXECs, but it doesn't fix other
On Thursday 30 June 2005 16:18, Andrey Belevantsev wrote:
> We don't know reload well enough to know for sure which place should be
> fixed in reload, or maybe in update_life_info(). Is this issue worth
> opening another PR?
This is a separate PR.
Actually, I'm surprised that -O0 -fschedule-insns
On Thursday 30 June 2005 16:19, Mostafa Hagog wrote:
> Hi,
>
> Steven Bosscher <[EMAIL PROTECTED]> wrote on 30/06/2005 01:46:22:
> > Hi,
>
> [snip]
>
> > Then the ia64 machine-reorg scheduler gets to work, and it produces:
> >
> > (insn:TI 8 70 12 0 (set (reg:BI 262 p6 [353])
> > (ne:BI (re
Hi,
Steven Bosscher <[EMAIL PROTECTED]> wrote on 30/06/2005 01:46:22:
>
> Hi,
>
[snip]
> Then the ia64 machine-reorg scheduler gets to work, and it produces:
>
> (insn:TI 8 70 12 0 (set (reg:BI 262 p6 [353])
> (ne:BI (reg/v:SI 15 r15 [orig:348 b1 ] [348])
> (const_int 0 [0
Vladimir Makarov wrote:
I'll look at this PR today.
We've looked today at this issue. We think the problem is that proposed
patch of sched_get_condition() treats conditional jumps likely to
COND_EXECs, but it doesn't fix other places in sched-deps, where
COND_EXECs are considered. Maxim Kuvy
Steven Bosscher wrote:
Notice how the conditional sets of r14 and r17 in insns 9 and 10 have
been moved past insn 14, which uses these registers. Shouldn't there
be true dependencies on insns 9 and 10 for insn 14?
In theory, yes. But the scheduler (it is ebb scheduler as I understand)
fre
On Thursday 30 June 2005 12:53, Richard Earnshaw wrote:
> On Thu, 2005-06-30 at 11:22, Steven Bosscher wrote:
> > For your problem, I think the jump should just be forced somehow to
> > be the last insn in the block. You can't move things into other
> > basic blocks if you are not doing interblock
On Thu, 2005-06-30 at 11:22, Steven Bosscher wrote:
> For your problem, I think the jump should just be forced somehow to
> be the last insn in the block. You can't move things into other
> basic blocks if you are not doing interblock scheduling, after all.
> For the PR I was looking at, someone w
On Thursday 30 June 2005 11:32, Richard Earnshaw wrote:
> Hmm, certainly looks suspicious, but it's not really what the original
> bug report was about. This might be some interblock scheduling problem
> that is also triggered by the extra scheduling freedom we get with the
> disabled change.
Hm
On Wed, 2005-06-29 at 23:46, Steven Bosscher wrote:
> Hi,
>
> I have a question about the scheduler. Forgive me if I'm totally
> missing the point here, this scheduling business is not my thing ;-)
>
> Consider the following snippet that I've derived from PR17808 with a
> few hacks in the compil
On Jun 29, 2005, at 3:46 PM, Steven Bosscher wrote:
I have a question about the scheduler. Forgive me if I'm totally
missing the point here, this scheduling business is not my thing ;-)
Consider the following snippet that I've derived from PR17808 with a
few hacks in the compiler to renumber in
Hi,
I have a question about the scheduler. Forgive me if I'm totally
missing the point here, this scheduling business is not my thing ;-)
Consider the following snippet that I've derived from PR17808 with a
few hacks in the compiler to renumber insns and dump RTL with all the
dependencies befor
19 matches
Mail list logo
