Re: Problem with gcc.c-torture/execute/960608-1.c on dataflow

[Roger Sayle <roger at eyesopen dot com>]

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)).

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.  I've
no idea whether we've another target-independent mechanism to inform
dataflow that a structure or some fields of it are used undefined.


This should explain why the middle-end is doing what it's doing.
As for how best to "fix" this behaviour, I'll leave to someone else.

Roger
--