This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Gcc 3.1 performance regressions with respect to 2.95.3
- From: law at redhat dot com
- To: Michael Matz <matzmich at cs dot tu-berlin dot de>
- Cc: David Edelsohn <dje at watson dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 28 May 2002 09:27:24 -0600
- Subject: Re: Gcc 3.1 performance regressions with respect to 2.95.3
- Reply-to: law at redhat dot com
In message <Pine.GSO.4.33.0204261010250.5325-100000@platon>, Michael Matz
writes:
> 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)))
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.
jeff