On Tue, Jan 4, 2022 at 5:59 PM Francisco Casas fcasas@codeweavers.com wrote:
January 4, 2022 11:36 AM, "Giovanni Mascellani" gmascellani@codeweavers.com wrote:
Hi,
On 03/01/22 15:57, Francisco Casas wrote:
On constant folding, first switch on the op type, handling each operation using a function defined on hlsl_constant_ops.c.
Creating a new file makes sense to me, but while you're doing it it also makes sense to copy there the whole implementation of fold_constants(), doesn't it? It logically related to hlsl_constant_ops.c, and it also spares you adding a lot of functions to the header file (also, if you do that you probably have only one function to add to the header, fold_constants() itself, and you can put it in hlsl.h instead of creating a new file).
That sounds like a very good idea to me!
While I don't have any specific objection against it, is there a particular reason for inverting the switch on the type and on the operation?
Zebediah mentioned that in the future we may want to add operations that aren't typed. Also, I think that splitting the problem op-wise allows for a better organization since there are fairly more ops than types.
I agree, it looks much better to me this way.
Each of these operations switches on the data type, if needed.
As I just said on the other thread (where I replied before noticing this one), watch out for undefined behavior that some operations entail.
Noted. The only problem with (+), (*), and (-), I can think of is signed integer overflow. I am not sure yet if implicit castings in C may result in undefined behaviors, I must check.
Another one that potentially needs some care is folding float expressions. E.g. even transforming a "(x + a) + b" into "x + (a + b)" (with x float, a and b constants) can technically affect the final result, depending on the specific values. We need to replicate MS's compiler in this regard, or at least support compatible behavior as one of the options. I've been looking into this a bit and it appears that the native compiler always allows constant folding transformations, regardless of the presence of the precise keyword or the D3DCOMPILE_IEEE_STRICTNESS flag to D3DCompile(). Other transformations / optimizations are affected but I guess we'll think about those when we get there.
So, as far as constant folding is concerned, always optimizing float constants should be okay. Or we could have our own compilation flag to control that, in case we feel that behavior might be useful to some non-Wine user.