| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
NVPTXAsmPrinter::doInitialization() was creating an NVPTXSubtarget on
the stack. This object is huge, about 80kb. Also it's slow to create.
And it's all redundant; we have one in NVPTXTargetMachine anyway!
llvm-svn: 349982
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes compiler crash when we attempted to compile this code:
extern __device__ int data;
__device__ int data = 1;
Differential Revision: https://reviews.llvm.org/D56033
llvm-svn: 349981
|
|
|
|
|
|
|
|
|
|
| |
When parsing CU ranges for gdb-index, handle the error (now propagated
up though the API lld is calling here - previously the error was
printed within the libDebugInfo API, not allowing lld to format or
handle the message at all) - including information about the object and
archive name, as well as failing the link.
llvm-svn: 349979
|
|
|
|
|
|
|
|
| |
Propagate the llvm::Error a little further up. This is NFC for
llvm-dwarfdump in this change, but allows ld.lld to emit more precise
error messages about which object and archive the erroneous DWARF is in.
llvm-svn: 349978
|
|
|
|
|
|
|
|
| |
struct/union' on Windows
This warning comes up in the ObjC language plugin because of the use of nameless structs. This change suppresses the warning.
llvm-svn: 349977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The "single parameter" .file directive appears to be an ELF-only feature
that is intended to insert the main source filename into the string
table table.
I noticed that if you assemble an ELF .s file for COFF, typically it
will assert right away on a .file directive near the top of the file. My
first change was to make this emit a proper error in the asm parser so
that we don't assert so easily.
However, COFF actually does have some support for this directive, and if
you emit an object file, llvm-mc does not assert. When emitting a COFF
object, MC will take those file names and create "debug" symbol table
entries for them. I'm not familiar with these kinds of symbol table
entries, and I'm not aware of any users of them, but @compnerd added
them a while ago. They don't introduce absolute paths, and most main
source file paths are short enough that this extra entry shouldn't cause
any problems, so I enabled the flag in MCAsmInfoCOFF that indicates that
it's supported.
This has the side effect of adding an extra debug symbol to every object
produced by clang, which is a pretty big functional change. My question
is, should we keep the functionality or remove it in the name of symbol
table minimalism?
Reviewers: mstorsjo, compnerd
Subscribers: hiraditya, compnerd, llvm-commits
Differential Revision: https://reviews.llvm.org/D55900
llvm-svn: 349976
|
|
|
|
|
|
|
|
| |
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D56030
llvm-svn: 349975
|
|
|
|
|
|
| |
Pointed out by ruiu in rLLD349969
llvm-svn: 349974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added a pair of APIs for encoding/decoding the 3 components of a DWARF discriminator described in http://lists.llvm.org/pipermail/llvm-dev/2016-October/106532.html: the base discriminator, the duplication factor (useful in profile-guided optimization) and the copy index (used to identify copies of code in cases like loop unrolling)
The encoding packs 3 unsigned values in 32 bits. This CL addresses 2 issues:
- communicates overflow back to the user
- supports encoding all 3 components together. Current APIs assume a sequencing of events. For example, creating a new discriminator based on an existing one by changing the base discriminator was not supported.
Reviewers: davidxl, danielcdh, wmi, dblaikie
Reviewed By: dblaikie
Subscribers: zzheng, dmgreen, aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D55681
llvm-svn: 349973
|
|
|
|
|
|
|
|
| |
Using compare is verbose, bug prone and potentially inefficient (because
of early termination). Replace relevant call sites with the (in)equality
operator.
llvm-svn: 349972
|
|
|
|
| |
llvm-svn: 349971
|
|
|
|
|
|
|
|
|
|
| |
Summary: Adding some test coverage while I'm around.
Reviewers: JDevlieghere, aprantl, zturner, clayborg, jingham
Differential Revision: https://reviews.llvm.org/D56017
llvm-svn: 349970
|
|
|
|
|
|
|
|
| |
The latter is what is actually called in the ABI http://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable
Pointed out by rsmith
llvm-svn: 349969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CU is empty (devoid of code addresses)
Originally committed in r349333, reverted in r349353.
GCC emitted these unconditionally on/before 4.4/March 2012
Clang emitted these unconditionally on/before 3.5/March 2014
This improves performance when parsing CUs (especially those using split
DWARF) that contain no code ranges (such as the mini CUs that may be
created by ThinLTO importing - though generally they should be/are
avoided, especially for Split DWARF because it produces a lot of very
small CUs, which don't scale well in a bunch of other ways too
(including size)).
The revert was due to a (Google internal) test that had some checked in old
object files missing DW_AT_ranges. That's since been fixed.
llvm-svn: 349968
|
|
|
|
|
|
|
| |
We already know the final size here so we might as well reserve it so we
don't have to re-allocate during the loop.
llvm-svn: 349967
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For the 2-bit bloom filter, we currently pick the bits Hash%64 and Hash>>6%64 (Shift2=6), but bits [6:...] are also used to select a word, causing a loss of precision.
In this patch, we choose Shift2=26, with is suggested by Ambrose Feinstein.
Note, Shift2 is computed as maskbitslog2 in bfd/elflink.c and gold/dynobj.cc
It is varying with the number of dynamic symbols but we don't
necessarily copy its rule.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55971
llvm-svn: 349966
|
|
|
|
|
|
|
|
|
|
|
| |
Instruction::isLifetimeStartOrEnd() checks whether an Instruction is an
llvm.lifetime.start or an llvm.lifetime.end intrinsic.
This was suggested as a cleanup in D55967.
Differential Revision: https://reviews.llvm.org/D56019
llvm-svn: 349964
|
|
|
|
| |
llvm-svn: 349963
|
|
|
|
|
|
|
|
|
|
|
|
| |
turned the root nodes into one of the flag producing binops.
This fixes the patterns that have or/and as a root. 'and' is handled differently since thy usually have a CMP wrapped around them.
I had to look for uses of the CF flag because all these nodes have non-standard CF flag behavior. A real or/xor would always clear CF. In practice we shouldn't be using the CF flag from these nodes as far as I know.
Differential Revision: https://reviews.llvm.org/D55813
llvm-svn: 349962
|
|
|
|
| |
llvm-svn: 349961
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It should be at the class scope and not inside the `Init(...)` function
because we want to error out as soon as the wrong type is constructed.
At the function scope the `static_assert` is only checked if the
function might be called.
This is a follow up to r349957.
rdar://problem/45284065
llvm-svn: 349960
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It should be at the class scope and not inside the `Init(...)` function
because we want to error out as soon as the wrong type is constructed.
At the function scope the `static_assert` is only checked if the
function might be called.
This is a follow up to r349138.
rdar://problem/45284065
llvm-svn: 349959
|
|
|
|
| |
llvm-svn: 349958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a follow up to https://reviews.llvm.org/D55764 .
For the ASan and LSan allocatorsthe type declarations have been modified
so that it's possible to create a combined allocator type that
consistently uses a different type of `AddressSpaceView`. We intend to
use this in future patches. For the other sanitizers they just use
`LocalAddressSpaceView` by default because we have no plans to use these
allocators in an out-of-process manner.
rdar://problem/45284065
Reviewers: kcc, dvyukov, vitalybuka, cryptoad, eugenis, kubamracek, george.karpenkov, yln
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D55766
llvm-svn: 349957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sign flag is used.
The BEXTR instruction documents the SF bit as undefined.
The TBM BEXTR instruction has the same issue, but I'm not sure how to test it. With the control being an immediate we can determine the sign bit is 0 or the BEXTR would have been removed.
Fixes PR40060
Differential Revision: https://reviews.llvm.org/D55807
llvm-svn: 349956
|
|
|
|
|
|
| |
conventions; NFC.
llvm-svn: 349955
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a follow up patch to r349138.
This patch makes a `AddressSpaceView` a type declaration in the
allocator parameters used by `SizeClassAllocator64`. For ASan, LSan, and
the unit tests the AP64 declarations have been made templated so that
`AddressSpaceView` can be changed at compile time. For the other
sanitizers we just hard-code `LocalAddressSpaceView` because we have no
plans to use these allocators in an out-of-process manner.
rdar://problem/45284065
Reviewers: kcc, dvyukov, vitalybuka, cryptoad, eugenis, kubamracek, george.karpenkov
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D55764
llvm-svn: 349954
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, we'd only match on literal floating or integral zeroes, but I've now also learned that some users spell that value as int{0} or float{0}, which also need to be matched.
Differential Revision: https://reviews.llvm.org/D56012
llvm-svn: 349953
|
|
|
|
|
|
|
|
|
|
| |
It is faster to directly call the ObjC runtime for methods such as retain/release instead of sending a message to those functions.
Differential Revision: https://reviews.llvm.org/D55869
Reviewed By: rjmccall
llvm-svn: 349952
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
negative in Indirect addressing.
Summary:
Don't peel of the offset if the resulting base could possibly be negative in Indirect addressing.
This is because the M0 field is of unsigned.
This patch achieves the similar goal as https://reviews.llvm.org/D55241, but keeps the optimization
if the base is known unsigned.
Reviewers:
arsemn
Differential Revision:
https://reviews.llvm.org/D55568
llvm-svn: 349951
|
|
|
|
|
|
|
|
|
|
|
| |
Weak symbols are supposed to be supported in the ELF TextAPI
implementation, but the YAML handler didn't read or write the `Weak`
member of ELFSymbol. This change adds the YAML mapping and updates tests
to ensure correct behavior.
Differential Revision: https://reviews.llvm.org/D56020
llvm-svn: 349950
|
|
|
|
|
|
|
|
| |
CheckSpecializationInstantiationRedecl
All cases are covered so add an llvm_unreachable. NFC.
llvm-svn: 349949
|
|
|
|
|
|
| |
The "this" capture was removed in r291939.
llvm-svn: 349948
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We already have the negation of that as _LIBCPP_HAS_NONUNIQUE_TYPEINFO.
Having both defined is confusing, since only one of them is used.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54537
llvm-svn: 349947
|
|
|
|
|
|
| |
Skip a number of tests on Windows that are flakey and will pass/fail unexpectedly every dozen or so runs.
llvm-svn: 349946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
BasicAA has special logic for unescaped allocas, which normally applies
equally well to dynamic and static allocas. However, llvm.stackrestore
has the power to end the lifetime of dynamic allocas, without referring
to them directly.
stackrestore is already marked with the most conservative memory
modification attributes, but because the alloca is not escaped, the
normal logic produces incorrect results. I think BasicAA needs a special
case here to teach it about the relationship between dynamic allocas and
stackrestore.
Fixes PR40118
Reviewers: gbiv, efriedma, george.burgess.iv
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D55969
llvm-svn: 349945
|
|
|
|
|
|
|
|
| |
Currently, runtime unrolling does not support loops where multiple
exiting blocks exit to the latchExit. Added TODO and other code
clarifications for ConnectProlog code.
llvm-svn: 349944
|
|
|
|
| |
llvm-svn: 349943
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
removed
Stat cache chaining was implemented for a StatListener in the PTH writer so that
it could write out the stat information to PTH. r348266 removed support for PTH,
and it doesn't seem like there are other uses of stat cache chaining. We can
remove the chaining support.
Differential Revision: https://reviews.llvm.org/D55455
llvm-svn: 349942
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a common error, and because many people don't know what the key
function is, it is sometimes very confusing.
The doc was originally written by Brooks Moses and slightly edited by me.
Reviewers: MaskRay, espindola
Subscribers: emaste, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55968
llvm-svn: 349941
|
|
|
|
|
|
| |
This avoids a potential failed assertion that is happening on someone's out-of-tree build.
llvm-svn: 349940
|
|
|
|
|
|
|
|
|
|
| |
RetainCountChecker on type mismatch even for inlined functions"
This reverts commit b44b33f6e020a2c369da2b0c1d53cd52975f2526.
Revert the revert with the fix.
llvm-svn: 349939
|
|
|
|
|
|
|
|
| |
checker
It should be in the past tense.
llvm-svn: 349938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is admittedly a narrow fix for the problem:
https://bugs.llvm.org/show_bug.cgi?id=37502
...but as the XOP restriction shows, it's a maze to get this right.
In the motivating example, note that we have movddup before SSE4.1 and
again with AVX2. That's because insertps isn't available pre-SSE41 and
vbroadcast is (more generally) available with AVX2 (and the splat is
reduced to movddup via isel pattern).
Differential Revision: https://reviews.llvm.org/D55898
llvm-svn: 349937
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes PR35023.
Reviewers: MatzeB, t.p.northover, sunfish, qcolombet, efriedma
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D55909
llvm-svn: 349935
|
|
|
|
| |
llvm-svn: 349934
|
|
|
|
|
|
| |
All cases are covered so add an llvm_unreachable. NFC.
llvm-svn: 349933
|
|
|
|
| |
llvm-svn: 349932
|
|
|
|
|
|
| |
Completes the work started by @bogner in rL340594.
llvm-svn: 349931
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D55848
llvm-svn: 349930
|