On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li <davi...@google.com> wrote: > Good point -- but why does SRA have to be so complicated? If it just > do structure expansion and let subsequent phases to clean it up, would > it be simpler? Anyway this is off the topic.
Well, it's certainly non-optimal to insert new memory backed variables to get rid of memory backed variables ... Richard. > Thanks, > > David > > > On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Mon, Jun 20, 2011 at 6:15 PM, Xinliang David Li <davi...@google.com> >> wrote: >>> It is used to indicate the fact the var decl needs to have a memory >>> home (addressable) -- is there another way to do this? this is to >>> avoid the following situation: >>> >>> 1) after SRA before update SSA, the IR looks like: >>> >>> MEM[.... &SR_123] = ... >>> >>> other_var = SR_123; <---- (x) >>> >>> >>> In this case, SR_123 is not of aggregate type, and it is not >>> addressable, update_ssa won't assign a VUSE for (x), leading to >> >> The point is, SRA should never have created the above >> >> MEM[.... &SR_123] = ... >> >> Martin, why would it even create new _memory_ backed decls? >> >> Richard. >> >>> 2) final IR after SRA: >>> >>> MEM[..., &SR_123] = .. >>> other_var = SR_123_yyy(D); >>> >>> >>> David >>> >>> On Mon, Jun 20, 2011 at 4:13 AM, Richard Guenther >>> <richard.guent...@gmail.com> wrote: >>>> On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li <davi...@google.com> >>>> wrote: >>>>> Compiling the test case in the patch with -O2 -m32 without the fix, >>>>> the program will abort. The problem is a var decl whose address is >>>>> taken is not marked as addressable leading to bad SSA update (missing >>>>> VUSE). (the triaging used the the .after and .after_cleanup dump diff >>>>> and found the problem). >>>>> >>>>> the test is on going. Ok after testing? >>>> >>>> That doesn't make sense. SRA shouldn't generate anything that has >>>> its address taken. So, where do we take its address? >>>> >>>> Richard. >>>> >>>>> Thanks, >>>>> >>>>> David >>>>> >>>> >>> >> >
