[llvm-dev] FW: clarification needed for the constrained fp implementation.
陳韋任 via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 7 07:45:04 PST 2017
> I was actually thinking that fegetround and fesetround would always be
> translated into llvm.get.roundingmode and llvm.set.roundingmode at least
> initially, because it’s a bit of trouble to prove that they are being used
> to implement the local rounding mode idiom. Certainly recognizing that kind
> of usage is more work than a front end should be doing.
> I would propose the begin/end local rounding mode intrinsics as a
> convenience for cases where some user (probably never clang) specifically
> knew that this was the intended behavior. I believe Wei has a use case
> like that, and I’ve also spoken to someone working on the Julia language
> who would like to be able to do this.
> That does still leave the problem of what happens if there is a function
> call inside a pair of begin/end local rounding mode intrinsics. I’m not
> entirely sure the best way to handle this. Do we try to restrict calls
> that might change the rounding mode or do we leave it up to the front end
> and/or user to make sure things are safe.
From the 2011 discussion thread on Intel Forum , seems the pragma only
affects the function containing it. That sounds reasonable to me.
> As for the C/FENV_ACCESS case, I seriously feel like the way that pragma
> is defined leaves users with a huge amount of room to shoot themselves in
> the foot. If I’m reading the specifications correctly, it says that
> changing from a scope with FENV_ACCESS on to a scope with FENV_ACCESS off
> or vice versa without the FP environment in its default state is undefined
> behavior. At some point it would probably be nice to have a sanitizer that
> checks this.
I think you can just implement the pragma without worrying too much about
how user might mis-use them. Leave the front-end or sanitizer to take care
of those issues.
Wei-Ren Chen (陳韋任)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev