Hi, On Tue, Jun 21, 2011 at 06:08:27PM +0200, Richard Guenther wrote: > On Tue, Jun 21, 2011 at 5:51 PM, Xinliang David Li <davi...@google.com> wrote: > > 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. > > No, it's not a proper fix.
Just for the record, I am aware of this, have managed to reproduce it and it is a high priority task for me. I'm just still overwhelmed by email and other backlog from the GCC Gathering (extended) weekend and so a bit less responsive than usual. Martin > > Richard. > > > 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 > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
