Re: Potential problem with variable handling - Was: Handling of local variables in the backend

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Wed, Sep 13, 2017 at 3:07 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Hi Luc,
>
> On 13 September 2017 at 12:55, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
>> On Wed, Sep 13, 2017 at 1:37 PM, Dibyendu Majumdar
>> <mobile@majumdar.org.uk> wrote:
>>> Hi,
>>>
>>>
>>> I have been thinking about this issue for some time - i.e. that the
>>> Sparse IR does not explicitly define or initialize local variables.
>>
>> The problem of undefined variables is one thing (that the SSA conversion
>> can and should deal with).
>>
>>> The back-end deals with it by doing it at first access. But this could
>>> result in incorrect behavior if the initialization was meant to occur
>>> at a certain point in the code. I should probably try to prove this
>>> theory by creating a test - but intuitively it seems that if the
>>> programmer had meant to initialize a variable at a particular point,
>>> there could be a reason why it should be done at that point and not
>>> some point later.
>>
>> Unless you access the variables by some means the compiler is not aware
>> of, it must not matter.
>>
>> And in all case, the initialization must be done when the following rules
>> (scopes, sequence points, ...) and the compiler is free to do anything
>> 'as if' these rules are respected.
>>
>
> Yes, it seems this is okay as the store instruction (from
> initialization) occurs at the right place.

Yes, but the 'place' (or 'time') is not the right concept.
The only thing that matter is for subsequent loads to see the
correct values. Thus everything is legit and correct as long as
the store-load dependencies are respected.
If you use pointers or if the variables can be in one way or another
be aliased between each other, then it's not simply the store-load
dependencies of this variable that must be respected but all
(possible) dependencies between all aliases (and partial aliases).

-- Luc