On 10/14/21 8:37 AM, Giovanni Mascellani wrote:
In HLSL the rules used to determine the type of a composite expression change depending on the operator. This commit changes add_expr so that it accepts both the types to which the operands have to be casted and the type that the final expression must have (which is not necessarily the cast type).
For example, when comparing a half with an int, both of them will have to be casted to float, though the type of the expression as a whole will be bool.
Similarly, it is not always the case that all operands have to be casted to the same type, therefore the interface leaves room for specifying a different cast type for each operand. For example, the first operand of the ternary operator must be casted to bool, while the other two must be casted to their common type, which is then the output type of the whole expression.
Yeah, but the ternary operator is a special case. I don't think it should result in an HLSL_IR_EXPR. Probably we should synthesize a temporary variable, store to it inside of a conditional, and load from it.
I'm still not convinced that casting in add_expr() is better than casting in the caller, either.
The add_*_last helpers behave similarly as their counterpart without "_last", except that the last node in each instruction list is used as an argument.
Yeah, I still don't like this name. "last" makes me think that the instruction will be added to the end of a list, or something. "merge" or "combine" would be a lot better, but it's a bit awkward for the unary helpers. But then again maybe we don't need the unary helpers, and we can just as easily just spell out node_from_list() inline. There are only three such cases after all (and I guess they're not even all the same kind of operation).
Or "parse", I guess, to symbolize it's done as part of parsing, although that's not great either.
Signed-off-by: Giovanni Mascellani gmascellani@codeweavers.com
libs/vkd3d-shader/hlsl.y | 144 ++++++++++++++++++--------------------- 1 file changed, 66 insertions(+), 78 deletions(-)
I think at least splitting the "cast_types" part out of this patch would make it easier to read.