On Thu, 2011-06-02 at 15:30 -0700, Steve Ellcey wrote:
On Thu, 2011-06-02 at 15:29 +0400, Alexander Monakov wrote:
Bernd,
The problem is INSN_COND should be reset when initializing a new deps
structure, otherwise instructions may get stale conditions from other
previously analyzed
Note that I am using r174594 sources with your patch *AND* with the patch
Bernd proposed for PR 48673
(http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02470.html).
So this regression may be due to the other change. I will look into it some
more to see if I can figure out which change is
On Thu, 2011-06-02 at 15:29 +0400, Alexander Monakov wrote:
Bernd,
The problem is INSN_COND should be reset when initializing a new deps
structure, otherwise instructions may get stale conditions from other
previously analyzed instructions. Presuming that sd_init_insn is the
proper place
On 31.05.2011 23:59, Andrey Belevantsev wrote:
On 31.05.2011 22:24, Steve Ellcey wrote:
Bernd,
This patch (r174336) is causing me many testsuite failures on IA64.
Tests like gcc.c-torture/compile/20010408-1.c are dying with a
seg fault in vinsn_detach.
I will look at it tomorrow. Bernd,
On Wed, 2011-06-01 at 12:18 +0400, Andrey Belevantsev wrote:
On 31.05.2011 23:59, Andrey Belevantsev wrote:
On 31.05.2011 22:24, Steve Ellcey wrote:
Bernd,
This patch (r174336) is causing me many testsuite failures on IA64.
Tests like gcc.c-torture/compile/20010408-1.c are dying with
Bernd,
This patch (r174336) is causing me many testsuite failures on IA64.
Tests like gcc.c-torture/compile/20010408-1.c are dying with a
seg fault in vinsn_detach.
#0 0x55b8760:0 in vinsn_detach (vi=0xf)
#1 0x55bda30:0 in clear_expr (expr=0x7fffeef0)
#2 0x562ea50:0 in
On 31.05.2011 22:24, Steve Ellcey wrote:
Bernd,
This patch (r174336) is causing me many testsuite failures on IA64.
Tests like gcc.c-torture/compile/20010408-1.c are dying with a
seg fault in vinsn_detach.
I will look at it tomorrow. Bernd, Steve, please let us know about any
issues with
On 05/11/2011 12:45 PM, Alexander Monakov wrote:
Could the above be conditional on whether the target CPU is exposed-pipeline?
Can do. New patch below.
I'm concerned this may degrade scheduling for other targets in some cases.
On the other hand, it may also improve scheduling. Hard to say
The scheduler knows that insns with different COND_EXEC conditions don't
conflict and can be scheduled independently. Unfortunately, sched-deps.c
does not try to keep the conditions valid as it progresses. For example,
[B0] A0 = [A1]
B0 = something
[!B0] [A2] = A0
The first and third insns
