search for: d39304

...ling a llvm-6.0 bitcode will potentially generate incorrect code w.r.t. fast math expectations. Should we bump the bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? (I believe we should!) * Context * With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. From a bitcode perspective, this change looks like this: Before r317488 we had 6 bits that respectively r...

...generate incorrect code w.r.t. fast math expectations. > > Should we bump the bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? > (I believe we should!) > > > * Context * > > With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that...

...ate incorrect code w.r.t. fast math > expectations. > > Should we bump the bitcode version because of that and have the > autoupgrader properly rewrite the fast-math to preserve that semantic? > (I believe we should!) > > > * Context * > > With https://reviews.llvm.org/D39304 / r317488 we got rid of the umbrella > UnsafeMath flag and introduced 3 more flags that better represent the > different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: >...

We knew the day when we needed another FMF bit was coming back in: https://reviews.llvm.org/D39304 ...it was just a question of 'when'. :) I'm guessing that an FTZ bit won't be the last new bit needed if we consider permutations between strict FP and fast-math. Even without that, denormals-as-zero (DAZ) might also be useful? So rather than continuing to carve these out bit-by-bi...

...fast math expectations. >> >> Should we bump the bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? >> (I believe we should!) >> >> >> * Context * >> >> With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. >> >> From a bitcode perspective, this change looks like this: >> Before r317488 we had...

...generate incorrect code w.r.t. fast math expectations. > > Should we bump the bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? > (I believe we should!) > > > * Context * > > With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that...

...>> Should we bump the bitcode version because of that and have the >>> autoupgrader properly rewrite the fast-math to preserve that semantic? >>> (I believe we should!) >>> >>> >>> * Context * >>> >>> With https://reviews.llvm.org/D39304 / r317488 we got rid of the >>> umbrella UnsafeMath flag and introduced 3 more flags that better represent >>> the different things that happen under fast-math. >>> >>> From a bitcode perspective, this change looks like this: >>> Before r317488 we had 6...

...bitcode version because of that and have the >>>> autoupgrader properly rewrite the fast-math to preserve that semantic? >>>> (I believe we should!) >>>> >>>> >>>> * Context * >>>> >>>> With https://reviews.llvm.org/D39304 / r317488 we got rid of the >>>> umbrella UnsafeMath flag and introduced 3 more flags that better represent >>>> the different things that happen under fast-math. >>>> >>>> From a bitcode perspective, this change looks like this: >>>> Befo...

...ate incorrect code w.r.t. fast math > expectations. > > Should we bump the bitcode version because of that and have the > autoupgrader properly rewrite the fast-math to preserve that semantic? > (I believe we should!) > > > * Context * > > With https://reviews.llvm.org/D39304 / r317488 we got rid of the umbrella > UnsafeMath flag and introduced 3 more flags that better represent the > different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: >...

...> expectations. >> >> Should we bump the bitcode version because of that and have the >> autoupgrader properly rewrite the fast-math to preserve that semantic? >> (I believe we should!) >> >> >> * Context * >> >> With https://reviews.llvm.org/D39304 / r317488 we got rid of the >> umbrella UnsafeMath flag and introduced 3 more flags that better represent >> the different things that happen under fast-math. >> >> From a bitcode perspective, this change looks like this: >> Before r317488 we had 6 bits that respective...

Hi, I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags, but we've already used up the 7 bits available in Value::SubclassOptionalData (the "backing storage" for FPMathOperator::getFastMathFlags()). These are the possibilities I can think of: 1. Increase the size of FPMathOperator. This gives us some additional bits for FTZ and other fastmath flags we'd want