On Wed, 11 Aug 2021 at 14:49, Matteo Bruni matteo.mystral@gmail.com wrote:
On Wed, Aug 11, 2021 at 2:31 PM Henri Verbeet hverbeet@gmail.com wrote:
On Wed, 11 Aug 2021 at 13:50, Matteo Bruni mbruni@codeweavers.com wrote:
@@ -768,6 +768,11 @@ static void write_sm1_instructions(struct hlsl_ctx *ctx, struct vkd3d_bytecode_b FIXME("Matrix operations need to be lowered.\n"); break; }
if (instr->data_type->type == HLSL_CLASS_ARRAY){FIXME("Array operations need to be split.\n");break;}Should that be a compiler error/warning instead? Arguably that would apply to FIXMEs/ERRs in compiler code in general; I think there are very few cases where we don't want those to be compiler messages instead.
I guess that's a possibility. In general we're currently ignoring a lot of error conditions caused by missing compiler features. We could certainly start switching it over to spewing errors instead (or better, implementing the missing features). It feels to me that we will eventually want to do that for sure but maybe not right away. At this point I'd push the compiler a bit further, then e.g. as soon as trivial shaders start to be compiled correctly for both SM1 and SM4 we can start tightening it up so that the compiler either generates correct bytecode or errors out with some compilation message.
I can certainly be convinced otherwise though.
It may not be worth the effort of changing the existing FIXMEs at this point, but it seems more questionable to add new ones if we already know we'll have to replace them in the future. If the concern is that generating an error means that the generated code won't be returned to the caller we could generate a warning instead and upgrade it to an error later, although I'm not sure how useful invalid byte code is going to be to the caller.