On Tue, Jun 21, 2011 at 1:42 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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 ... >
Yes, in the current way it is not optimal. Before that problem is resolved, is the simple patch ok for trunk? The non-optimal code issue can be tracked with a different bug. Thanks, David > 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 >>>>>> >>>>> >>>> >>> >> >
