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

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 the logic.

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 propagation pass.

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.

--
Marc Glisse

Reply via email to