This is the mail archive of the
mailing list for the GCC project.
Re: SRA: don't drop clobbers
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 7 Jul 2014 22:15:25 +0200 (CEST)
- Subject: Re: SRA: don't drop clobbers
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1406282350110 dot 31815 at stedding dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 02 dot 1406300119080 dot 8326 at stedding dot saclay dot inria dot fr> <CAFiYyc3VuRhVBOhELM=_X5YYBuL3X5CRdPt0WC3M+DzOaDe4nQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 11 dot 1407071121180 dot 1854 at laptop-mg dot saclay dot inria dot fr> <e27bf2ce-0d82-49ba-9d89-2f418fe473ff at email dot android dot com>
On Mon, 7 Jul 2014, Richard Biener wrote:
The main idea of these patches is that when we read from a place that
was clobbered, instead of dropping the clobber and reading what was
there before, we can use a variable with a default definition to mark
that the content is undefined. This enables both warnings and
The previous patch makes update_ssa handle replacing clobbers with
default definitions when a variable doesn't have its address taken
anymore. When SRA scalarizes, it creates a new variable and relies on
update_ssa to finish the job. So I am inserting a clobber on the new
variable so that update_ssa knows to use a default definition.
OK. But can't SRA simply replace the reads with undef SSA names when
the use is dominated by a clobber?
I guess it could, but it seems safer and much simpler to avoid duplicating
SRA creates a new variable and replaces uses of the old one by uses of the
new one. update_address_taken then handles replacing the new variable by a
bunch of SSA_NAMEs, tracking which use corresponds to which def, so it
seems natural to let it handle the clobber as well. Also, conceptually,
saying that when the full variable is clobbered the subvariable is
clobbered as well is a rather obvious operation.
Otherwise, I could create an extra variable tmp, with the same type as the
new variable, and replace the clobber by an assignment of the default
definition of tmp to the new variable. update_address_taken will then see
a regular assignment and handle it as usual (create a new SSA_NAME for
it). So instead of creating a clobber that is immediatly replaced with a
NOP, this creates an extra SSA_NAME that only disappears in the next
Handling the reads myself directly in SRA and replacing them with undef
SSA_NAMEs doesn't seem to fit well with how SRA works. It would certainly
be possible, but would require quite a bit of new code. Also, the
domination relation between the clobber and the reads is not always
obvious and may require some PHIs in between.