Re: SRA generates uninitialized var use

[Richard Guenther <richard.guenther@gmail.com>]

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.

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