This is the mail archive of the gcc@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: Problem with gcc.c-torture/execute/960608-1.c on dataflow


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.



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