On Tue, 2005-11-01 at 13:26 -0500, Diego Novillo wrote:
> We won't get perfect answers, which is fine given the nature of the
> problem.
Right.
> However, I would like, to get *consistent* answers.
Depends on how you define "consistent" :-)
> If we
> decide to re-organize the optimization pipeline, we should not be getting
> different -Wuninitialized behaviour. Perhaps that's an easier problem to
> solve. For instance, for GCC bootstraps we could ignore the warning when
> it's from "... but was later optimized away ...".
I don't think you're going to achieve this goal, unless you fall back to
just warning before the optimizers get started (and the increased false
positives that are inherent with that solution).
If you change the pipeline, you may have a case where we miss an
optimization. That in turn might cause us to not detect that a
particular edge in the CFG is not executable. That in turn may prevent
us from realizing that a particular variable which appeared
uninitialized is really initialized on all paths to its uses.
The opposite is true as well. ie, we add a new stage in the pipeline
and we determine more edges in the CFG are unexecutable or more code
is dead. Thus variables which appeared uninitialized are now either
proven always initialized, or optimized away.
If you really want answers that don't change, then you just run the
existing warning code early in the pipeline (switch controlled of
course). We see something potentially uninitialized and we warn
and forget.
If you're willing to tolerate some changes, then you have choices.
You just run the existing code as it stands today -- you get fewer false
positives. As the pipeline changes the set of false positives will
fluctuate, but hopefully over the long term the set of false positives
is generally reduced.
You run something similar to what I've suggested. The set of false
positives will fluctuate as will the set of "optimized away false
positives". However, the union of those two sets would be consistent.
So, to summarize, I think this is the complete set of viable
alternatives:
1. Status quo. Nothing changes.
2. Run the maybe uninitialized warning code earlier in the pipeline
with no other changes. Will result in more false positives, but
more consistent results.
3. Allow a user switch to determine if the maybe uninitialized code
runs early in the pipeline (more false positives, but more
consistent results), or late in the pipeline (fewer false
positives, but results fluctuate as optimizers change).
3a. Switch on with -Wuninitialized
3b. Switch off with -Wuninitialized
4. Use an approach which runs both late and early which allows us
to explicitly warn about cases where a maybe-uninitialized variable
was either eliminated or proven always initialized. A switch
controls the new warning.
4a. Switch defaults to on with -Wuninitialized
4b. Switch defaults to off with -Wuninitialized.
My favorites (in preferred order) would be 3b, 4b, and 4a.
3a and 1 are less appealing with 2 being the worst choice IMHO.
Other thoughts, opinions and comments are encouaged :-)
jeff
