search for: origrm

...As I said above, I think front ends should define clear circumstances under which such changes are permitted, but the mechanism for making such changes is independent of the constrained FP intrinsics. For example, consider the following C function. double foo(double A, double B, double C) { int OrigRM = fegetround(); fesetround(FE_TOWARDZERO); double tmp = A + B; fesetround(OrigRM); return tmp + C; } Assuming the compiler was in a state where it knew fenv access was enabled, I would expect that to get translated to something like this (after SROA cleanup): define double @foo(double %A,...

Let me clarify. These aren’t intended to be exposed to the user. The user code that leads to the generation of these intrinsics will be normal floating point operations combined with either pragmas (such as “STDC FENV_ACCESS ON”) or command line options (such as the recently introduced “-fp-model=strict”). The reason I’ve been avoiding normal constant values is that it provides no information when