Summary:
Using llvm-style rtti gives us stronger guarantees around casting
LanguageRuntimes.
As discussed in D62755
Differential Revision: https://reviews.llvm.org/D62934
llvm-svn: 362884
This is implemented by the lld-link option -include:, just like
--require-defined. Contrary to --require-defined, the -u/--undefined
option allows the symbol to remain undefined in the end.
This should fix PR42121.
Differential Revision: https://reviews.llvm.org/D62876
llvm-svn: 362882
This works like /include, but is not fatal if the requested symbol
wasn't found. This allows implementing the GNU ld option -u.
Differential Revision: https://reviews.llvm.org/D62976
llvm-svn: 362881
This is 1 step towards correcting our usage of fast-math-flags when applied on an fcmp.
In this case, we are checking for 'nnan' on the fcmp itself rather than the operand of
the fcmp. But I'm leaving that clause in until we're more confident that we can stop
relying on fcmp's FMF.
By using the more general "isKnownNeverNaN()", we gain a simplification shown on the
tests with 'uitofp' regardless of the FMF on the fcmp (uitofp never produces a NaN).
On the tests with 'fabs', we are now relying on the FMF for the call fabs instruction
in addition to the FMF on the fcmp.
I'll update the 'ult' case below here as a follow-up assuming no problems here.
Differential Revision: https://reviews.llvm.org/D62979
llvm-svn: 362879
As suggested in the review for D62949, this patch pre-normalizes the
reference expected output plist files by removing lines containing
fields for which we expect differences that should be ignored.
llvm-svn: 362877
Types such as float and i64's do not have legal loads in Thumb1, but will still
be loaded with a LDR (or potentially multiple LDR's). As such we can treat the
cost of addressing mode calculations the same as an i32 and get some optimisation
benefits.
Differential Revision: https://reviews.llvm.org/D62968
llvm-svn: 362874
Now with MVE being added, we can add the vector addressing mode costs for it.
These are generally imm7 multiplied by the size of the type being loaded /
stored.
Differential Revision: https://reviews.llvm.org/D62967
llvm-svn: 362873
The fp16 version of VLDR takes a imm8 multiplied by 2. This updates the costs
to account for those, and adds extra testing. It is dependant upon hasFPRegs16
as this is what the load/store instructions require.
Differential Revision: https://reviews.llvm.org/D62966
llvm-svn: 362872
We are starting to add an entirely separate vector architecture to the ARM
backend. To do that we need at least some separation between the existing NEON
and the new MVE code. This patch just goes through the Neon patterns and
ensures that they are predicated on HasNEON, giving MVE a stable place to start
from.
No tests yet as this is largely an NFC, and we don't have the other target that
will treat any of these intructions as legal.
Differential Revision: https://reviews.llvm.org/D62945
llvm-svn: 362870
This patch aims to reduce spilling and register moves by using the 3-address
versions of instructions per default instead of the 2-address equivalent
ones. It seems that both spilling and register moves are improved noticeably
generally.
Regalloc hints are passed to increase conversions to 2-address instructions
which are done in SystemZShortenInst.cpp (after regalloc).
Since the SystemZ reg/mem instructions are 2-address (dst and lhs regs are
the same), foldMemoryOperandImpl() can no longer trivially fold a spilled
source register since the reg/reg instruction is now 3-address. In order to
remedy this, new 3-address pseudo memory instructions are used to perform the
folding only when the dst and lhs virtual registers are known to be allocated
to the same physreg. In order to not let MachineCopyPropagation run and
change registers on these transformed instructions (making it 3-address), a
new target pass called SystemZPostRewrite.cpp is run just after
VirtRegRewriter, that immediately lowers the pseudo to a target instruction.
If it would have been possibe to insert a COPY instruction and change a
register operand (convert to 2-address) in foldMemoryOperandImpl() while
trusting that the caller (e.g. InlineSpiller) would update/repair the
involved LiveIntervals, the solution involving pseudo instructions would not
have been needed. This is perhaps a potential improvement (see Phabricator
post).
Common code changes:
* A new hook TargetPassConfig::addPostRewrite() is utilized to be able to run a
target pass immediately before MachineCopyPropagation.
* VirtRegMap is passed as an argument to foldMemoryOperand().
Review: Ulrich Weigand, Quentin Colombet
https://reviews.llvm.org/D60888
llvm-svn: 362868
I've change the variable names used in PPC64.cpp from "Instr" to "Insn"
because "Insn" is a more common abbreviation for "instruction".
While changing PPC64.cpp relocateOne(), make R_PPC64_ADDR16_LO{_DS}
slightly more efficient by saving a read and a write for the TocOptimize
case.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63043
llvm-svn: 362867
std::function uses a standard allocator to manage its memory, however
standard allocators are templates and using them correctly requires
a stupid amount of instantiations. This leads to a substantial increase
in debug info and object sizes.
This patch addresses the issue by dropping the allocator when possible
and using raw new and delete to get memory.
This change decreases the object file size for the test func.wrap.func.con/F.pass.cpp by 33% and the final binary by 29% (when compiled with -g -ggnu-pubnames -gpubnames).
It also roughly halfs the number of entries in the pubnames and pubtype
sections.
llvm-svn: 362865
Summary:
Recompute and update offset/size fields so that we can implement llvm-objcopy options like --only-section.
This patch is the first step and focuses on supporting load commands that covered by existing tests: executable files and
dynamic libraries are not supported.
Reviewers: alexshap, rupprecht, jhenderson
Reviewed By: alexshap, rupprecht
Subscribers: compnerd, jakehehrlich, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62652
llvm-svn: 362863
This reverts commit 58afc1bdebf9fa8b178d6c9d89af94c5cc091760.
This commit caused the test suite on macOS to fail many tests. It
appears that setting breakpoints is the issue. One example that fails
is the lit test Breakpoint/case-sensitive.test.
llvm-svn: 362862
Visualizer for the simple case of APInt (uints < 2^64)
as will be required for Clang ConstantArrayType visualizer.
Also, removed obsolete VS2013 SmallVectorVisualizer as VS2013
is no longer supported.
llvm-svn: 362860
In order for GlobalISel to re-use the significant amount of analysis and
optimization code in SDAG's switch lowering, we first have to extract it and
create an interface to be used by both frameworks.
No test changes as it's NFC.
Differential Revision: https://reviews.llvm.org/D62745
llvm-svn: 362857
Seems like a logical extension to me - and of interest because it might
help reduce the debug info size of libc++ by applying this attribute to
type traits that have a disproportionate debug info cost compared to the
benefit (& possibly harm/confusion) they cause users.
llvm-svn: 362856
Summary:
We're using the clang static analyzer together with a number of
custom analyses in our CI system to ensure that certain invariants
are statiesfied for by the code every commit. Unfortunately, there
currently doesn't seem to be a good way to determine whether any
analyzer warnings were emitted, other than parsing clang's output
(or using scan-build, which then in turn parses clang's output).
As a simpler mechanism, simply add a `-analyzer-werror` flag to CC1
that causes the analyzer to emit its warnings as errors instead.
I briefly tried to have this be `Werror=analyzer` and make it go
through that machinery instead, but that seemed more trouble than
it was worth in terms of conflicting with options to the actual build
and special cases that would be required to circumvent the analyzers
usual attempts to quiet non-analyzer warnings. This is simple and it
works well.
Reviewed-By: NoQ, Szelethusw
Differential Revision: https://reviews.llvm.org/D62885
llvm-svn: 362855
Summary: Move some code around, in preparation for later fixes
to the non-integral addrspace handling (D59661)
Patch By Jameson Nash <jameson@juliacomputing.com>
Reviewed By: reames, loladiro
Differential Revision: https://reviews.llvm.org/D59729
llvm-svn: 362853
Summary:
When handling exports from the command line or from .def files, the
linker does a "fuzzy" string lookup to allow finding mangled symbols.
However, when the symbol is re-exported under a new name, the linker has
to transfer the decorations from the exported symbol over to the new
name. This is implemented by taking the mangled symbol that was found in
the object and replacing the original symbol name with the export name.
Before this patch, LLD implemented the fuzzy search by adding an
undefined symbol with the unmangled name, and then during symbol
resolution, checking if similar mangled symbols had been added after the
last round of symbol resolution. If so, LLD makes the original symbol a
weak alias of the mangled symbol. Later, to get the original symbol
name, LLD would look through the weak alias and forward it on to the
import library writer, which copies the symbol decorations. This
approach doesn't work when bar is itself a weak alias, as is the case in
asan. It's especially bad when the aliasee of bar contains the string
"bar", consider "bar_default". In this case, we would end up exporting
the symbol "foo_default" when we should've exported just "foo".
To fix this, don't look through weak aliases to find the mangled name.
Save the mangled name earlier during fuzzy symbol lookup.
Fixes PR42074
Reviewers: mstorsjo, ruiu
Subscribers: thakis, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62984
llvm-svn: 362849
Add docs (llvm-lipo.rst) for llvm-lipo.
Test plan:
make -j8 sphinx
check that ./docs/html/CommandGuide/llvm-lipo.html is built correctly and looks okay.
Differential revision: https://reviews.llvm.org/D62706
llvm-svn: 362848
Summary:
This fixes the bugzilla id,41862 to support dealing with checking
stop address against start address to support this not being a
proper object to check the disasembly against like gnu objdump
currently does.
Reviewers: jakehehrlich, rupprecht, echristo, jhenderson, grimar
Reviewed By: jhenderson
Subscribers: MaskRay, smeenai, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61969
Patch by Nicholas Krause!
llvm-svn: 362847
In LLDB, where tests run with the debug version of Python, we get a
series of deprecation warnings because escape sequences like `\(` are
being treated as part of the string literal rather than an escape for
the regexp pattern.
NFC intended.
Differential Revision: https://reviews.llvm.org/D62882
llvm-svn: 362846
Problem discovered in the breakpoint lit test, but probably exists in others.
lldb-test splits lines on LF. Input files that are CR+LF separated (as is
common on Windows) then resulted in commands being sent to LLDB that ended
in CR, which confused the command interpreter.
This could be fixed at different levels:
1. Treat '\r' like a tab or space in the argument splitter.
2. Fix the line splitters (plural) in lldb-test.
3. Normalize the test files to LF only.
If we did only 3, I'd expect similar problems to recur, so this patch does
1 and 2. I may also do 3 in a separate patch later, but that's tricky
because I believe we have some input files that MUST use CR+LF.
Differential Revision: https://reviews.llvm.org/D62759
llvm-svn: 362844
lldb/lit/SymbolFile/DWARF/debug-types-expressions.test fails with msan.
This change fixes the issue by ensuring FileNameEntry::checksum is
always default-initialized.
llvm-svn: 362843
Summary:
Longstanding issues in the Android test runner means that compiler-rt unit
tests don't work on Android due to libc++ link-time issues. Looks like the
exported libc++ from the Android NDK is x86-64, even though it's part of the
ARM[64] toolchain... See similar measures for ASan and sanitizer-common that
disable unit tests for Android.
Should fully fix the Android bots (@vlad.tsyrklevich).
Reviewers: vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, kubamracek, mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits, vlad.tsyrklevich
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D63019
llvm-svn: 362842
Displays the architecture names of an input file.
Unknown architectures are represented by unknown(cputype,cpusubtype).
Patch by Anusha Basana <anusha.basana@gmail.com>
Differential Revision: https://reviews.llvm.org/D62753
llvm-svn: 362840
Summary:
The cleanup in D62751 introduced a compile-time regression due to the way DT updates are performed.
Add all insert edges then all delete edges in DTU to match the previous compile time.
Compile time on the test provided by @mstorsjo before and after this patch on my machine:
113.046s vs 35.649s
Repro: clang -target x86_64-w64-mingw32 -c -O3 glew-preproc.c; on https://martin.st/temp/glew-preproc.c.
Reviewers: kuhar, NutshellySima, mstorsjo
Subscribers: jlebar, mstorsjo, dmgreen, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62981
llvm-svn: 362839
Kristof Umann