[Bug middle-end/38740] New: Incorrect delayed branch optimization

[Bug middle-end/38740] New: Incorrect delayed branch optimization

[danglin at gcc dot gnu dot org]

.L1018:
        ldi 1105,%r19
        cmpb,= %r19,%r28,.L1015
        ldw 48(%r3),%r28
        cmpb,<< %r19,%r28,.L1019
        ldi 1104,%r19

The "ldw 48(%r3),%r28" instruction placed in the delay slot of the preceding
cmpb instruction clobbers %r28 and the following cmpb fails if the first
branch is not taken.

The above code snippet is from lzma.  The compilation command is:

g++ -DHAVE_CONFIG_H -I. -I../../../../../../src/sdk/7zip/Compress/LZMA
-I../../../../..    -DCOMPRESS_MF_BT -DCOMPRESS_MF_BT4 -DCOMPRESS_MF_HC -O0
-march=2.0 -g -fdelayed-branch -MT LZMAEncoder.o -MD -MP -MF
.deps/LZMAEncoder.Tpo -S -o LZMAEncoder.s
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp -da

This is the rtl from LZMAEncoder.cpp.199r.barriers:

(insn 36 453 37
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp:381 (set (reg:SI
19 %r19 [140])
        (const_int 1105 [0x451])) 37 {*pa.md:2552} (nil))

(jump_insn 37 36 454
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp:381 (set (pc)
        (if_then_else (eq (reg:SI 28 %r28 [orig:124 D.7781 ] [124])
                (reg:SI 19 %r19 [140]))
            (label_ref 124)
            (pc))) 25 {*pa.md:1780} (nil))

(note 454 37 38 [bb 10] NOTE_INSN_BASIC_BLOCK)

(insn 38 454 39
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp:381 (set (reg:SI
19 %r19 [141])
        (const_int 1105 [0x451])) 37 {*pa.md:2552} (nil))

(jump_insn 39 38 455
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp:381 (set (pc)
        (if_then_else (gtu (reg:SI 28 %r28 [orig:124 D.7781 ] [124])
                (reg:SI 19 %r19 [141]))
            (label_ref 44)
            (pc))) 25 {*pa.md:1780} (nil))

This is the rtl from LZMAEncoder.cpp.200r.dbr:

(insn 36 453 655
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp:38
1 (set (reg:SI 19 %r19 [140])
        (const_int 1105 [0x451])) 37 {*pa.md:2552} (nil))
(insn 655 36 454
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp:381 (sequence [
            (jump_insn 37 36 126
../../../../../../src/sdk/7zip/Compress/LZMA/LZ
MAEncoder.cpp:381 (set (pc)
                    (if_then_else (eq (reg:SI 28 %r28 [orig:124 D.7781 ] [124])
                            (reg:SI 19 %r19 [140]))                       
(label_ref 124)
                        (pc))) 25 {*pa.md:1780} (expr_list:REG_BR_PRED
(const_in
t 17 [0x11])
                    (nil)))
            (insn/s 126 37 454 (set (reg/f:SI 28 %r28 [177])                   
(mem/f/c/i:SI (plus:SI (reg/f:SI 3 %r3)
                            (const_int 48 [0x30])) [0 prop+0 S4 A64])) 37
{*pa.m
d:2552} (nil))
        ]) -1 (nil))

(note 454 655 657 [bb 10] NOTE_INSN_BASIC_BLOCK)

(insn 657 454 455
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp:381 (sequence [
            (jump_insn 39 454 40
../../../../../../src/sdk/7zip/Compress/LZMA/LZMAEncoder.cpp:381 (set (pc)
                    (if_then_else (gtu (reg:SI 28 %r28 [orig:124 D.7781 ]
[124])
                            (reg:SI 19 %r19 [141]))
                        (label_ref 44)
                        (pc))) 25 {*pa.md:1780} (expr_list:REG_BR_PRED
(const_int 17 [0x11])
                    (nil)))
            (insn 40 39 455 (set (reg:SI 19 %r19 [142])
                    (const_int 1104 [0x450])) 37 {*pa.md:2552} (nil))
        ]) -1 (nil))


-- 
           Summary: Incorrect delayed branch optimization
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug middle-end/38740] Incorrect delayed branch optimization

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-06 04:27 -------
Subject: Re:   New: Incorrect delayed branch
        optimization

Attached preprocessed source.

Dave


------- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-06 04:27 -------
Created an attachment (id=17036)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17036&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug middle-end/38740] Incorrect delayed branch optimization

[ebotcazou at gcc dot gnu dot org]

------- Comment #3 from ebotcazou at gcc dot gnu dot org  2009-01-06 13:24 -------
I've seen that on the SPARC too.  Does Richard's patch in

http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00506.html

help?  If so, it is approved for mainline and 4.3 branch.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-06 13:24:44
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] Incorrect delayed branch optimization

[ebotcazou at gcc dot gnu dot org]

------- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-01-06 13:27 -------
Please fill in the "known to work" field if you can.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |rtl-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] Incorrect delayed branch optimization

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-06 14:57 -------
Subject: Re:  Incorrect delayed branch optimization

> Please fill in the "known to work" field if you can.

Unfortunately, this testcase also triggered a bug in the delayed branch
handling in the PA backend.  This was introduced in 3.4.  So, I need to
rebuild earlier versions to determine whether this problem is a regression.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] Incorrect delayed branch optimization

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-07 17:27 -------
Subject: Re:  Incorrect delayed branch optimization

> I've seen that on the SPARC too.  Does Richard's patch in
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00506.html
> 
> help?  If so, it is approved for mainline and 4.3 branch.

It didn't help.  It may have caused these fails:

FAIL: gcc.c-torture/execute/pr34415.c compilation,  -O0
FAIL: gcc.c-torture/execute/pr34415.c compilation,  -O1
FAIL: gcc.c-torture/execute/pr34415.c compilation,  -O2
FAIL: gcc.c-torture/execute/pr34415.c compilation,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/pr34415.c compilation,  -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/pr34415.c compilation,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/pr34415.c compilation,  -O3 -g
FAIL: gcc.c-torture/execute/pr34415.c compilation,  -Os

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[danglin at gcc dot gnu dot org]

------- Comment #7 from danglin at gcc dot gnu dot org  2009-01-08 04:15 -------
Oops, I see pr34415.c was part of Richard's patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[carlos at systemhalted dot org]

------- Comment #8 from carlos at systemhalted dot org  2009-01-12 15:02 -------
Dave,

I've been building parts of glibc's vfprintf code with -fno-delayed-branch for
hppa because of bugs in DBR. I never filed a bug because it was almost
impossible for me to reduce the vfprintf code (large file, large tables, long
jumps).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-12 18:01 -------
Subject: Re:  [4.4 Regression] Incorrect delayed branch optimization

> I've been building parts of glibc's vfprintf code with -fno-delayed-branch for
> hppa because of bugs in DBR. I never filed a bug because it was almost
> impossible for me to reduce the vfprintf code (large file, large tables, long
> jumps).

I would guess that this particular regression has something to do with
the new register allocator.

The general problem mentioned by Richard Sandiford

  dbr_schedule is the only user of resource.c, which is based
  on this horrible hack of assuming that, although the basic block
  information is no longer up-to-date, we can still rely on the live
  register sets before BARRIERs.  We also assume that we can rely on
  REG_DEAD notes to some extent: if a register is marked dead by a
  REG_DEAD note, and isn't set again before the next label, we assume
  it really is dead at the label.

is more serious.  The delayed branch optimisation is run at all levels.
So, the generated code may be wrong if a user doesn't specify
-fno-delayed-branch.

As this problem affects more than the PA, possibly the priority of this
report should be increased.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[danglin at gcc dot gnu dot org]

------- Comment #10 from danglin at gcc dot gnu dot org  2009-01-17 22:34 -------
This is the last output of the register usage information prior to the dbr
pass.  I am somewhat puzzled as to why register 124 doesn't appear as
allocated to %r28 in the "lr  in" and "lr  use" lines for blocks 4 and 9.

;; Start of basic block ( 4) -> 9
;; bb 9 artificial_defs: { }
;; bb 9 artificial_uses: { u-1(3){ }u-1(30){ }}
;; lr  in        3 [%r3] 30 [%r30] 124
;; lr  use       3 [%r3] 30 [%r30] 124
;; lr  def       140

;; Pred edge  4
(code_label 35 466 453 9 774 "" [1 uses])

(note 453 35 36 9 [bb 9] NOTE_INSN_BASIC_BLOCK)

(insn 36 453 37 9 LZMAEncoder.cc:3105 (set (reg:SI 19 %r19 [140])
        (const_int 1105 [0x451])) 37 {*pa.md:2552} (nil))

(jump_insn 37 36 454 9 LZMAEncoder.cc:3105 (set (pc)
        (if_then_else (eq (reg:SI 28 %r28 [orig:124 D.7781 ] [124])
                (reg:SI 19 %r19 [140]))
            (label_ref 124)
            (pc))) 25 {*pa.md:1780} (nil))
;; End of basic block 9 -> ( 25 10)
;; lr  out       3 [%r3] 30 [%r30] 124

;; Succ edge  25
;; Succ edge  10 (fallthru)

;; Start of basic block ( 9) -> 10
;; bb 10 artificial_defs: { }
;; bb 10 artificial_uses: { u-1(3){ }u-1(30){ }}
;; lr  in        3 [%r3] 30 [%r30] 124
;; lr  use       3 [%r3] 30 [%r30] 124
;; lr  def       141

;; Pred edge  9 (fallthru)
(note 454 37 38 10 [bb 10] NOTE_INSN_BASIC_BLOCK)

(insn 38 454 39 10 LZMAEncoder.cc:3105 (set (reg:SI 19 %r19 [141])
        (const_int 1105 [0x451])) 37 {*pa.md:2552} (nil))

(jump_insn 39 38 455 10 LZMAEncoder.cc:3105 (set (pc)
        (if_then_else (gtu (reg:SI 28 %r28 [orig:124 D.7781 ] [124])
                (reg:SI 19 %r19 [141]))
            (label_ref 44)
            (pc))) 25 {*pa.md:1780} (nil))
;; End of basic block 10 -> ( 13 11)
;; lr  out       3 [%r3] 30 [%r30] 124

;; Start of basic block ( 9) -> 25
;; bb 25 artificial_defs: { };; bb 25 artificial_uses: { u-1(3){ }u-1(30){ }}
;; lr  in        3 [%r3] 30 [%r30]
;; lr  use       3 [%r3] 30 [%r30]
;; lr  def       118 177 178
;; Pred edge  9
(code_label 124 482 125 25 771 "" [1 uses])
(note 125 124 126 25 [bb 25] NOTE_INSN_BASIC_BLOCK)

(insn 126 125 127 25 LZMAEncoder.cc:3128 (set (reg/f:SI 28 %r28 [177])
        (mem/f/c/i:SI (plus:SI (reg/f:SI 3 %r3)
                (const_int 48 [0x30])) [0 prop+0 S4 A64])) 37 {*pa.md:2552}
(nil
))


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-18 23:02 -------
Subject: Re:  [4.4 Regression] Incorrect
        delayed branch optimization

Attached slightly reduced testcase.

Dave


------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-18 23:02 -------
Created an attachment (id=17138)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17138&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2009-01-25 17:54 -------
Do we have a testcase for a primary platform that is affected by this bug?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[ebotcazou at gcc dot gnu dot org]

------- Comment #14 from ebotcazou at gcc dot gnu dot org  2009-01-25 18:02 -------
> Do we have a testcase for a primary platform that is affected by this bug?

FWIW I haven't seen this failure mode on the SPARC yet.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2009-01-28 13:34 -------
Created an attachment (id=17196)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17196&action=view)
PR38740.C

Simplified testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[jakub at gcc dot gnu dot org]

------- Comment #16 from jakub at gcc dot gnu dot org  2009-01-28 15:20 -------
The problem is -O0 together with -fdelayed-branch.  Shouldn't we just reject it
or silently not do dbr at !optimize?  If it is really important to support (I
don't see any rationale for it), then the problem is that ira.c only calls
df_analyze after RA if -O1 and above:
  df_finish_pass (true);
  if (optimize > 1)
    df_live_add_problem ();
  df_scan_alloc (NULL);
  df_scan_blocks ();

  if (optimize)
    df_analyze ();

  timevar_pop (TV_IRA);
}

No other -O0 pass in between ira and dbr calls df_analyze and dbr itself can't
call it, as the cfg is gone.  So, if we really want to support this, either
ira.c could
  /* -O0 -fdelayed-branch uses dataflow info during dbr pass, but uses it after
     the cfg is gone.  Ensure it is updated even in that case.  */
  if (optimize || flag_delayed_branch)
    df_analyze ();
or we could have some pass right before pass_free_cfg that would be gated on
!optimize && flag_delayed_branch and would call df_analyze ().


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[jakub at gcc dot gnu dot org]

------- Comment #18 from jakub at gcc dot gnu dot org  2009-01-28 16:06 -------
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[jakub at gcc dot gnu dot org]

------- Comment #17 from jakub at gcc dot gnu dot org  2009-01-28 16:05 -------
Subject: Bug 38740

Author: jakub
Date: Wed Jan 28 16:05:41 2009
New Revision: 143733

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143733
Log:
        PR rtl-optimization/38740
        * reorg.c (gate_handle_delay_slots): Avoid dbr scheduling
        if !optimize.
        * config/mips/mips.c (mips_reorg): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/mips/mips.c
    trunk/gcc/reorg.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[vapier at gentoo dot org]

------- Comment #19 from vapier at gentoo dot org  2009-01-28 18:20 -------
are corresponding changes needed for hppa/sparc considering this bug discussed
them originally ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[danglin at gcc dot gnu dot org]

------- Comment #20 from danglin at gcc dot gnu dot org  2009-01-29 13:05 -------
hppa just uses the generic code for delayed branch optimization.

The target problems that led to this PR were fixed in this series of
changes:

2009-01-05  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

        * pa.c (output_call): Relocate non-jump insns in the delay slot of
        long absolute calls when generating PA 2.0 code.

2009-01-09  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

        * pa.c (last_address): Change to unsigned.
        (update_total_code_bytes): Change argument to unsigned.  Don't
        check if insn addresses are set.
        (pa_output_function_epilogue): Set last_address to UINT_MAX if insn
        addresses are not set.
        (pa_asm_output_mi_thunk): Handle wrap when updating last_address.

2009-01-12  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

        * pa.c (pa_asm_output_mi_thunk): Use pc-relative branch to thunk
        function when not using named sections on targets with named sections
        if branch distance is less than 262132.

All three are installed on 4.3.3 and trunk.  Only the first, the most critical
one, is on 4.2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740