| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reinstates commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 216982
|
| |
|
|
| |
llvm-svn: 216938
|
| |
|
|
|
|
|
|
|
|
| |
I've been assuming chain operands were always the first operand,
since the documentation says this. I was confused about why they
were missing after instruction selection. Apparently the convention
changes to using the last operand for MachineSDNodes and I've never
noticed before.
llvm-svn: 216934
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Just fixing comments, no functional change.
Test Plan: N/A
Reviewers: jfb
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D5130
llvm-svn: 216784
|
| |
|
|
|
|
|
|
|
| |
version of LLVM/Clang.
I've fixed most of the simple bugs and currently "check-llvm" test suite
has 26 failures, and "check-clang" suite has 5 failures.
llvm-svn: 216701
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There is no functionality change here except in the way we assemble and
dump musttail calls in variadic functions. There's really no need to
separate out the bits for musttail and "is forwarding varargs" on call
instructions. A musttail call by definition has to forward the ellipsis
or it would fail verification.
Reviewers: chandlerc, nlewycky
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D4892
llvm-svn: 216423
|
| |
|
|
| |
llvm-svn: 216316
|
| |
|
|
| |
llvm-svn: 216292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
changes to ensure discriminator changes don't introduce new DWARF DW_TAG_lexical_blocks.
Somewhat unnoticed in the original implementation of discriminators, but
it could cause instructions to end up in new, small,
DW_TAG_lexical_blocks due to the use of DILexicalBlock to track
discriminator changes.
Instead, use DILexicalBlockFile which we already use to track file
changes without introducing new scopes, so it works well to track
discriminator changes in the same way.
llvm-svn: 216239
|
| |
|
|
| |
llvm-svn: 216204
|
| |
|
|
|
|
| |
how this affects the numbering of unnamed temporaries.
llvm-svn: 216070
|
| |
|
|
|
|
| |
Should make the example added in r216025 a little more clear.
llvm-svn: 216027
|
| |
|
|
|
|
|
|
|
|
| |
Implement `uselistorder` and `uselistorder_bb` assembly directives,
which allow the use-list order to be recovered when round-tripping to
assembly.
This is the bulk of PR20515.
llvm-svn: 216025
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4729
llvm-svn: 215990
|
| |
|
|
|
|
|
| |
I should have included this as part of r215986, which worked around this
corner by changing ArrayRef::equals() not to use std::equal. Alas.
llvm-svn: 215988
|
| |
|
|
| |
llvm-svn: 215695
|
| |
|
|
|
|
|
|
|
| |
auroraux.org is not resolving.
I will add this to the release notes as soon as I figure out where to put the
3.6 release notes :-)
llvm-svn: 215645
|
| |
|
|
|
|
|
| |
treated as errors (which is still the default). This is useful when
working on documentation that has existing errors.
llvm-svn: 215634
|
| |
|
|
| |
llvm-svn: 215522
|
| |
|
|
|
|
|
| |
* libaries => libraries
* avaiable => available
llvm-svn: 215366
|
| |
|
|
|
|
|
|
|
|
|
| |
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reverts commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 215154
|
| |
|
|
|
|
|
|
|
| |
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.
Thanks to Lang Hames for making MCJIT a good replacement!
llvm-svn: 215111
|
| |
|
|
| |
llvm-svn: 215088
|
| |
|
|
|
|
| |
Committing http://reviews.llvm.org/D4798 for Robin Morisset (morisset@google.com)
llvm-svn: 214934
|
| |
|
|
|
|
| |
information and update all callers. No functional change.
llvm-svn: 214781
|
| |
|
|
| |
llvm-svn: 214772
|
| |
|
|
|
|
| |
Level Debugging metadata.
llvm-svn: 214771
|
| |
|
|
| |
llvm-svn: 214700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch add a --show-xfail flag. If this flag is specified then each xfail test will be printed to output.
When it is not given xfail tests are ignored. Ignoring xfail tests is the current behavior.
This flag is meant to mirror the --show-unsupported flag that was recently added.
Reviewers: ddunbar, EricWF
Reviewed By: EricWF
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D4750
llvm-svn: 214609
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables (for example, by-value struct arguments passed in registers, or
large integer values split across several smaller registers).
On the IR level, this adds a new type of complex address operation OpPiece
to DIVariable that describes size and offset of a variable fragment.
On the DWARF emitter level, all pieces describing the same variable are
collected, sorted and emitted as DWARF expressions using the DW_OP_piece
and DW_OP_bit_piece operators.
http://reviews.llvm.org/D3373
rdar://problem/15928306
What this patch doesn't do / Future work:
- This patch only adds the backend machinery to make this work, patches
that change SROA and SelectionDAG's type legalizer to actually create
such debug info will follow. (http://reviews.llvm.org/D2680)
- Making the DIVariable complex expressions into an argument of dbg.value
will reduce the memory footprint of the debug metadata.
- The sorting/uniquing of pieces should be moved into DebugLocEntry,
to facilitate the merging of multi-piece entries.
llvm-svn: 214576
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Users keep emailing us about the difficulties of getting LD_LIBRARY_PATH
into their environment, which should be completely unecessary. Try to
strengthen the rpath recommentation by putting in an example cmake
invocation.
Speaking of which, we might want to make CMake the recommended build
system in GettingStarted.html.
llvm-svn: 214565
|
| |
|
|
| |
llvm-svn: 214431
|
| |
|
|
|
|
|
|
|
| |
As requested, changing this wording slightly.
Thanks,
Bill
llvm-svn: 214430
|
| |
|
|
|
|
|
|
|
| |
Oops. Used the wrong heading level by mistake.
Thanks,
Bill
llvm-svn: 214405
|
| |
|
|
|
|
|
|
|
|
| |
I wrongly included a description of a patch that came in after 3.5 branched
and has not been backported.
Thanks,
Bill
llvm-svn: 214404
|
| |
|
|
|
|
|
|
|
|
| |
Here's my take on 3.5 changes for PowerPC. Others please feel free to add,
edit, delete as desired.
Thanks,
Bill
llvm-svn: 214403
|
| |
|
|
| |
llvm-svn: 214383
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we had
@a = weak global ...
but
@b = alias weak ...
The patch changes aliases to look more like global variables.
Looking at some really old code suggests that the reason was that the old
bison based parser had a reduction for alias linkages and another one for
global variable linkages. Putting the alias first avoided the reduce/reduce
conflict.
The days of the old .ll parser are long gone. The new one parses just "linkage"
and a later check is responsible for deciding if a linkage is valid in a
given context.
llvm-svn: 214355
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4726
llvm-svn: 214331
|
| |
|
|
|
|
|
|
|
| |
Someone asked about this on IRC the other day, and I couldn't
find the magic prefix documented anywhere.
Differential Revision: http://reviews.llvm.org/D4728
llvm-svn: 214329
|
| |
|
|
|
|
|
| |
According to VectorType::isValidElementType, any integer, floating point
or pointer type is a valid vector element type.
llvm-svn: 214302
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We branched 3.5, it's now time to work on 3.6.
This is Sylvestre's patch from [1] plus regenerated configure
file by me, and minus the release notes reset, which Sean
pointed out [2] should happen later.
1. http://reviews.llvm.org/D4660
2. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140721/111137.html
llvm-svn: 214131
|
| |
|
|
|
|
| |
libraries. With many contributions from Brad King.
llvm-svn: 214077
|
| |
|
|
| |
llvm-svn: 214076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first commit in a series that add an @llvm.assume intrinsic which
can be used to provide the optimizer with a condition it may assume to be true
(when the control flow would hit the intrinsic call). Some basic properties are added here:
- llvm.invariant(true) is dead.
- llvm.invariant(false) is unreachable (this directly corresponds to the
documented behavior of MSVC's __assume(0)), so is llvm.invariant(undef).
The intrinsic is tagged as writing arbitrarily, in order to maintain control
dependencies. BasicAA has been updated, however, to return NoModRef for any
particular location-based query so that we don't unnecessarily block code
motion.
llvm-svn: 213973
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
|
| |
|
|
| |
llvm-svn: 213813
|
| |
|
|
|
|
| |
new form using the string "full".
llvm-svn: 213772
|
| |
|
|
| |
llvm-svn: 213749
|