- Aug 22, 2018
-
-
Dean Michael Berris authored
Summary: This patch moves out the definition of the XRay log file header from binary logs into its own header and implementation file. This is one part of the refactoring being done in D50441. Reviewers: eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51086 llvm-svn: 340389
-
Kirill Bobyrev authored
The wrong diff that was uploaded to Phabricator was building the wrong index. llvm-svn: 340388
-
Rui Ueyama authored
We have an issue with -wrap that the option doesn't work well when renamed symbols get PLT entries. I'll explain what is the issue and how this patch solves it. For one -wrap option, we have three symbols: foo, wrap_foo and real_foo. Currently, we use memcpy to overwrite wrapped symbols so that they get the same contents. This works in most cases but doesn't when the relocation processor sets some flags in the symbol. memcpy'ed symbols are just aliases, so they always have to have the same contents, but the relocation processor breaks that assumption. r336609 is an attempt to fix the issue by memcpy'ing again after processing relocations, so that symbols that are out of sync get the same contents again. That works in most cases as well, but it breaks ASan build in a mysterious way. We could probably fix the issue by choosing symbol attributes that need to be copied after they are updated. But it feels too complicated to me. So, in this patch, I fixed it once and for all. With this patch, we no longer memcpy symbols. All references to renamed symbols point to new symbols after wrapSymbols() is done. Differential Revision: https://reviews.llvm.org/D50569 llvm-svn: 340387
-
Hiroshi Inoue authored
[AST] correct the behavior of -fvisibility-inlines-hidden option (don't make static local variables hidden) The command line option -fvisibility-inlines-hidden makes inlined method hidden, but it is expected not to affect the visibility of static local variables in the function. However, Clang makes the static local variables in the function also hidden as reported in PR37595. This problem causes LLVM bootstarp failure on Fedora 28 if configured with -DBUILD_SHARED_LIBS=ON. This patch makes the behavior of -fvisibility-inlines-hidden option to be consistent with that of gcc; the option does not change the visibility of the static local variables if the containing function does not associated with explicit visibility attribute and becomes hidden due to this option. Differential Revision: https://reviews.llvm.org/D50968 llvm-svn: 340386
-
Marshall Clow authored
Fix Bug 38644: multimap::clear() missing exception specifier. Add noexcept tests for all the containers that have clear(). llvm-svn: 340385
-
Philip Reames authored
llvm-svn: 340384
-
Philip Reames authored
llvm-svn: 340383
-
Philip Reames authored
llvm-svn: 340382
-
Max Kazantsev authored
Guard widening should not spend efforts on dealing with guards with trivial true/false conditions. Such guards can easily be eliminated by any further cleanup pass like instcombine. However we should not unconditionally delete them because it may be profitable to widen other conditions into such guards. Differential Revision: https://reviews.llvm.org/D50247 Reviewed By: fedor.sergeev llvm-svn: 340381
-
Fangrui Song authored
Summary: This is to be consistent with lld behavior since rLLD340364. Reviewers: tejohnson Reviewed By: tejohnson Subscribers: steven_wu, eraman, mehdi_amini, inglorion, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51060 llvm-svn: 340380
-
Vedant Kumar authored
Set a debug location on the cast instruction used to widen a switch condition. llvm-svn: 340379
-
George Karpenkov authored
Differential Revision: https://reviews.llvm.org/D51072 llvm-svn: 340378
-
George Karpenkov authored
Differential Revision: https://reviews.llvm.org/D51071 llvm-svn: 340377
-
Stephen Kelly authored
Reviewers: hans Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51079 llvm-svn: 340376
-
Bob Haarman authored
Summary: Before this change, pruning order was based on size. This changes it to be based on time of last use instead, preferring to keep recently used files and prune older ones. Reviewers: pcc, rnk, espindola Reviewed By: rnk Subscribers: emaste, arichardson, hiraditya, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51062 llvm-svn: 340374
-
Heejin Ahn authored
This should be not 0x3f but 0x40. llvm-svn: 340373
-
Heejin Ahn authored
Summary: We now write back not to memory but to __stack_pointer global. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51074 llvm-svn: 340372
-
Vedant Kumar authored
When splitting a select into a diamond, set debug locations on newly-created branch instructions and phi nodes. llvm-svn: 340371
-
Vedant Kumar authored
CodeGenPrepare has a strategy for moving dbg.values so that a value's definition always dominates its debug users. This cleanup was happening too early (before certain CGP transforms were run), resulting in some dbg.value use-before-def errors. Perform this cleanup as late as possible to avoid use-before-def. llvm-svn: 340370
-
Vedant Kumar authored
This test shows that optimizeSelectInst splits a select and sinks a `fdiv` operation to one side of the diamond. However, the dbg.value for the operation isn't moved. llvm-svn: 340369
-
Vedant Kumar authored
In optimizeSelectInst, when scanning for candidate selects to rewrite into branches, scan past debug intrinsics. This makes the debug-enabled and non-debug paths through optimizeSelectInst more congruent. NFC because every select is eventually visited either way. llvm-svn: 340368
-
Vedant Kumar authored
When optimizing for size, this allows optimizeSelectInst to skip a linear scan and exit early. llvm-svn: 340367
-
Vedant Kumar authored
This is preparation for landing a use-before-def verifier for debug intrinsics (D46100). As a drive-by, remove `tail` from debug intrinsic calls because it doesn't mean anything in that context. llvm-svn: 340366
-
Alina Sbirlea authored
Summary: Extend BasicBlocksUtils to update MemorySSA. Subscribers: sanjoy, arsenm, nhaehnle, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D45300 llvm-svn: 340365
-
Fangrui Song authored
Summary: For -thinlto-object-suffix-replace=old\;new, in tools/gold/gold-plugin.cpp, the thinlto object filename is Path minus optional old suffix. static std::string getThinLTOObjectFileName(StringRef Path, StringRef OldSuffix, StringRef NewSuffix) { if (OldSuffix.empty() && NewSuffix.empty()) return Path; StringRef NewPath = Path; NewPath.consume_back(OldSuffix); std::string NewNewPath = NewPath; NewNewPath += NewSuffix; return NewNewPath; } Currently lld will error that the path does not end with old suffix. This patch makes lld accept such paths but only add new suffix if Path ends with old suffix. This fixes a link error where bitcode members in an archive are regular LTO objects without old suffix. Acording to tejohnson, this will "enable supporting mix and match of minimized ThinLTO bitcode files with normal ThinLTO bitcode files in a single link (where we want to apply the suffix replacement to the minimized files, and just ignore it for the normal ThinLTO files)." Reviewers: ruiu, pcc, tejohnson, espindola Reviewed By: tejohnson Subscribers: emaste, inglorion, arichardson, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51055 llvm-svn: 340364
-
Alina Sbirlea authored
llvm-svn: 340362
-
Richard Trieu authored
Add a missing space when dumping a template argument which is a template expansion. Found during debugging so no test. llvm-svn: 340357
-
Zachary Turner authored
Previously if you had something like this: template<typename T> struct Foo { template<typename U> Foo(U); }; Foo F(3.7); this would mangle as ??$?0N@?$Foo@H@@QEAA@N@Z and this would be demangled as: undname: __cdecl Foo<int>::Foo<int><double>(double) llvm-undname: __cdecl Foo<int>::Foo<int>(double) Note the lack of the constructor template parameter in our demangling. This patch makes it so we print the constructor argument list. llvm-svn: 340356
-
Kuba Mracek authored
On macOS Mojave, the OS started using the XOR-by-a-secret-key scheme (same as glibc is alread doing) for storing the SP value in setjmp environment. We need to adjust for that to keep supporting setjmp/longjmp on latest Darwin. The patch is basically doing the same what we're already doing for glibc. rdar://problem/43542596 Differential Revision: https://reviews.llvm.org/D51064 llvm-svn: 340350
-
Nico Weber authored
EmitX86BuiltinExpr() emits all args into Ops at the beginning, so don't do that work again. This changes behavior: If e.g. ++a was passed as an arg, we incremented a twice previously. This change fixes that bug. https://reviews.llvm.org/D50979 llvm-svn: 340348
-
Kuba Mracek authored
rdar://problem/42242579 llvm-svn: 340347
-
- Aug 21, 2018
-
-
Tom Stellard authored
Summary: Computing the remaining latency can be very expensive especially on graphs of N nodes where the number of edges approaches N^2. This reduces the compile time of a pathological case with the AMDGPU backend from ~7.5 seconds to ~3 seconds. This test case has a basic block with 2655 stores, each with somewhere between 500 and 1500 successors and predecessors. Reviewers: atrick, MatzeB, airlied, mareko Reviewed By: mareko Subscribers: tpr, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D50486 llvm-svn: 340346
-
Philip Reames authored
llvm-svn: 340344
-
Scott Linder authored
In general we can't assume flat loads are uniform, and cases where we can prove they are should be handled through infer-address-spaces. Differential Revision: https://reviews.llvm.org/D50991 llvm-svn: 340343
-
Kuba Mracek authored
The synchronous dispatch functions in GCD (dispatch_sync, dispatch_barrier_sync), don't make a copy of the passed block. To maintain binary compatibility, we should avoid doing that as well in TSan, as there's no reason to do that. The synchronous dispatch functions will not return before the block is actually executed. rdar://problem/42242579 Differential Revision: https://reviews.llvm.org/D50920 llvm-svn: 340342
-
Zachary Turner authored
I found these by running llvm-undname over a couple hundred megabytes of object files generated as part of building chromium. The issues fixed in this patch are: 1) decltype-auto return types. 2) Indirect vtables (e.g. const A::`vftable'{for `B'}) 3) Pointers, references, and rvalue-references to member pointers. I have exactly one remaining symbol out of a few hundred MB of object files that produces a name we can't demangle, and it's related to back-referencing. llvm-svn: 340341
-
Zachary Turner authored
llvm-svn: 340340
-
Heejin Ahn authored
Summary: After the stack is unwound due to a thrown exception, the `__stack_pointer` global can point to an invalid address. This inserts instructions that restore `__stack_pointer` global. Reviewers: jgravelle-google, dschuff Subscribers: mgorny, sbc100, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D50980 llvm-svn: 340339
-
Anna Thomas authored
llvm-svn: 340337
-
Thomas Lively authored
Summary: This CL implements v128.const for each vector type. New operand types are added to ensure the vector contents can be serialized without LEB encoding. Tests are added for instruction selection, encoding, assembly and disassembly. Reviewers: aheejin, dschuff, aardappel Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D50873 llvm-svn: 340336
-