This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gcc 3.1 performance regressions with respect to 2.95.3


Hi,

On Thu, 25 Apr 2002, David Edelsohn wrote:

> 	Sigh^2.  The open-coded no-conflict block does not work as a
> normal no-conflict block.  This algorithm probably is not strictly a word
> at a time, so no-conflict causes optimization errors down the line.

Hmm, how unfortunate.  Then probably letting the clobber stick to the
following insn, is the easiest way.  OTOH this was the block in question:

(insn 204 201 206 (clobber (reg/v:DI 124)) -1 (nil) (nil))

(insn 206 204 207 (set (subreg:SI (reg/v:DI 124) 4)
    (plus:SI (subreg:SI (reg:DI 182) 4)
             (const_int -2147483648 [0xffffffff80000000]))) 36
  {*addsi3_internal1} (insn_list 201 (insn_list 204 (nil))) (nil))

(insn 208 207 210 (set (reg:SI 185)
    (ltu:SI (subreg:SI (reg/v:DI 124) 4)
            (subreg:SI (reg:DI 182) 4))) 436
  {*rs6000.md:11929} (insn_list 206 (nil)) (nil))

(insn 210 208 212 (set (subreg:SI (reg/v:DI 124) 0)
    (plus:SI (subreg:SI (reg:DI 182) 0)
             (const_int -1 [0xffffffffffffffff]))) 36
  {*addsi3_internal1} (nil)
    (expr_list:REG_DEAD (reg:DI 182) (nil)))

(insn 214 212 221 (set (subreg:SI (reg/v:DI 124) 0)
    (plus:SI (reg:SI 185)
             (subreg:SI (reg/v:DI 124) 0))) 36
  {*addsi3_internal1} (insn_list 210 (insn_list 208 (nil)))
    (expr_list:REG_DEAD (reg:SI 185) (nil)))

This indeed has not the form of a REG_NOCONFLICT block, as insn 208 sets a
completely different pseudo 185.  Attaching a REG_NOCONFLICT note for reg
182 to it would be wrong.  Double-hmm.  If only the scheduler would track
the data flow correctly.

I feel that moving the free-standing clobber to the begin of the region is
a bug in the data-flow sense, even if it's zero-cost suggests that.
After all the uses of the (subreg (reg 124))  instantiate a liverange,
which ends at that clobber.  In this data-flow sense it's equivalent to a
(set (reg 124) 0), which also wouldn't be moved before the other set's and
uses of 124.  I mean, the scheduler does take such things into account,
or?  The different live-ranges for reg 124 all conflict, if they overlap,
so the scheduler can't simply mix them.

> 	I guess one other question is why the target REG is re-used
> instead of a new pseudo generated.  That also would prevent the DEAD notes
> from disappearing.

Yes, but this fixes only the symptom, not the bug, the scheduler should be
able to cope with this.  Although for this particular case it might be
enough.  As it's anyway open-coded, it can also simply produce a new
pseudo.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]