| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since r268966 the modern Verifier pass defaults to stripping invalid debug info
in nonasserts builds. This patch ports this behavior back to the legacy
Verifier pass as well. The primary motivation is that the clang frontend
accepts bitcode files as input but is still using the legacy pass pipeline.
Background: The problem I'm trying to solve with this sequence of patches is
that historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about breaking
bitcode compatibility with existing producers. For example, we don't necessarily
want IR produced by an older version of clang to be rejected by an LTO link just
because of malformed debug info, and rather provide an option to strip it. Note
that merely outdated (but well-formed) debug info would continue to be
auto-upgraded in this scenario.
http://reviews.llvm.org/D20629
<rdar://problem/26448800>
llvm-svn: 270768
|
| |
|
|
|
|
| |
Equivalent tests included in sse41-intrinsics-x86-upgrade.ll - the i8/i32 immediate diff doesn't matter anymore
llvm-svn: 270767
|
| |
|
|
| |
llvm-svn: 270766
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inference in LTO pipeline.
As a result of D18634 we no longer infer certain attributes on linkonce_odr
functions at compile time, and may only infer them at LTO time. The readnone
attribute in particular is required for virtual constant propagation (part
of whole-program virtual call optimization) to work correctly.
This change moves the whole-program virtual call optimization pass after
the function attribute inference passes, and enables the attribute inference
passes at opt level 1, so that virtual constant propagation has a chance to
work correctly for linkonce_odr functions.
Differential Revision: http://reviews.llvm.org/D20643
llvm-svn: 270765
|
| |
|
|
| |
llvm-svn: 270764
|
| |
|
|
|
|
| |
My script missed those in r270750.
llvm-svn: 270763
|
| |
|
|
|
|
|
|
|
| |
The max warning check was masking the "return 0" codepath.
See the thread "Warnings and compile-time failure on 458.sjeng" for more
info.
llvm-svn: 270762
|
| |
|
|
|
|
| |
Equivalent tests included in sse41-intrinsics-x86-upgrade.ll
llvm-svn: 270761
|
| |
|
|
| |
llvm-svn: 270760
|
| |
|
|
|
|
|
|
|
|
| |
It may materialize a declaration, or a definition. The name could
be misleading. This is following a merge of materializeInitFor()
into materializeDeclFor().
Differential Revision: http://reviews.llvm.org/D20593
llvm-svn: 270759
|
| |
|
|
|
|
|
|
|
|
|
|
| |
They were originally separated to handle the co-recursion between
the ValueMapper and the ValueMaterializer. This recursion does not
exist anymore: the ValueMapper now uses a Worklist and the
ValueMaterializer is scheduling job on the Worklist.
Differential Revision: http://reviews.llvm.org/D20593
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 270758
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This test was hitting an assertion in the value mapper because
the IRLinker was trying to map two times @A while materializing
the initializer for @C.
Fix http://llvm.org/PR27850
Differential Revision: http://reviews.llvm.org/D20586
llvm-svn: 270757
|
| |
|
|
| |
llvm-svn: 270756
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20641
llvm-svn: 270755
|
| |
|
|
|
|
|
|
|
| |
definitions as declarations (PR27810, PR27811)"
It seems to have broken the sanitizer-windows bot.
Reverting while investigating.
llvm-svn: 270754
|
| |
|
|
| |
llvm-svn: 270753
|
| |
|
|
|
|
|
|
| |
unordered_map more than once in a stop due to the synthetic provider not properly caching the ValueObjects it was returning for the child elements
Fixes rdar://26470909
llvm-svn: 270752
|
| |
|
|
|
|
|
|
|
|
| |
We have need to reuse this functionality, including making
additional generic stream types that are smarter about how and
when they copy memory versus referencing the original memory.
So all of these structures belong in the common library
rather than being pdb specific.
llvm-svn: 270751
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There was a typo in r267758. It caused invalid accesses when
given something like "void @free(...)", as NumParams == 0, and
we then try to look at the 0th parameter.
Turns out, most of these were untested; add both attribute
and missing-prototype checks for all libc libfuncs.
Differential Revision: http://reviews.llvm.org/D20543
llvm-svn: 270750
|
| |
|
|
| |
llvm-svn: 270749
|
| |
|
|
|
|
|
|
|
|
|
| |
declarations (PR27810, PR27811)
This matches what MSVC does, and should make compiles faster by avoiding to
unnecessarily emit a lot of code.
Differential Revision: http://reviews.llvm.org/D20608
llvm-svn: 270748
|
| |
|
|
| |
llvm-svn: 270747
|
| |
|
|
| |
llvm-svn: 270746
|
| |
|
|
|
|
|
|
| |
TestCallUserAnonTypedef.py and TestIRInterpreter.py fail to limitation of JIT expressions in handling hard float ABI targets.
TestBSDArchives.py fails due to python unicode error.
TestBuiltinTrap.py fails due to wrong line information generated by some gcc versions.
llvm-svn: 270745
|
| |
|
|
| |
llvm-svn: 270744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is probably correct for all uses except cross-module IR linking,
where we need to move the comdat from the source module to the
destination module.
Fixes PR27870.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D20631
llvm-svn: 270743
|
| |
|
|
|
|
| |
Dumping it as ASCII makes it fairly useless.
llvm-svn: 270742
|
| |
|
|
| |
llvm-svn: 270741
|
| |
|
|
|
|
|
| |
These operations tend to get promoted away to v4i32 so
this doesn't happen often.
llvm-svn: 270740
|
| |
|
|
|
|
| |
Also un xfail a test.
llvm-svn: 270739
|
| |
|
|
| |
llvm-svn: 270738
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adds cache_frag.h and cache_frag.cpp for the cache fragmentation tool.
Updates test struct-simple.cpp.
Reviewers: aizatsky
Subscribers: filcab, zhaoqin, llvm-commits, eugenis, vitalybuka, kcc, bruening, kubabrecka
Differential Revision: http://reviews.llvm.org/D20538
llvm-svn: 270737
|
| |
|
|
|
|
| |
Simplifies test updates in the future.
llvm-svn: 270736
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing pthread detection code in __config is pretty good for
common operating systems. It doesn't allow cmake-time choices to be
made for uncommon operating systems though.
This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns
into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is
a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests
want __config_site.in variables to have a _LIBCPP_HAS prefix.
http://reviews.llvm.org/D20573
llvm-svn: 270735
|
| |
|
|
|
|
|
| |
While here, convert the logic of the pass to use static function(s).
This is in preparation for porting this pass to the new PM.
llvm-svn: 270734
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building libcxxabi in tree (i.e. in llvm/projects/libcxxabi,
along with llvm/projects/libcxx), libcxx's config_site.in doesn't
get created in a timely manner. This means that any configuration
that is normally set in libcxx's config_site.in needs to be
duplicated in libcxxabi to successfully build libcxxabi. This patch
does exactly that for the _LIBCPP_HAS_THREAD_API_PTHREAD
preprocessor define.
http://reviews.llvm.org/D20574
llvm-svn: 270732
|
| |
|
|
|
|
|
|
|
| |
f32 vectors would use a sequence of BFI instructions instead
of unrolled cmp + select. This was better in the case of a VALU
select with SGPR inputs, but we don't have a way of dealing with that
in the DAG.
llvm-svn: 270731
|
| |
|
|
|
|
| |
Also get rid of the redundant strncpy calls.
llvm-svn: 270730
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
By making pointer extraction from a vector more expensive in the cost model,
we avoid the vectorization of a loop that is very likely to be memory-bound:
https://llvm.org/bugs/show_bug.cgi?id=27826
There are still bugs related to this, so we may need a more general solution
to avoid vectorizing obviously memory-bound loops when we don't have HW gather
support.
Differential Revision: http://reviews.llvm.org/D20601
llvm-svn: 270729
|
| |
|
|
| |
llvm-svn: 270728
|
| |
|
|
| |
llvm-svn: 270727
|
| |
|
|
| |
llvm-svn: 270726
|
| |
|
|
|
|
| |
This is the first bit of support for MachO __LINKEDIT segment data.
llvm-svn: 270724
|
| |
|
|
|
|
| |
This should actually address PR27855. This results in adding references to the system libs inside generated dylibs so that they get correctly pulled in when linking against the dylib.
llvm-svn: 270723
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20311
llvm-svn: 270722
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX are used.
D15779 introduced basic approach to support new relaxations.
This patch implements relaxations for jmp and call instructions,
described in System V Application Binary Interface AMD64 Architecture Processor
Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf,
B.2 "B.2 Optimize GOTPCRELX Relocations")
Differential revision: http://reviews.llvm.org/D20622
llvm-svn: 270721
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LegalizeIntegerTypes does not have a way to expand multiplications for large
integer types (i.e. larger than twice the native bit width). There's no
standard runtime call to use in that case, and so we'd just assert.
Unfortunately, as it turns out, it is possible to hit this case from
standard-ish C code in rare cases. A particular case a user ran into yesterday
involved an __int128 induction variable and a loop with a quadratic (not
linear) recurrence which triggered some backend logic using SCEVExpander. In
this case, the BinomialCoefficient code in SCEV generates some i129 variables,
which get widened to i256. At a high level, this is not actually good (i.e. the
underlying optimization, PPCLoopPreIncPrep, should not be transforming the loop
in question for performance reasons), but regardless, the backend shouldn't
crash because of cost-modeling issues in the optimizer.
This is a straightforward implementation of the multiplication expansion, based
on the algorithm in Hacker's Delight. I validated it against the code for the
mul256b function from http://locklessinc.com/articles/256bit_arithmetic/ using
random inputs. There should be no functional change for previously-working code
(the new expansion code only replaces an assert).
Fixes PR19797.
llvm-svn: 270720
|
| |
|
|
|
|
|
| |
There aren't any checks with prefix PROMOTE, should be PROMOTE_MOD1
which wasn't being tested (but works as expected).
llvm-svn: 270719
|
| |
|
|
|
|
|
|
|
|
| |
VZeroUpperInserter pass (PR27823)
As noted in the review, there are still problems, so this doesn't the bug completely.
Differential Revision: http://reviews.llvm.org/D20529
llvm-svn: 270718
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch makes SectionPiece class 8 bytes smaller on platforms
on which pointer size is 8 bytes. Sean suggested in a post commit
review for r270340 that this could make a differentce, and it
actually is. Time to link clang (with debug info) improved from
6.725 seconds to 6.589 seconds or by about 2%.
Differential Revision: http://reviews.llvm.org/D20613
llvm-svn: 270717
|