On July 7, 2014 11:32:10 AM CEST, Marc Glisse <marc.gli...@inria.fr> wrote: >On Mon, 7 Jul 2014, Richard Biener wrote: > >> On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse <marc.gli...@inria.fr> >wrote: >>> Hello, >>> >>> with this patch on top of >>> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html >>> we finally warn for the testcase of PR 60517. >>> >>> The new function is copied from init_subtree_with_zero right above. >I guess >>> it might be possible to merge them into a single function, if >desired. I >>> don't understand the debug stuff, but hopefully by keeping the >functions >>> similar enough it shouldn't be too broken. >>> >>> When we see a clobber during scalarization, instead of dropping it, >we add a >>> clobber to the new variable, which the previous patch turns into an >SSA_NAME >>> with a default def. Then either we reach uninit and warn, or the >variable >>> appears in a PHI and CCP optimizes. >> >> What's the point of a clobber of sth that was scalarized away? So >... >> can you please explain in more detail? > >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've long wanted to teach it some flow sensitivity by doing the replacements within a domwalk) Richard. >> The new function needs a comment. > >Indeed, I'll add one once the conversation on the first patch >converges. > >Thanks,
