On Tue Jan 24 18:56:26 2023 +0000, Zebediah Figura wrote:
I still don't understand why there's a need to refactor anything? (And, if we do, it doesn't belong in this patch). What about register allocation can't be done with the loop we have?
Well, I think that allocation must be done regset-wise instead of hlsl_base_type-wise, given that that is what defines the regsets. And once we replace the argument in `allocate_objects()` with a regset, and considering we have `reg_size[regset]` for each variable, it doesn't make much sense to have `get_object_type_info()` anymore.
The other refactorings may indeed be premature, but I think I remember why those are there:
Given the possibility of multiple-register variables (which are introduced in the patch just after this MR), the allocation strategy needs to be "smarter". Assigning indexes sequentially in a greedy way is no longer possible to get the correct result, consider the following scenario:
- Variable A is reserved to t2 and uses 3 t registers. - We need to allocate variable B, which uses 3 t registers. - We need to allocate variable C, which uses 1 t register.
In that case we need to get the allocation like this: ``` C - A A A B B B ``` instead of like this: ``` - - A A A B B B C ```
So, some of the refactoring changes are useful for the new allocation strategy, for instance, `get_reserved_object()` was changed into `get_allocated_object()` in order to not only get reserved objects but also being able to query objects already allocated by the allocation strategy itself. Also, I probably moved `allocate_register_reservations()` to a previous step to make the strategy simpler.
TL;DR: Okay, I will try to make an intermediate patch, separating the switch from `hlsl_base_type` to regsets and the refactoring associated to a change in the allocation strategy.