| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
* Add CUs to the named CU node
* Add missing DW_TAG_subprogram nodes
* Add llvm::Functions to the DW_TAG_subprogram nodes
This cleans up the tests so that they don't break under a
soon-to-be-made change that is more strict about such things.
llvm-svn: 213951
|
| |
|
|
|
|
| |
Add myself as the code owner for the scoped-noalias metadata I've developed.
llvm-svn: 213950
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This functionality is currently turned off by default.
Part of the motivation for introducing scoped-noalias metadata is to enable the
preservation of noalias parameter attribute information after inlining.
Sometimes this can be inferred from the code in the caller after inlining, but
often we simply lose valuable information.
The overall process if fairly simple:
1. Create a new unqiue scope domain.
2. For each (used) noalias parameter, create a new alias scope.
3. For each pointer, collect the underlying objects. Add a noalias scope for
each noalias parameter from which we're not derived (and has not been
captured prior to that point).
4. Add an alias.scope for each noalias parameter from which we might be
derived (or has been captured before that point).
Note that the capture checks apply only if one of the underlying objects is not
an identified function-local object.
llvm-svn: 213949
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the process of fixing the noalias parameter -> metadata conversion process
that will take place during inlining (which will be committed soon, but not
turned on by default), I have come to realize that the semantics provided by
yesterday's commit are not really what we want. Here's why:
void foo(noalias a, noalias b, noalias c, bool x) {
*q = x ? a : b;
*c = *q;
}
Generically, we know that *c does not alias with *a and with *b (so there is an
'and' in what we know we're not), and we know that *q might be derived from *a
or from *b (so there is an 'or' in what we know that we are). So we do not want
the semantics currently, where any noalias scope matching any alias.scope
causes a NoAlias return. What we want to know is that the noalias scopes form a
superset of the alias.scope list (meaning that all the things we know we're not
is a superset of all of things the other instruction might be).
Making that change, however, introduces a composibility problem. If we inline
once, adding the noalias metadata, and then inline again adding more, and we
append new scopes onto the noalias and alias.scope lists each time. But, this
means that we could change what was a NoAlias result previously into a MayAlias
result because we appended an additional scope onto one of the alias.scope
lists. So, instead of giving scopes the ability to have parents (which I had
borrowed from the TBAA implementation, but seems increasingly unlikely to be
useful in practice), I've given them domains. The subset/superset condition now
applies within each domain independently, and we only need it to hold in one
domain. Each time we inline, we add the new scopes in a new scope domain, and
everything now composes nicely. In addition, this simplifies the
implementation.
llvm-svn: 213948
|
| |
|
|
|
|
|
|
|
|
|
| |
The dragonegg buildbot (and others?) started failing after
r213945/r213946 because `llvm-as` wasn't linking in the bitcode reader.
I think moving the verify functions to the same file as the verify pass
should fix the build. Adding a command-line option for maintaining
use-list order in assembly as a drive-by to prevent warnings about
unused static functions.
llvm-svn: 213947
|
| |
|
|
| |
llvm-svn: 213946
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a -verify-use-list-order pass, which shuffles use-list order, writes
to bitcode, reads back, and verifies that the (shuffled) order matches.
- The utility functions live in lib/IR/UseListOrder.cpp.
- Moved (and renamed) the command-line option to enable writing
use-lists, so that this pass can return early if the use-list orders
aren't being serialized.
It's not clear that this pass is the right direction long-term (perhaps
a separate tool instead?), but short-term it's a great way to test the
use-list order prototype. I've added an XFAIL-ed testcase that I'm
hoping to get working pretty quickly.
This is part of PR5680.
llvm-svn: 213945
|
| |
|
|
|
|
|
|
| |
Patch by Ben Foster!
Differential Revision: http://reviews.llvm.org/D4657
llvm-svn: 213944
|
| |
|
|
|
|
| |
Now that it become faster, it's OK to query it every 100ms again.
llvm-svn: 213943
|
| |
|
|
|
|
|
|
| |
It is currently broken because it reads a wrong value from profile (heap instead of total).
Also make it faster by reading /proc/self/statm. Reading of /proc/self/smaps
can consume more than 50% of time on beefy apps if done every 100ms.
llvm-svn: 213942
|
| |
|
|
|
|
|
|
| |
initialization takes place on FreeBSD
Differential Revision: http://reviews.llvm.org/D4496
llvm-svn: 213941
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4656
llvm-svn: 213940
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 213938
|
| |
|
|
|
|
|
| |
directories description. Released version of this toolchain has not separate
libraries for -mfp64 command line option.
llvm-svn: 213937
|
| |
|
|
|
|
| |
be disabled in CMake or relocated if desired.
llvm-svn: 213936
|
| |
|
|
|
|
|
|
| |
Specifically the part where we removed a warning to be compatible with GCC, which has been widely regarded as a bad idea.
I'm not quite happy with how obtuse this warning is, especially in the fairly common case of a 32-bit integer literal, so I've got another patch awaiting review that adds a fixit to reduce confusion.
llvm-svn: 213935
|
| |
|
|
|
|
| |
targeting *-win32.
llvm-svn: 213933
|
| |
|
|
|
|
| |
It sometimes confuses FileCheck. Consider the case that path contains 'stmib'. :)
llvm-svn: 213932
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SDValues, fixing the two bugs left in the regression suite.
The key for both of these was the use a single value type rather than
a VTList which caused an unintentionally single-result merge-value node.
Fix this by getting the appropriate VTList in place.
Doing this exposed that the comments in x86's code abouth how MUL_LOHI
operands are handle is wrong. The bug with the use of out-of-range
result numbers was hiding the bug about the order of operands here (as
best i can tell). There are more places where the code appears to get
this backwards still...
llvm-svn: 213931
|
| |
|
|
|
|
|
| |
doesn't actually correspond to an SDValue at all. Fixes most of the
remaining asserts on out-of-range SDValue result numbers.
llvm-svn: 213930
|
| |
|
|
|
|
| |
(despite it's deprecated on Linux) to remove the ifdefs.
llvm-svn: 213929
|
| |
|
|
| |
llvm-svn: 213928
|
| |
|
|
| |
llvm-svn: 213927
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
with a result number outside the range of results for the node.
I don't know how we managed to not really check this very basic
invariant for so long, but the code is *very* broken at this point.
I have over 270 test failures with the assert enabled. I'm committing it
disabled so that others can join in the cleanup effort and reproduce the
issues. I've also included one of the obvious fixes that I already
found. More fixes to come.
llvm-svn: 213926
|
| |
|
|
|
|
| |
directives.
llvm-svn: 213925
|
| |
|
|
|
|
|
|
|
|
|
|
| |
assembly instructions.
This is necessary to ensure ARM assembler switches to Thumb mode before it
starts assembling the file level inline assembly instructions at the beginning
of a .s file.
<rdar://problem/17757232>
llvm-svn: 213924
|
| |
|
|
|
|
|
|
| |
testcases.
Based on code review from Philip Reames. Thanks Philip!
llvm-svn: 213923
|
| |
|
|
|
|
|
|
|
|
| |
* Track override set across module load and save
* Track originating module to allow proper re-export of #undef
* Make override set properly transitive when it picks up a #undef
This fixes nearly all of the remaining macro issues with self-host.
llvm-svn: 213922
|
| |
|
|
|
|
|
|
| |
StringMap doesn't guarantee any particular iteration order,
this is suboptimal when comparing llvm-vtabledump's output for two
object files.
llvm-svn: 213921
|
| |
|
|
| |
llvm-svn: 213920
|
| |
|
|
| |
llvm-svn: 213919
|
| |
|
|
| |
llvm-svn: 213918
|
| |
|
|
|
|
|
|
| |
feedback from Eric Christopher.
No functional change.
llvm-svn: 213917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch extends the __asm parser to make it keep parsing input tokens
as inline assembly if a single-line __asm line is followed by another line
starting with __asm too. It also makes sure that we correctly keep
matching braces in such situations by separating the notions of how many
braces we are matching and whether we are in single-line asm block mode.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4598
llvm-svn: 213916
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the PowerPC vmrgh* and vmrgl* instructions have a built-in
big-endian bias, it is necessary to swap their inputs in little-endian
mode when using them to implement a vector shuffle. This was
previously missed in the vector LE implementation.
There was already logic to distinguish between unary and "normal"
vmrg* vector shuffles, so this patch extends that logic to use a third
option: "swapped" vmrg* vector shuffles that are used for little
endian in place of the "normal" ones.
I've updated the vec-shuffle-le.ll test to check for the expected
register ordering on the generated instructions.
This bug was discovered when testing the LE and ELFv2 patches for
safety if they were backported to 3.4. A different vectorization
decision was made in 3.4 than on mainline trunk, and that exposed the
problem. I've verified this fix takes care of that issue.
llvm-svn: 213915
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change has the practical effect of fixing some backtrace
scenarios that would fail with inferiors running on the Android Art
host-side JVM under Linux x86_64 on Ubuntu 14.04.
See this lldb-commits thread for more details:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140721/011988.html
Change by Tong Shen.
Reviewed by Jason Molenda.
Tested:
Ubuntu 14.04 x86_64, clang-3.5-built lldb.
MacOSX 10.10 Preview 4, Xcode 6 Beta 4-built lldb.
llvm-svn: 213914
|
| |
|
|
|
|
|
| |
it through the normal TreeTransform logic for Exprs (which will strip off
implicit parts of the initialization and never re-create them).
llvm-svn: 213913
|
| |
|
|
|
|
|
| |
diffing. This removes extra "struct"/"class" in the type names and gives
"bool" instead of "_Bool" for booleans.
llvm-svn: 213912
|
| |
|
|
|
|
|
|
|
| |
This patch implements the data structures, the reader and
the writers for the new code coverage mapping system.
The new code coverage mapping system uses the instrumentation
based profiling to provide code coverage analysis.
llvm-svn: 213910
|
| |
|
|
|
|
|
|
|
| |
This patch implements the data structures, the reader and
the writers for the new code coverage mapping system.
The new code coverage mapping system uses the instrumentation
based profiling to provide code coverage analysis.
llvm-svn: 213909
|
| |
|
|
| |
llvm-svn: 213908
|
| |
|
|
| |
llvm-svn: 213907
|
| |
|
|
|
|
|
|
| |
The -print-file-name option in llvm-nm is to precede each symbol
with the object file it came from. While code for the parsing of this
option and its aliases existed there was no code to implement it.
llvm-svn: 213906
|
| |
|
|
|
|
|
| |
A builder complained that it couldn't find llvm-vtabledump, this is
probably because it wasn't a dependency of the 'test' target.
llvm-svn: 213905
|
| |
|
|
|
|
| |
Change by Keno Fischer.
llvm-svn: 213904
|
| |
|
|
|
|
|
|
|
|
| |
This tool's job is to dump the vtables inside object files. It is
currently limited to MS ABI vf- and vb-tables but it will eventually
support Itanium-style v-tables as well.
Differential Revision: http://reviews.llvm.org/D4584
llvm-svn: 213903
|
| |
|
|
|
|
| |
printing of other types.
llvm-svn: 213902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes compilers emit data into code sections (e.g. constant pools or
jump tables). These runs of data can throw off disassemblers. The solution
in mach-o is that ranges of data-in-code are encoded into a table pointed to
by the LC_DATA_IN_CODE load command.
The way the data-in-code information is encoded into lld's Atom model is that
that start and end of each data run is marked with a Reference whose offset
is the start/end of the data run. For arm, the switch back to code also marks
whether it is thumb or arm code.
llvm-svn: 213901
|
| |
|
|
|
|
|
|
|
|
| |
hint) the loop unroller replaces the llvm.loop.unroll.count metadata with
llvm.loop.unroll.disable metadata to prevent any subsequent unrolling
passes from unrolling more than the hint indicates. This patch fixes
an issue where loop unrolling could be disabled for other loops as well which
share the same llvm.loop metadata.
llvm-svn: 213900
|
| |
|
|
| |
llvm-svn: 213899
|