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

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

[Dibyendu Majumdar]

Hi,

On 12 September 2017 at 22:54, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> One issue I am facing at the moment is that there is no explicit
> alloca for each symbol that is used in a function - so that the
> backend has to detect when a symbol is accessed and then do alloca to
> associate stack space. In the LLVM backend this is not so much an
> issue as LLVM allows instructions to be inserted at a particular point
> - so my code just ensures that all the allocas go at the start of the
> function as required by LLVM. But I am having trouble with the other
> backend that doesn't have this capability.
>

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

Regards
Dibyendu

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

[Luc Van Oostenryck]

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.

-- Luc

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

[Dibyendu Majumdar]

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.

Regards
Dibyendu

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

[Luc Van Oostenryck]

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