Re: [PATCH 3/3] allow to normalize the pseudos

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

On Mon, Jun 5, 2017 at 8:45 PM, Christopher Li <sparse@chrisli.org> wrote:
> On Sat, Jun 3, 2017 at 12:34 AM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
>> Using the output of test-linearize for testing is not
>> ideal because some details of this output are very dependent
>> to small changes in linearization or optimization while the
>> test in itself may very well not concerned about those changes.
>>
>> One of the things that are particulary sensitive to these changes
>> is the number of the pseudos (%r123, ...).
>>
>> Make these tests much less sensitive to these changes by adding
>> a normalization phase called just before emitting the output.
>> This normalization will renumber all the pseudos sequentially,
>> restarting at %r1 at each functions.
>
> I have a totally untested idea might be able to simplify this
> normalize process. It seems most of the pseudo output is
> come from show_pseudo(). We can use the generation number
> idea. All we need to do is just keep track of the base of the pseudo
> number. If you need new series of number just set the base to a number bigger
> than all of the pseudo number. That might means make alloc_pseudo::nr
> visible to other function we know what is the max pseudo number.
>
> Initialize the normalization is easy, just set
>      pseudo_base = ++pseudo_max;
>
> Then in show_pseudo() we can do the normalize as following:
>
> if (pseudo->nr - pseudo_base < 0)
>      pseudo->nr = ++pseudo_max;
>
> For the output of the number, we have:
> nr = pseudo->nr - pseudo_base;

The problem that the patch here tries to solve is that *between* different
versions of sparse, because of some subtle (or not so subtle) changes
in the details of linearization or the optimization, a function, while
having essentially the same intermediate code have in fact different
name (here just the number) for its pseudos.
And these differences are annoying when comparing results, during
development and for the test suite. Also, given the 'problem', it's very
fine to keep the code simple and only make the changes in a separate
pass only used for dev & test.

I have already tried several things in the past 6 months and anything
a bit smart had some problems, it's why, finally, I opted for the brute force
here in this patch.

I think that what you propose here, will just allow to have consecutive
pseudo numbers but I don't see how it will give the guarantee that
"same code" will give "same pseudo numbers" and this will be easily
be 'diffed out' so that only real differences will show up in diff output.

> One problem I can see if the pseudo->nr wrap around then it
> will create confusion. Maybe not some thing we need to worry
> about any time soon.
Indeed, with even with 32bit ::nr, I'm not really worried :)

> Another thing is the pseudo->nr only
> make sense in the function scope. We might able to use that
> to handle overflowing if it really became a problem.
Well, it's true for now that we could reset the counter at each function
and this would already 'solve' most of the cases I had. But what if
we begin to add a second pass of automatic inlining?
And keeping unique names every pseudo has advantages.

-- Luc