This is a pre-emptive bug for the implementation of constrained FP intrinsics. When these intrinsics are translated to machine instructions, an implicit use and/or def of target-specific FP environment registers should be added to the instructions selected. These registers aren't currently modeled for FP instructions, and for the default, non-constrained case it probably makes sense to continue not modeling them, but when the constrained intrinsics are used these accesses need to be modeled to prevent unwanted code motion.
For example, if a program uses an intrinsic such as llvm.x86.sse.ldmxcsr to change the rounding mode we need to be certain that FP operations are not moved across the LDMXCSR instruction.
andykaylor
commented
7 years ago
Extended Description
This is a pre-emptive bug for the implementation of constrained FP intrinsics. When these intrinsics are translated to machine instructions, an implicit use and/or def of target-specific FP environment registers should be added to the instructions selected. These registers aren't currently modeled for FP instructions, and for the default, non-constrained case it probably makes sense to continue not modeling them, but when the constrained intrinsics are used these accesses need to be modeled to prevent unwanted code motion.
For example, if a program uses an intrinsic such as llvm.x86.sse.ldmxcsr to change the rounding mode we need to be certain that FP operations are not moved across the LDMXCSR instruction.