| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.
I'll be updating other docs and other files in smaller subsequnet
commits.
While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.
Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)
llvm-svn: 171359
|
|
|
|
|
|
| |
AttrKind value.
llvm-svn: 171294
|
|
|
|
|
|
| |
the getAttrSomewhere predicate. This prevents the uses of 'Attribute' as a collection of attributes.
llvm-svn: 171271
|
|
|
|
| |
llvm-svn: 171257
|
|
|
|
|
|
| |
methods instead.
llvm-svn: 171255
|
|
|
|
|
|
|
|
|
| |
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
llvm-svn: 171253
|
|
|
|
| |
llvm-svn: 171252
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* One that accepts a single Attribute::AttrKind.
* One that accepts an Attribute::AttrKind plus a list of values. This is for
attributes defined like this:
#1 = attributes { align = 4 }
* One that accepts a string, for target-specific attributes like this:
#2 = attributes { "cpu=cortex-a8" }
llvm-svn: 171249
|
|
|
|
|
|
|
| |
stored here is of a certain kind. This is in preparation for when an Attribute
object represents a single attribute, instead of a bitmask of attributes.
llvm-svn: 171247
|
|
|
|
|
|
|
|
|
| |
already uniquified.
Note: This will be expanded in the future to add more than just one pointer
value.
llvm-svn: 171245
|
|
|
|
|
|
| |
method won't be sticking around.
llvm-svn: 171244
|
|
|
|
| |
llvm-svn: 171221
|
|
|
|
| |
llvm-svn: 171220
|
|
|
|
| |
llvm-svn: 171120
|
|
|
|
|
|
|
|
|
| |
These are now generally used for all diagnostics from the backend, not just
for inline assembly, so this drops the "InlineAsm" from the names. No
functional change. (I've left aliases for the old names but only for long
enough to let me switch over clang to use the new ones.)
llvm-svn: 171047
|
|
|
|
|
|
|
|
|
| |
When the backend is used from clang, it should produce proper diagnostics
instead of just printing messages to errs(). Other clients may also want to
register their own error handlers with the LLVMContext, and the same handler
should work for warnings in the same way as the existing emitError methods.
llvm-svn: 171041
|
|
|
|
| |
llvm-svn: 171026
|
|
|
|
|
|
| |
attribute instead of the value of the attribute.
llvm-svn: 170972
|
|
|
|
|
|
|
| |
Rename the AttributeImpl* from Attrs to pImpl to be consistent with other code.
Add comments where none were before. Or doxygen-ify other comments.
llvm-svn: 170767
|
|
|
|
|
|
|
|
| |
call, the call cannot be duplicated - Jump threading, loop unrolling, loop unswitching, and loop rotation are inhibited if they would duplicate the call.
Similarly inlining of the function is inhibited, if that would duplicate the call (in particular inlining is still allowed when there is only one callsite and the function has internal linkage).
llvm-svn: 170704
|
|
|
|
|
|
|
|
| |
This has undefined behavior, because the classof implementation attempts to
access parts of the not-yet-constructed derived class. Found by clang
-fsanitize=vptr.
llvm-svn: 170658
|
|
|
|
|
|
|
| |
behavior and violates the !range constraints we put on loads of this enum.
Found by clang -fsanitize=enum.
llvm-svn: 170653
|
|
|
|
|
|
| |
Attributes.
llvm-svn: 170631
|
|
|
|
| |
llvm-svn: 170615
|
|
|
|
|
|
| |
isa<IntrinsicInst>()) to use it. This decreases the number of occurrences of the slow-path string matching performed by getIntrinsicID().
llvm-svn: 170602
|
|
|
|
| |
llvm-svn: 170600
|
|
|
|
|
|
| |
Accordingly, add MVT::getVT.
llvm-svn: 170550
|
|
|
|
| |
llvm-svn: 170518
|
|
|
|
| |
llvm-svn: 170517
|
|
|
|
|
|
| |
some minor comment reformatting.
llvm-svn: 170516
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
|
|
|
| |
llvm-svn: 170367
|
|
|
|
| |
llvm-svn: 170002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of the instruction. I've left a forwarding wrapper for the
instruction so users with the instruction don't need to create
a GEPOperator themselves.
This lets us remove the copy of this code in instsimplify.
I've looked at most of the other copies of similar code, and this is the
only one I've found that is actually exactly the same. The one in
InlineCost is very close, but it requires re-mapping non-constant
indices through the cost analysis value simplification map. I could add
direct support for this to the generic routine, but it seems overly
specific.
llvm-svn: 169853
|
|
|
|
|
|
|
|
|
|
|
| |
the GEP instruction class.
This is part of the continued refactoring and cleaning of the
infrastructure used by SROA. This particular operation is also done in
a few other places which I'll try to refactor to share this
implementation.
llvm-svn: 169852
|
|
|
|
|
|
| |
in the near future.
llvm-svn: 169651
|
|
|
|
| |
llvm-svn: 169428
|
|
|
|
|
|
|
|
|
| |
- fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies
- fixed machine module info to operate in the doInitialization/doFinalization model, also fixes some FIXMEs
reviewed by Evan Cheng <evan.cheng@apple.com>
llvm-svn: 169391
|
|
|
|
|
|
|
|
|
| |
The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.
llvm-svn: 169312
|
|
|
|
|
|
|
|
|
|
| |
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
llvm-svn: 169224
|
|
|
|
|
|
|
|
|
| |
The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.
llvm-svn: 169218
|
|
|
|
|
|
|
|
| |
unreachable code in MachineModuleInfo
reviewed by Evan Cheng <evan.cheng@apple.com>
llvm-svn: 169164
|
|
|
|
| |
llvm-svn: 169145
|
|
|
|
|
|
| |
pass instance."
llvm-svn: 169134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
| |
status.
llvm-svn: 169083
|
|
|
|
|
|
|
| |
2012-11-30-misched-dbg.ll had crashed. Then (MDNode)N was "!{}".
I am not sure it would be ill-formed or not.
llvm-svn: 169074
|
|
|
|
|
|
|
| |
This avoids unidentified duplicates in the pass execution time report
when a pass runs more than once in the pass manager pipeline.
llvm-svn: 169039
|
|
|
|
|
|
|
|
|
|
|
| |
For example, don't allow empty strings to be passed to getInt.
Move asserts inside parseSpecifier. (One day we may want to pass parse
error messages to the user - from LLParser - instead of using asserts,
but keep the code simple until then. There have been an attempt to do
this. See r142288, which got reverted, and r142605.)
llvm-svn: 168991
|
|
|
|
|
|
|
|
|
|
|
|
| |
depends on the IR infrastructure, there is no sense in it being off in
Support land.
This is in preparation to start working to expand InstVisitor into more
special-purpose visitors that are still generic and can be re-used
across different passes. The expansion will go into the Analylis tree
though as nothing in VMCore needs it.
llvm-svn: 168972
|