On 14.06.2017 08:30, Gert Wollny wrote:
Am Dienstag, den 13.06.2017, 11:07 +0200 schrieb Nicolai Hähnle:


I'm curious what you'd suggest for getting rid of allocations anyway.

As the refactoring goes I think I will end up with a hybrid approach:
In the temporaries  I will not keep the full time line, but the
important read/write information - just like you suggested. However, I
will not resolve the scopes at the end of each loop, but only after the
program is fully scanned. For that I need to keep the information of
all scopes available and links to the key scopes fro each temporary.

Okay. Hmm, I think in a sense what you might end up doing is resolving scopes lazily. That does sound good, and I'm starting to see how it might be possible. Try to keep the data structures clean so that you can easily explain all the variables in comments. That should help a lot.


Equal to what you pointed out above, I'll need three allocations for
this:

- the vector for the scopes,
- the vector for the temporaries
- a stack to handle the scope changes.

To not limit the number of scopes and the scope nesting level the scope
vector and the stack might do re-allocations though.

I think right now I will not go for tracking whether a temporary is
written in both if/else branches or all switch cases. What I want to
achieve is that the drivers don't get into trouble because too many
temporaries need to be allocated when the TGSI is translated into byte
code (test case R600 with 124 free usable registers), and so far this
seems to work without tackling this detail.

Sounds good. If I'm understanding the "lazy scope resolution" correctly, it might even be not too difficult to add if/else and switch case resolution after the fact. Anyway, it's not needed for a first version.

Cheers,
Nicolai



Thank you again for your insights,
Gert



--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to