Usually dllexported symbols are defined with 'extern "C"',
so identifying them is easy. We can just do hash table lookup
to look up exported symbols.
However, C++ non-member functions are also allowed to be exported,
and they can be specified with unmangled name. So, if /export:foo
is given, we need to look up not only "foo" but also its all
mangled names. In MSVC mangling scheme, that means that we need to
look up any symbol which starts with "?foo@@Y".
In this patch, we scan the entire symbol table to search for
a mangled symbol. The symbol table is a DenseMap, and that doesn't
support table lookup by string prefix. This is of course very
inefficient. But that should be probably OK because the user
should always add 'extern "C"' to dllexported symbols.
llvm-svn: 240919
This option is to ignore remaining undefined symbols and force
the linker to create an output file anyways.
The existing code assumes that there's no undefined symbol after
reportRemainingUndefines(). That assumption is legitimate.
I also don't want to mess up the existing code for this minor feature.
In order to keep it as is, remaining undefined symbols are replaced
with dummy defined symbols.
llvm-svn: 240913
When comparing two COMDAT sections, we need to take section values
and associative sections into account. This patch fixes that bug.
It fixes a crash bug of llvm-tblgen when linked with /opt:lldicf.
One thing I don't understand yet is that this logic seems to be
too strict. MSVC linker is able to create more compact executables
(which of course work correctly). With this ICF algorithm, LLD is
able to make executable smaller, but the outputs are larger than
MSVC's. There must be something I'm missing here.
llvm-svn: 240897
Format @autoreleasepool properly for the Attach brace style
by recognizing @autoreleasepool as a block introducer.
Patch from Strager Neds!
http://reviews.llvm.org/D10372
llvm-svn: 240896
We had a hack in SDAGBuilder in place to work around this but now we
can avoid that. Call BuildExactSDIV from BuildSDIV so DAGCombiner can
perform this trick automatically.
The added check in DAGCombiner is necessary to prevent exact sdiv by pow2
from regressing as the target-specific pow2 lowering is not aware of
exact bits yet.
This is mostly covered by existing tests. One side effect is that we
get the better lowering for exact vector sdivs now too :)
llvm-svn: 240891
the DW_AT_bit_offset computation, the byte offset is in fact also
endian-dependent as it needs to point to the storage unit containing the
most-significant bit of the the bitfield.
I'm so looking forward to emitting the endian-agnostic DWARF 3 version
instead.
llvm-svn: 240890
Summary:
Previously it (incorrectly) used GPR's.
Patch by Simon Dardis. A couple small corrections by myself.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10567
llvm-svn: 240883
ctypes 0.3 and earlier contains an interface-definig bug:
its ptr_of_raw_address accepts Int64 and not Nativeint. ctypes 0.4
was not released during the 3.6 cycle, and because of that, LLVM 3.6
was released with ctypes 0.3 as a dependency, which now breaks
the build on modern ctypes.
Unbreak.
llvm-svn: 240882
Summary:
On PPC64, half the msan tests fail with an infinite recursion through
GetStackTrace like this:
#0 __msan::GetStackTrace
#1 __msan_memcpy
#2 ?? () from /lib64/libgcc_s.so.1
#3 ?? () from /lib64/libgcc_s.so.1
#4 _Unwind_Backtrace
#5 __sanitizer::BufferedStackTrace::SlowUnwindStack
#6 __sanitizer::BufferedStackTrace::Unwind
#7 __msan::GetStackTrace
#8 __interceptor_calloc
#9 _dl_allocate_tls
#10 pthread_create@@GLIBC_2.17
#11 __interceptor_pthread_create
#12 main
The problem is that we call _Unwind_Backtrace to get a stack trace; but
_Unwind_Backtrace calls memcpy, which we intercept and try to get
another stack trace.
This patch fixes it in __msan_memcpy by skipping the stack trace if
IsInSymbolizer(). This works because GetStackTrace already creates a
SymbolizerScope to "block reports from our interceptors during
_Unwind_Backtrace".
Reviewers: samsonov, wschmidt, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10762
llvm-svn: 240878
If we are dealing with a pointer induction variable, isInductionPHI
gives back a step value of Stride / size of pointer. However, we might
be indexing with a legal type wider than the pointer width.
Handle this by inserting casts where appropriate instead of crashing.
This fixes PR23954.
llvm-svn: 240877
The PruneEH pass tries to annotate functions as 'noreturn' if it doesn't
see a ReturnInst. However, a naked function containing inline assembly
can contain control flow leaving the function.
This fixes PR23971.
llvm-svn: 240876
This case had been failing on testers that didn't have x86 support. Rather
than XFAIL it on testers without x86 support, I've just assembled it and used
the raw object as the test input.
llvm-svn: 240875
This function is actually *very* hot. It is hard to see currently
because the call graph is very recursive, but I'm working to remove that
and when I do this function becomes significantly higher on the profile
(up to 5%!) and so worth avoiding the call overhead.
No specific perf gain I can measure yet (below the noise), but likely to
have more impact as we stop cluttering the call graph.
Differential Revision: http://reviews.llvm.org/D10788
llvm-svn: 240873
StringRefs. This uses the LLVM hashing rather than the standard library
and a closed addressed hash table rather than chaining.
This improves the Windows self-link of LLD by 4.4% (averaged over 10
runs, with well under 1% of variance on each).
There is still some room to improve here. Two things I clearly see in
the profile:
1) This is one of the biggest stress tests for the LLVM hashing code. It
actually consumes something like 3-4% of the link time after the
change.
2) The way that StringRef keys are handled in the DenseMap interface is
pretty suboptimal. We pay the price of checking for empty and
tombstone keys when we could only possibly be looking for a normal
key. But fixing this requires invasive API changes.
So there is still some headroom here.
Differential Revision: http://reviews.llvm.org/D10684
llvm-svn: 240871
Summary:
The current implementation doesn't always flush all pending labels
beforeemitting data which can result in an incorrectly placed labels in
case when when instruction bundling is enabled and -mc-relax-all flag is
being used. To address this issue, we always flush pending labels before
emitting data.
The change was tested by running PNaCl toolchain trybots with
-mc-relax-all flag set.
Fixes https://code.google.com/p/nativeclient/issues/detail?id=4063
Test Plan: Regression test attached
Reviewers: mseaborn
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D10325
llvm-svn: 240870
Summary:
Ensure that fragments are bundle aligned when instruction bundling
is enabled and the -mc-relax-all flag is set. This is implicitly
assumed by the bundle padding implementation but this assumption
does not hold when custom alignment is being used.
The change was tested by running PNaCl toolchain trybots with
-mc-relax-all flag set.
Fixes https://code.google.com/p/nativeclient/issues/detail?id=4063
Test Plan: Regression test attached
Reviewers: mseaborn
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D10044
llvm-svn: 240869
There are two main reasons why a linked-list makes sense for
`DIEValueList`.
1. We want `DIE` to be on a `BumpPtrAllocator` to improve teardown
efficiency. Making `DIEValueList` array-based would make that much
more complicated.
2. The singly-linked list is fairly memory efficient. The histogram
[1] shows that most DIEs have relatively few values, so we often pay
less than the 2/3-pointer static overhead of a vector. Furthermore,
we don't know ahead of time exactly how many values a `DIE` needs,
so a vector-like scheme will on average over-allocate by ~50%. As
it happens, that's the same memory overhead as the linked list node.
[1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/085910.html
The comment I added to the code is a little more succinct, but I think
it's enough to give the idea.
llvm-svn: 240868
NAKAMURA Takumi