Hi,
Il 20/01/22 19:20, Matteo Bruni ha scritto:
I wonder if that's what it should do in the first place?
Yes, witness the following shader:
uint func(float x) { return 1; } uint func(half x) { return 2; }
float4 main(void) : sv_target { return float4(func(float(0)), func(half(0)), func(int(0)), func(uint(0))); }
Native reduces this to (1, 2, 1, 1).
Fun... But at least it means we can fix add_implicit_conversion() and avoid that kind of workarounds, if I understand correctly.
I... guess, but it seems janky. The main point of add_implicit_conversion() is for stuff like assignment RHS or return values. If we had add_implicit_conversion() pass through half it'd generate IR like
2: half | 1.0 3: | x = @2 4: float | x
(i.e. "x" is a float variable). Which... works, I guess? Maybe it's not that bad, since we already do a somewhat similar thing for scalar vs vec1.
I think that's an improvement to the current state of things, right now we're effectively losing information from the get-go. We can always add a half-to-float lowering pass to simplify the IR.
I don't really understand what Zeb's proposed fragment of code have to do with implicit conversions (that seems mostly a test about overload resolution), and I don't understand why and how implicit conversions should treat half in a special way.
Also, I don't think we should mix types in the IR without casts. If we're doing the same for vec1 vs scalar, I think we should rather fix that than introduce other mistypings.
Giovanni.