User Details
- User Since
- Apr 30 2013, 5:34 PM (260 w, 1 d)
Feb 19 2018
Feb 16 2018
@hans : this needs to go in LLVM 6.0, is it OK?
Feb 15 2018
@tstellar YES.
I quickly put a patch to change the encoding, may be easier to discuss with code at hand: https://reviews.llvm.org/D43348
(I didn't try to build it, just a quick draft)
Feb 14 2018
Feb 13 2018
Actually if we're making this change, we consider that bitcode generated between the introduction of the new fast-math flags and now isn't supported anymore.
If so then we could instead of bumping a version, change the encoding of the FMF record (or create a new record type), so that the old encoding is upgraded but not the new one.
That would seem to me to be more in line with the usual handling of such situation in the bitcode.
Feb 6 2018
Jan 13 2018
Jan 12 2018
Jan 10 2018
Jan 9 2018
The test still seems complex to me (do you need all the IR types? The code in the functions? And all these metadatas and metadata fields?
Dec 29 2017
Dec 21 2017
Dec 18 2017
Dec 15 2017
However small changes in input, could trigger combined module and shuffle outputs making life of llvm::LTO harder.
I suspect it should be possible to do this after the ThinLink and add notation about the importing decision, promotion, dead-elimination, ... on every edge/nodes.
Neat!
This patch doesn't seem motivated, the only effect I can see is that a ThinLTO link that don't include any LTO module would create a module while it was lazily created only if needed before.
Dec 14 2017
The commit message does not make much sense to me in the context of this C++ API: there is a non-negligible layer between the build and the build system rules and the LTO implementation, i.e. the linker.
Implementing a contract that makes it convenient for your build system in the implementation of the LTO "engine" behind this API looks like leaking abstractions to me.
Dec 8 2017
I wrote this code in April 2016 ( http://reviews.llvm.org/D19103 ), in the very first approach to internalization, which was inferred in the backend and wasn't bullet proof (especially with respect to assembly by the way).
Since then, we moved all decision in the thin-link and this code is indeed (hopefully) dead.
Nov 14 2017
LGTM.
Did you check clang?
Nov 13 2017
Was this done using clang-tidy (or similar tool) or manually?
Nov 7 2017
Oh ok, this is different than what thought the issue was. There isn't a correctness problem with this - the reference edge ensures correctness. It sounds like the only correctness issue then was due to the ld64 issue. (I thought there was also an issue with getting @f promoted when @ext was imported.) There isn't really a correctness issue with having both a reference and call edge though. Ideally we would have just the call edge and no reference edge, but that goes back to the earlier suggestion you had tried (changing the call site to look through pointer casts which had other issues). So I think this is fine. Sorry for the confusion.
Nov 6 2017
Nov 3 2017
Nov 2 2017
Oct 31 2017
Oct 27 2017
Oct 26 2017
Oct 11 2017
Oct 2 2017
Oct 1 2017
Sep 28 2017
Sep 27 2017
Ideally, I think all the headers would hide the method behind #ifdef LLVM_ENABLE_DUMP , so that it wouldn't be a linker failure but a compile time failure!
Thanks for fixing this :)
Sep 26 2017
Can you elaborate why this script is desirable/needed?
Sep 18 2017
Sep 17 2017
Did you check ld64 in Xcode 9? I think ld64 was fixed to append the suffix as well.
Sep 4 2017
Sep 1 2017
LGTM
Aug 31 2017
LGTM otherwise.
Aug 28 2017
I don't mind where you install it, but we can also assume that someone who use this Dockerfile intends to use clang, so why not adding it to to update-alternatives as well, and even making it default for /usr/bin/c++ and /usr/bin/cc?
Aug 27 2017
I'd like to also see a testcase for the situation where we trigger the emission of a declaration with an available_externally definition and then find we need to promote it to a "full" definition:
Aug 25 2017
Aug 24 2017
Would this be all obsolete with git repos?
Aug 20 2017
Aug 17 2017
Bi-weekly ping! (@rsmith)
LGTM
Aug 14 2017
Seems fine to me. Adding @dexonsmith (I don't know who maintain libc++ at Apple right now)
Aug 9 2017
Is this something that is affecting clang-5.0 backward compatibility with clang-4.0?
(adding @hansw for visibility)
Aug 8 2017
LGTM.
Aug 7 2017
Aug 5 2017
Aug 4 2017
Address Richard's comment
Aug 3 2017
I'll leave the final approval to Teresa.
When the working set size is determined to be huge, disable peeling to avoid bloating the working set further.