SRA generates uninitialized var use

[Martin Jambor]

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 <davidxl@google.com> wrote:
> > On Tue, Jun 21, 2011 at 1:42 AM, Richard Guenther
> > <richard.guenther@gmail.com> wrote:
> >> On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li <davidxl@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.guenther@gmail.com> wrote:
> >>>> On Mon, Jun 20, 2011 at 6:15 PM, Xinliang David Li <davidxl@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.guenther@gmail.com> wrote:
> >>>>>> On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li <davidxl@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
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >