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

2009-01-29 Thread 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.ang...@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.ang...@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.ang...@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

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

2009-01-28 Thread 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=17196action=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

2009-01-28 Thread 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

2009-01-28 Thread 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=gccview=revrev=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

2009-01-28 Thread 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

2009-01-28 Thread 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

2009-01-25 Thread 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

2009-01-25 Thread 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

2009-01-23 Thread 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

2009-01-18 Thread 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=17138action=view)


-- 


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

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

2009-01-17 Thread 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  in3 [%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  in3 [%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  in3 [%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

2009-01-12 Thread 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

2009-01-12 Thread 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

2009-01-07 Thread 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