Re: [RFC] rationale for systematic elimination of OP_SYMADDR instructions

[Christopher Li <sparse@chrisli.org>]

On Wed, Apr 26, 2017 at 7:02 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>> Does the address of the symbol ever change inside a function?
>> I assume it does not change. If that is the case, can we skip the CSE
>> and replace all the symbol address reference to one OP_SYMADDR?
>>
>> For example, for each symbol access in the function we insert OP_SYMADDR
>> after the entry:
>> foo:
>> <entry-point>
>>         %r1 <- a
>>         %r2 <- b
>> ...
>>
>> Then all reference of symbol address of "a" and "b" inside the function
>> foo will use %r1 and %r2.  Notice that we still keep the OP_SYMADDR
>> instruction, just move to function entry.
>>
>> Is that illegal or bad?
>
> The address of a symbol will of course not change.
> So yes, all the OP_SYMADDR could move to the top of the function.
> It wouldn't be illegal and it could be advantageous in some cases.
> It would be bad, though, if these addresses are in fact not used
> (because of a conditional). I'm thinking to something like:
>         if (unlikely(some cond)) a++;
> Of course, doing so would also need a register to hold these addresses
> so pre-calculated. What if the function access a lot of symbols?

Sorry for reply to a very old email. Still catching up the my backlogs.

I think the function access a lot of symbols will need to have more
OP_SYMADDR, at least one instruction per symbol if you want to
have the OP_SYMADDR. You can't do better than that.


> In my opinion, we should handle these OP_SYMADDR just like
> any other instructions (in other words: near where they are used).

I think in the current IR, how close it is to be used is not a big issue.

If you want to get it close and have one OP_SYMADDR per symbol.
The OP_SYMADDR should be place at immediate D(N), where N is the
block that use the symbol. In other words, place the OP_SYMADDR
at where N blocks join in the dominator tree. You can't do better than
hat.

Please correct me if I am wrong.  I still think:
1)  OP_SYMADDR can be generated from the symbol node and where
     to place them (immediate D(N)).

2) If one of the back end needs them. Go ahead and generate OP_SYMADDR.
   However, I don't think sparse checker need to use the OP_SYMADDR
   so it will be more optimal  for sparse checker to avoid OP_SYMADDR.

   Am I missing some thing?

Chris