This is the mail archive of the 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

 In message <Pine.GSO.4.33.0204261010250.5325-100000@platon>, Michael Matz 
 > 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
 >   {*} (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)))
An FYI -- this code would probably benefit by using a new pseudo instead of
storing into the subreg twice.   In a lot of ways it's not unlike the code
I recently tweaked in the double-word multiply support -- storing into a subreg
like this can lead to poor code generation later -- especially if the pseudo
does not get a hard register.

 > 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.
Presumably you're talking about the subreg stores.  Yes, it would be a huge
benefit if flow/life and the schedulers properly tracked this stuff.  The
single biggest reason we have naked clobbers is avoid -Wuninitialized 
warnings when dealing with multi-word values which are assigned their
initial value in a multi-insn sequence similar to what you've shown above.

 > 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.
I think we've all agreed that the clobber should stay as close to the rest
of the sequence as possible to avoid unnecessarily extending the live range
of the pseudo.


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