search for: isfast

Agree, but that wouldn’t solve the downgrade problem plus this is probably too late to fix LLVM 6.0 for all the isFast uses. > On Feb 9, 2018, at 10:05 AM, Matthias Braun <mbraun at apple.com> wrote: > > Just wanted to point out part of this even becoming a problem is the use of `isFast()`. > There should be warnings against using isFast() and the existing code should be changed to query specifi...

Just wanted to point out part of this even becoming a problem is the use of `isFast()`. There should be warnings against using isFast() and the existing code should be changed to query specific flags instead... - Matthias > On Feb 8, 2018, at 5:34 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > TL;DR > r317488 changed t...

Hi, TL;DR r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling 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...

...2018 at 8:34 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > TL;DR > r317488 changed the way fast math flags are laid out in the bitcode and > anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the > optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling 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 be...

...-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org>: > Hi, > > TL;DR > r317488 changed the way fast math flags are laid out in the bitcode and > anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the > optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling 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 be...

...Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: > Hi, > > TL;DR > r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling 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 shoul...

...; llvm-dev at lists.llvm.org>: >> >>> Hi, >>> >>> TL;DR >>> r317488 changed the way fast math flags are laid out in the bitcode and >>> anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the >>> optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling 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-ma...

...lombet via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Hi, >> >> TL;DR >> r317488 changed the way fast math flags are laid out in the bitcode and >> anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the >> optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling 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...

...>: >>> >>>> Hi, >>>> >>>> TL;DR >>>> r317488 changed the way fast math flags are laid out in the bitcode and >>>> anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the >>>> optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling 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...