User Details
- User Since
- Dec 28 2012, 2:34 PM (495 w, 6 d)
Fri, Jun 24
Thu, Jun 23
Comment
LGTM
Wed, Jun 15
LGTM
Okay, it seems reasonable enough to have the [[clang::lto_visibility_public]] attribute override the --lto-whole-program-visibility flag.
I don't think I would expect the stage 2 runtimes to be built with a sanitizer even if use_asan is set. The sanitizer runtimes themselves don't support being built with sanitizers, and they might be compiled to depend on the builtins, which would create a circular dependency. So I think use_asan and such should only affect the stage 1 compiler. I think I would favor adding use_asan = false to the stage2_unix_toolchain template.
This diverges from the documented behavior of -lto-whole-program-visibility. The flag is meant to give all classes hidden LTO visibility, but now it only does that to some of them.
Tue, Jun 14
Mon, Jun 13
Fix Mac build
Stop sync_source_lists_from_cmake.py from finding the reference to the source file
Fri, Jun 10
Thu, Jun 9
Wed, Jun 8
Thanks for the reproducer!
Sun, Jun 5
Thu, Jun 2
Doesn't it also need to be removed from the list in llvm/lib/Target/AArch64/AArch64.td?
May 25 2022
This case is supposed to be handled as a result of running the WPD pass early. See the comment near the top of PassBuilder::buildThinLTODefaultPipeline:
// These passes import type identifier resolutions for whole-program // devirtualization and CFI. They must run early because other passes may // disturb the specific instruction patterns that these passes look for, // creating dependencies on resolutions that may not appear in the summary. // // For example, GVN may transform the pattern assume(type.test) appearing in // two basic blocks into assume(phi(type.test, type.test)), which would // transform a dependency on a WPD resolution into a dependency on a type // identifier resolution for CFI. // // Also, WPD has access to more precise information than ICP and can // devirtualize more effectively, so it should operate on the IR first. // // The WPD and LowerTypeTest passes need to run at -O0 to lower type // metadata and intrinsics.
Is there some way that we can now end up with GVN or some other such pass running between when we create the summary and when we run WPD that's inserting a phi?
May 16 2022
May 13 2022
May 12 2022
May 2 2022
Ping.
Apr 28 2022
Apr 22 2022
LGTM
Apr 21 2022
Apr 19 2022
I think this will introduce a correctness issue as it will become possible for two modules that can be linked together to have the same unique module ID.
Apr 18 2022
Apr 12 2022
LGTM but please add a test for the autoupgrader.
Apr 11 2022
Can we add logic to llvm/lib/IR/AutoUpgrade.cpp to change Error to Min if we see one of these module flags? I think that should allow old bitcode to continue working.
Apr 7 2022
Note that if additional data has been injected between the KCFI
type identifier and the start of the function, e.g. by using
-fpatchable-function-entry, the offset in bytes must be specified
using -fsanitize-kcfi-offset=<value> to avoid errors. The offset
must be the same for all indirectly called functions in every
translation unit.
Apr 6 2022
Apr 5 2022
IIRC 1 << 21 was from COFF (missed that the addend was signed), so it wouldn't make sense to have this be 1 << 21 on other object formats if the actual limit is higher.
Mar 31 2022
Mar 15 2022
Mar 14 2022
LGTM
Mar 8 2022
Mar 2 2022
Feb 17 2022
Use isARM() etc
Feb 14 2022
On the bug you have:
define internal fastcc void @​_Z4callIiE4taskv.resume(%_Z4callIiE4taskv.Frame* noalias nonnull align 8 dereferenceable(24 ) %FramePtr) #​1 prologue <{ i32, i32 }> <{ i32 846595819, i32 trunc (i64 sub (i64 ptrtoint (i8** @​1 to i64), i64 ptrtoint (void ()* @​_Z4callIiE4taskv to i64)) to i32) }> {...}
Is it possible for the C/C++ code to take the address of the function _Z4callIiE4taskv.resume and call it indirectly? If not, it seems like the right fix would be to arrange for the prologue data to be dropped on the .resume function instead of duplicating it there. I would also imagine that whatever signature you have on the .resume function would be incorrect since it appears that the coro splitting pass will use a different function signature for that function.
Feb 11 2022
I suspect the real issue is that we're missing #include <stddef.h> at the top of this file. What happens if you add that and don't std qualify everything?
In addition to the .bc support we will also need support for reading/writing .ll files.
Feb 9 2022
Make it conditional