search for: d43253

...> official LLVM release. >> > Need to at least make sure everyone knows what to expect, so the cherry-pick for the LLVM 6.0 release should include an entry in the Release Notes. Hans: this can only happen if you're still OK to cherry-pick in LLVM 6.0 branch https://reviews.llvm.org/D43253 Duncan, Steven, Peter, Teresa: this change can break LTO if we read back bitcode emitted from trunk since r317488 (last November), any concerns? Best, -- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachment...

...gt; >> > Need to at least make sure everyone knows what to expect, so the > cherry-pick for the LLVM 6.0 release should include an entry in the Release > Notes. > > Hans: this can only happen if you're still OK to cherry-pick in LLVM 6.0 > branch https://reviews.llvm.org/D43253 > > Duncan, Steven, Peter, Teresa: this change can break LTO if we read back > bitcode emitted from trunk since r317488 (last November), any concerns? > For our usage of ThinLTO, we don't reuse bitcode across different revisions, so it wouldn't cause an issue. The LTO caching i...

2018-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

2018-02-13 13:29 GMT-08:00 Quentin Colombet <qcolombet at apple.com>: > Hi Mehdi, > > > On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-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

Hi Mehdi, > On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-08 17:34 GMT-08:00 Quentin 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

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