This patch is used to initialize the new added register MXCSR.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm not sure I understand why this needs to be initialized. Why don't we need to do it for FPCW?
llvm/tools/llvm-exegesis/lib/X86/Target.cpp | ||
---|---|---|
506 | Isn't the default value of MXCSR 0x1f80 not 0x1f8? |
I'm not sure I understand why this needs to be initialized. Why don't we need to do it for FPCW?
I'm sorry for not giving comments. Yes, we do need for FPCW if this is a reasonable approach. But I'm not sure if we need to explicatly initialize registers like MXCSR and FPCW or not either.
Can we just return a MCInstBuilder(X86::NOOP) for them to make the check pass (In Assembler.cpp L44, it judges the IsSnippetSetupComplete by checking if the return value is empty).
We make sure that every register that is used by an instruction in the snippet is initialized. This is to avoid having fluctuations in measurements due to performance depending on values in registers. I think it's great if SSE/AVX instructions start explicitly state their deps on MXCSR, because the behaviour does indeed depend on the value of these flags.
Regarding whether masking instruction is the right thing to do: Yes for now, because this will ensure that these instructions will at least pass, but on the other hand that might not be perfectly representative of the real performance characteristics. AFAICT @gchatelet still wants to work on value constraints & exploration.
So this looks good to me if Craig has no other remarks.
We make sure that every register that is used by an instruction in the snippet is initialized. This is to avoid having fluctuations in measurements due to performance depending on values in registers. I think it's great if SSE/AVX instructions start explicitly state their deps on MXCSR, because the behaviour does indeed depend on the value of these flags.
Thanks for the explanation. Please note that currently we only state the rounding modes and the IEEE masks bits of MXCSR. This means instructions like VRSQRT14PS, which only have dependence on FTZ and DAZ, wouldn't be modeled.
Please note that currently we only state the rounding modes and the IEEE masks bits of MXCSR. This means instructions like VRSQRT14PS, which only have dependence on FTZ and DAZ, wouldn't be modeled.
FTZ and DAZ are modeled now by commit rGc8995de06994. Thanks.
Isn't the default value of MXCSR 0x1f80 not 0x1f8?