- User Since
- Nov 4 2014, 3:46 PM (176 w, 3 d)
Wed, Mar 21
I am not trying to discuss which english word is best here. My point is simply:
- macros are evaluated during compile time
- "host"means either the platform you compiled on during compile time or the platform you run on during the runtime
- __is_host_* is not a good name, because it is misleading as it either implies "runtime" as a compile-time constant, or indicates the wrong platform.
It is not about matching command line name to builtin marco name. "target" is the platform we are compiling for, whether it is host or device or something else. It is a different concept when you talking about cross-compiling, which "target" is strictly not host and "build" or "host" doesn't matter to compiler at all.
I disagree. I think "target" is the correct name, even for cross compiling. For something compiled with -target foo, we are consistent calling it "target" during compile time. It only becomes appropriate to call it "host" during the runtime of the executable. There is no such concept as "host" when you are doing cross compiling.
Mon, Mar 19
Thu, Mar 15
If we all agree that dropping local_unnamed_addr is invalid, I can abandon this. Thanks for the feedback!
I might have missed something. Can you be more specific about how it is going to work?
The solution is to use canBeOmittedFromSymbolTable from include/llvm/Object/IRSymtab.h.
The symbol table is computed earlier and so the above predicate still returns 1. Your examples work with lld and ThinLTO if you want to check the implementation details.
So the original of this patch is thinLTO is promoting linkonce_odr to weak_odr. Think the following two situations:
Tue, Mar 13
Additional comment, I didn't realize llvm-nm now prioritize to print bitcode symbol table, rather than the symbol table from the object file. There should be an option to choose which one to see and maybe also an option to see both.
Thanks for fixing this. LGTM.
Thu, Mar 1
The idea is to prevent LTO (ConstMerge pass) from merging global constants that has the same value, which has the same side-effect as linker merging two weak symbols that has ODR violation.
Wed, Feb 28
LGTM. And yes, order doesn't matter.
Mon, Feb 26
The API change is fine for ld64. But you need to do the following when you update LTO C API:
- You need to declare the interface in include/llvm-c/lto.h
- You need to bump LTO_API_VERSION in that header and document the new API is available since the new LTO_API_VERSION.
- You need to update tools/lto/lto.exports. This is the export list used by ld64 and only the interface listed in that file will be exported on darwin platform.
Feb 19 2018
Michael doesn't have commit right yet so I will commit this for him.
Feb 16 2018
I am using local_unnamed_addr as an example. Maybe you are right but I think my point is still valid. That is, LTO optimization and code generation can modify the symbol table from the bitcode file. It is already the case that symbols can be internalized, removed, backend can also insert new symbols. Unless there is a rule saying LTO passes cannot modify the linkage or visibility or any other attributes to the symbols, linker cannot trust whatever the bitcode symbol table says and firmly it will not be changed for some good reason.
I think this approach is much better. Can you update the title because it is not really a version bump anymore? From my understanding, this is good enough for backwards-compatibility. Thanks!
Feb 15 2018
Generated by mistake. Abandon and I will reformat the patch.
Feb 9 2018
Move the check later so it is only check when needed.
Feb 6 2018
This indeed affects how ld64 interact with libLTO. If user didn't specify a value, ld64 will always call thinlto_codegen_set_cache_pruning_interval with interval 0. This is currently a no-op so it will use whatever the default value in libLTO. With this change, it will be force pruning.
Jan 5 2018
Move STDC pragma handler to parser.
Dec 19 2017
Just a small suggestion. Looks good otherwise.
Dec 15 2017
Other than the comment inline, LGTM.
Dec 13 2017
Dec 8 2017
Nov 9 2017
Add more tests! The new tests can trigger two errors during the compilation
but only one should be emitted.
I think I understand what you mean now. You want some cases when the
compilation doesn't failed on the first source it process.
Nov 6 2017
Update testcase for CUDA driver
Improve testcase according to review feedback.
Add testcase for CUDA driver
This seems to be the cleanest solution I can find for CUDA without
touching the job configuration for CUDA. My proposed fix is to bail
out of the jobs that are parts of CUDA offload if some command failed
before that. Now if you hit failures when compiling multiple GPU
architectures, you will error out only once. This is pretty much the exact
same behavior of current driver.
Nov 2 2017
Fix testcase. My test was passing because files left over from previous run.
Now it should work with a clean build.
Address review feedback.
Nov 1 2017
More background here that doesn't fit in the commit message.
Sep 15 2017
Thanks Hans. Yes, it will be good to pick this up for 5.0.1
Aug 21 2017
Missing one fixup from the previous update. Try again.
Thanks for the feedback. Here is another attempt to modify the module flag in place.
Aug 18 2017
Here is a version that rebuilds the module flags to avoid replaceOperandsWith.
Aug 17 2017
Aug 15 2017
Should we also add this doc update to 5.0 branch?
Aug 10 2017
Yes, this will affect clang-5.0 backward compatibility. Thanks for bringing this up. I was planning to nominate to merge into release branch after this gets reviewed.
Aug 9 2017
May 31 2017
Feb 27 2017
Feb 20 2017
Feb 1 2017
Jan 27 2017
Sorry I just notice that when I look at driver today.
Jan 24 2017
Depending on how you look at the previous commit, you can think that as a new API or just rename the old API. I actually dont think there is too much issue names. Plz go ahead.
Jan 23 2017
I think you should add a new API for embedBitcodeMarkerEnabled() or revert the name the APIs to before https://reviews.llvm.org/rL287084.