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