+static const struct vkd3d_sm4_register_type_info *get_register_type_info( + enum vkd3d_sm4_register_type type) +{ + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(register_type_table); ++i) + { + if (type == register_type_table[i].type) return ®ister_type_table[i]; + } + + return NULL; +} + +static const struct vkd3d_sm4_register_type_info *get_register_type_info_from_handler( + enum vkd3d_shader_register_type handler) +{ + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(register_type_table); ++i) + { + if (handler == register_type_table[i].handler_type) return ®ister_type_table[i]; + } + + return NULL; +}
We care about parser speed at least somewhat, and looping over the table like that is probably going to make it worse. (On that note, get_opcode_info() is one of the current offenders, and we should probably just index opcode_table[] by the opcode id.) We probably care slightly less about HLSL compilation time, but I'd probably feel better about simply having separate tables for vkd3d->sm4 and sm4->vkd3d.
There may be different ways to get there, of course. The most straightforward approach would be to simply put two separate tables in tpf.c, and I think that would be fine. We could also generate those lookup tables from a single table like you have here though, either at runtime (for example, the first time get_register_type_info()/get_register_type_info_from_handler() is called) or at compile time.
I don't love the names "type" and "handler_type"; I'd probably prefer some variant of "tpf_type"/"vkd3d_type", "sm4_type"/"ir_type", or something along those lines.
The `'s'` trick doesn't really thrill me, but right now I can't think of anything better and I prefer to see this moving forward rather than bikeshedding that bit (which can always be improved later, if a better solution arise at some point).
Likewise; I don't think it's great, but I can live with it.
Does this series strictly depend on the first two patches by Conor?