This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Problem with gcc.c-torture/execute/960608-1.c on dataflow
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 08 Dec 2005 09:42:54 -0500
- Subject: Re: Problem with gcc.c-torture/execute/960608-1.c on dataflow
- References: <Pine.LNX.4.44.0512072138450.14595-100000@www.eyesopen.com>
On Wed, 2005-12-07 at 21:55 -0700, Roger Sayle wrote:
> Hi Dan,
>
> On Wed, 7 Dec 2005, Daniel Berlin wrote:
> > This is *already* wrong, AFAICT, because reg:QI 58 is uninitialized, and
> > we are trying to use it's value. Why do we do this?
>
> This may have been a rhetorical question, but the middle-end's RTL
> expanders are generating uses of uninitialized registers when writing
> to bitfields of a structure that has been allocated to a register.
>
> In your example, the middle-end has decided that the struct "flags"
> should be placed in (reg:QI 58). Then when the first statement
> decides to initialize the single bit corresponding to field c to zero,
> it uses the idiom of (set (reg:QI 58) (and:QI (reg:QI 58) (const_int)))
>
> The possible fixes to this are for the middle-end to generate either
> code to initialize bitfield-containing structures when they're stored
> in registers, i.e. something like (set (reg:QI 58) (const_int 0)) at
> the start of the function, or to emit some form of nop_set or clobber
> to make it explicit that the contents of register QI:58 are initially
> undefined but may be used before becoming defined.
>
> Both of these should allow the middle-end's optimizers to do a better
> job, for example, the and's and or's to set QI:58 to a specific value
> should ideally be reduced to a single (set (reg:QI 58) (const_int foo)).
Exactly. It's not just that nothing apparently stops combine from doing
the and + or -> or transformation, it's that if we had initialized it to
0, all the and's and or's would have been constant propagated away. We
are only hurting ourselves by not emitting an explicit set *in this
case* so that it knows the initial value.
>
> The potential concern with "initialization" is that this may result
> in additional overhead, if the RTL optimizers can't determine that
> an initialization is dead when the result is unused/cobbered.
The new DCE should be able to do this in *all* cases where you've
transformed the structure into a register. If it has no uses, it has no
uses, and will go away.