SRA generates uninitialized var use

Xinliang David Li davidxl@google.com
Tue Jun 21 16:11:00 GMT 2011


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.

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



More information about the Gcc-patches mailing list