Before this patch, we created an empty PDB file if /debug option is
specified. For MSVC linker, such PDB file is completely broken, and
linker exits without doing anything as soon as it finds an empty PDB
file.
A PDB file created in this patch has the correct file signature.
MSVC linker still thinks that the file is broken, but it then removes
and replaces with its output.
This is an initial patch to support PDB in LLD. We aim to support
PDB in order to make it 100% compatible with MSVC linker. PDB support
is the last missing piece.
llvm-svn: 254796
The issue appears to have been that the copy constructor of the SmallVector was being invoked and this was somehow leading to leaked memory. This patch avoids the symptom, but likely doesn't address the underlying problem. I'm still investigating the root cause, but wanted to avoid the memory leak in the mean time. Even with the underlying fix, avoiding the redundant allocation is worthwhile.
llvm-svn: 254795
When a `SlotIndexes` is destroyed, `ileAllocator` will currently be
destructed before `IndexList`, but all of `IndexList`'s storage has
been allocated by `ileAllocator`. This means we'll call destructors on
garbage data, which is very bad. This can be avoided by putting the
BumpPtrAllocator earlier in the class than anything it allocates.
Unfortunately, I don't know how to test this. It depends very much on
memory layout, and the only evidence I have that this is actually
happening in practice are backtraces that might be explained by this.
By inspection though, the code is obviously dangerous/wrong, and this
is the right thing to do.
I'll follow up later with a patch that calls clearAndLeakNodesUnsafely
on the list, since there isn't much point in destructing them when
they're allocated in a BPA anyway, but I figured it makes sense to
commit the correctness fix separately from that optimization.
llvm-svn: 254794
These instructions are not supported by all CPUs in 64-bit mode. Emitting them
causes Chromium to crash on start-up for users with such chips.
(GCC puts these instructions behind -msahf on 64-bit for the same reason.)
This patch adds FeatureLAHFSAHF, enables it by default for 32-bit targets
and modern CPUs, and changes X86InstrInfo::copyPhysReg back to the lowering
from before r244503 when the instructions are not available.
Differential Revision: http://reviews.llvm.org/D15240
llvm-svn: 254793
This test would fail before if conditional breakpoints weren't
working correctly, and the nature of the test (spinning up 10
threads, etc) opens the door to raciness.
This patch vastly simplifies the test, removes the need for relying
on conditional expression evaluation, and as a result makes the
correctness of the test vastly easier to reason about and reduces
flakiness.
Differential Revision: http://reviews.llvm.org/D15241
Reviewed By: Jim Ingham
llvm-svn: 254792
Summary:
1. Move MSan-specific flags and features from user manual to MSan page.
2. Update current status / list of supported platforms.
Reviewers: eugenis, kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15246
llvm-svn: 254788
System properties are not accessible through NDK (we've been using
hacks to get to them) and they are unavailable during ASan
initialization in .preinit_array. Use environment variables and
files instead (ex. ASAN_OPTIONS=include_if_exists=/path).
No test changes. This feature was not tested because the properties
are system-wide and would conflict with the parallel test runner. Yet
another reason to get rid of it.
llvm-svn: 254783
This brings the timings down for 1500 elements from 166 to 2 seconds on my machine - if I can math correctly, that is a 98% improvement
llvm-svn: 254781
Before this patch the diagnostic handler was optional. If it was not
passed, the one in the LLVMContext was used.
That is probably not a pattern we want to follow. If each area has an
optional callback, there is a sea of callbacks and it is hard to follow
which one is called.
Doing this also found cases where the callback is a nice addition, like
testing that no errors or warnings are reported.
The other option is to always use the diagnostic handler in the
LLVMContext. That has a few problems
* To implement the C API we would have to set the diag handler and then
set it back to the original value.
* Code that creates the context might be far away from code that wants
the diagnostics.
I do have a patch that implements the second option and will send that as
an RFC.
llvm-svn: 254777
Summary:
In order to avoid calling pow function we generate repeated fmul when n is a
positive or negative whole number.
For each exponent we pre-compute Addition Chains in order to minimize the no.
of fmuls.
Refer: http://wwwhomes.uni-bielefeld.de/achim/addition_chain.html
We pre-compute addition chains for exponents upto 32 (which results in a max of
7 fmuls).
For eg:
4 = 2+2
5 = 2+3
6 = 3+3 and so on
Hence,
pow(x, 4.0) ==> y = fmul x, x
x = fmul y, y
ret x
For negative exponents, we simply compute the reciprocal of the final result.
Note: This transformation is only enabled under fast-math.
Patch by Mandeep Singh Grang <mgrang@codeaurora.org>
Reviewers: weimingz, majnemer, escha, davide, scanon, joerg
Subscribers: probinson, escha, llvm-commits
Differential Revision: http://reviews.llvm.org/D13994
llvm-svn: 254776
Summary: Lately, I have submitted a number of patches to fix bugs that
only occurred when using the same pass manager to compile multiple
modules (generally these bugs are failure to reset some persistent
state). Unfortunately I don't think there is currently a way to test
that from the command line. This adds a very simple flag to both llc
and opt, under which the tools will simply re-run their respective
pass pipelines using the same pass manager on (a clone of the same
module). Additionally, we verify that both outputs are bitwise the
same.
Reviewers: yaron.keren
Subscribers: loladiro, yaron.keren, kcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D14965
llvm-svn: 254774
Use proper headling levels in CFI doc. Before that, all sections
were considered a subsection of "Introduction".
Reviewers: pcc, kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15237
llvm-svn: 254771
This probably shouldn't be generated in the .dwo file for CUs, only for
TUs, but it's in the sample .dwos (generated by clang) so dwp should
reflect that.
Arguably the DWP tool could be smart enough to know that the CUs
shouldn't need a debug_line.dwo section and skip that even when it's
legitimately generated for TUs, but that's a bit more off-book.
llvm-svn: 254767
Summary:
With this change the error reported is on the identifier location
itself. It was declaration location before.
Reviewers: alexfh
Differential Revision: http://reviews.llvm.org/D15203
llvm-svn: 254766
Currently `OperandBundleUse::operandsHaveAttr` computes its result
without being given a specific operand. This is problematic because it
forces us to say that, e.g., even non-pointer operands in `"deopt"`
operand bundles are `readonly`, which doesn't make sense.
This commit changes `operandsHaveAttr` to work in the context of a
specific operand, so that we can give the operand attributes that make
sense for the operands's `llvm::Type`.
llvm-svn: 254764
If memory turns out to be a problem, which I don't think it will in practice because all these ValueObjects, we'd be keeping alive anyway, I can always resort to caching the farthest-most iterator only
This gains us an order of magnitude in my benchmark, cutting the time to traverse a 1500-elements list from 22 seconds down to 2
llvm-svn: 254762
The LegacyPassManager was storing an instance of AnalysisUsage for each instance of each pass. In practice, most instances of a single pass class share the same dependencies. We can't rely on this because passes can (and some do) have dynamic dependencies based on instance options.
We can exploit the likely commonality by uniqueing the usage information after querying the pass, but before storing it into the pass manager. This greatly reduces memory consumption by the AnalysisUsage objects. For a long pass pipeline, I measured a decrease in memory consumption for this storage of about 50%. I have not measured on the default O3 pipeline, but I suspect it will see some benefit as well since many passes are repeated (e.g. InstCombine).
Differential Revision: http://reviews.llvm.org/D14677
llvm-svn: 254760
This patch fixes setting breakpoints on symbol for variants of C and
Pascal where the language is "unknown" within the filter-by-language
process added in r252356. It also renames GetLanguageForSymbolByName to
GuessLanguageForSymbolByName and adds comments explaining the pitfalls
of the flawed assumption that the language can be determined solely from
the name and target.
Reviewed by: jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15175
llvm-svn: 254753
After r251874, properties from class extensions no longer show up in
ObjCInterfaceDecl::properties(). Make debug info emission explicitly
look for properties in class extensions before looking at direct properties.
Also add a test that checks for this. There are three interesting cases:
1. A property is only declared in a class extension, and the @implementation
is in a different file. This used to generated a DIObjcProperty before
r251874 and does again with this fix.
2. A property is declared as readonly in the class itself and redeclared as
readwrite in a class extension. clang before r251874 put the DIObjcProperty
on the first declaration. clang after r251874 didn't emit any DIObjcProperty,
and clang with this fix puts it on the readwrite redeclaration (which is
what lookup finds). This seems like a progression.
3. Like 2, but with an @implementation in the same file. In this case,
the property debug info gets generated a second time through the ivar
from the definition. In this case, lookup and declaration code need
to agree on the line number so that the DIObjcProperty isn't emitted
twice. In this case, clang before r251874 emitted one DIObjcProperty
on the first declaration, clang with r251874 emitted one on the second
declaration, and clang with this patch still does the latter.
llvm-svn: 254750
Alexey Samsonov