| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 270773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Getting accurate locations for loops is important, because those locations are
used by the frontend to generate optimization remarks. Currently, optimization
remarks for loops often appear on the wrong line, often the first line of the
loop body instead of the loop itself. This is confusing because that line might
itself be another loop, or might be somewhere else completely if the body was
an inlined function call. This happens because of the way we find the loop's
starting location. First, we look for a preheader, and if we find one, and its
terminator has a debug location, then we use that. Otherwise, we look for a
location on an instruction in the loop header.
The fallback heuristic is not bad, but will almost always find the beginning of
the body, and not the loop statement itself. The preheader location search
often fails because there's often not a preheader, and even when there is a
preheader, depending on how it was formed, it sometimes carries the location of
some preceeding code.
I don't see any good theoretical way to fix this problem. On the other hand,
this seems like a straightforward solution: Put the debug location in the
loop's llvm.loop metadata. When emitting debug information, this commit causes
us to add the debug location as an operand to each loop's llvm.loop metadata.
Thus, we now generate this metadata for all loops (not just loops with
optimization hints) when we're otherwise generating debug information.
The remark test case changes depend on the companion LLVM commit r270771.
llvm-svn: 270772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Getting accurate locations for loops is important, because those locations are
used by the frontend to generate optimization remarks. Currently, optimization
remarks for loops often appear on the wrong line, often the first line of the
loop body instead of the loop itself. This is confusing because that line might
itself be another loop, or might be somewhere else completely if the body was
inlined function call. This happens because of the way we find the loop's
starting location. First, we look for a preheader, and if we find one, and its
terminator has a debug location, then we use that. Otherwise, we look for a
location on an instruction in the loop header.
The fallback heuristic is not bad, but will almost always find the beginning of
the body, and not the loop statement itself. The preheader location search
often fails because there's often not a preheader, and even when there is a
preheader, depending on how it was formed, it sometimes carries the location of
some preceeding code.
I don't see any good theoretical way to fix this problem. On the other hand,
this seems like a straightforward solution: Put the debug location in the
loop's llvm.loop metadata. A companion Clang patch will cause Clang to insert
llvm.loop metadata with appropriate locations when generating debugging
information. With these changes, our loop remarks have much more accurate
locations.
Differential Revision: http://reviews.llvm.org/D19738
llvm-svn: 270771
|
|
|
|
|
|
| |
the creation of synthetic children
llvm-svn: 270770
|
|
|
|
| |
llvm-svn: 270769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|