Hi, On Mon, Jun 20, 2011 at 10:47:58PM +0200, Richard Guenther 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?
This is now PR 49516. I will submit a patch later today after bootstrapping and testing it. Martin > > 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 > >>> > >> > >
