| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 155516
|
|
|
|
|
|
|
|
|
|
|
|
| |
ObjCPlusPlus as Objective-C classes. Really the
compiler should say they have Objective-C runtime
class, but we should be a little more resilient
(we were refusing to find ivars in those classes
before).
Also added a test case.
llvm-svn: 155515
|
|
|
|
|
|
|
|
| |
global namespace.
Enrico will follow this up with fixing the data formatter test cases that are failing.
llvm-svn: 155514
|
|
|
|
|
|
|
| |
of a precise count. Also, move RRInfo's Partial field into PtrState,
now that it won't increase the size.
llvm-svn: 155513
|
|
|
|
|
|
|
| |
the same test to be run multiple times in the same
session.
llvm-svn: 155511
|
|
|
|
| |
llvm-svn: 155510
|
|
|
|
|
|
|
|
| |
if the section is marked as encrypted. It will likely be readable
in live memory.
<rdar://problem/11305675>
llvm-svn: 155509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A test for this is checking if this compiles:
#include <float.h>
inline bool IsFinite(const double& number) {
return _finite(number) != 0;
}
That depends however on either mingw or msvc being installed, and
chapuni tells me there might be issues with float.h on mingw, so
no automated test is added.
llvm-svn: 155507
|
|
|
|
|
|
| |
rdar://problem/11312971
llvm-svn: 155505
|
|
|
|
|
|
|
| |
test whether an object responds to a selector
from outside the process.
llvm-svn: 155504
|
|
|
|
|
|
|
|
| |
case so that the Objective-C runtime doesn't
complain about lack of one, causing the test case
to fail.
llvm-svn: 155503
|
|
|
|
|
|
|
| |
math library functions.
rdar://11251464
llvm-svn: 155502
|
|
|
|
|
|
| |
test/lang/objcxx.
llvm-svn: 155501
|
|
|
|
|
|
|
|
| |
These lists exclude invoke unwind edges and loop backedges which
are being ignored. This makes it easier to ignore them
consistently.
llvm-svn: 155500
|
|
|
|
|
|
|
|
|
|
|
| |
When an instruction match is found, but the subtarget features it
requires are not available (missing floating point unit, or thumb vs arm
mode, for example), issue a diagnostic that identifies what the feature
mismatch is.
rdar://11257547
llvm-svn: 155499
|
|
|
|
|
|
|
|
|
| |
With -fno-math-errno (the default for Darwin) or -ffast-math these library
function can be marked readnone enabling more opportunities for CSE and other
optimizations.
rdar://11251464
llvm-svn: 155498
|
|
|
|
| |
llvm-svn: 155497
|
|
|
|
|
|
| |
bitfields - This patch ensures that (a) freeze-drying bitfields works correctly and (b) that we actually access bitfields through IR instead of the 'frame var en lieu of expr' shortcut, for added safety in corner cases that may arise
llvm-svn: 155494
|
|
|
|
| |
llvm-svn: 155492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directory, if exists, will be removed entirely
before running the test suite. A usage example looks like this:
test $ ./dotest.py -A x86_64 -R /tmp/x86_64 &
test $ ./dotest.py -A i386 -R /tmp/i386 &
where we would want to run the x86_64 and i386 archs concurrently but relocate the test suite to different directory
hierarchies in order not to stump on each other's intermediate files.
llvm-svn: 155491
|
|
|
|
|
|
| |
Fixes the two issues mentioned in PR12146.
llvm-svn: 155490
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed an issue that would happen when using debug map with DWARF in the .o files where we wouldn't ever track down the actual definition for a type when things were in namespaces. We now serialize the decl context information into an intermediate format which allows us to track down the correct definition for a type regardless of which DWARF symbol file it comes from. We do this by creating a "DWARFDeclContext" object that contains the DW_TAG + name for each item in a decl context which we can then use to veto potential accelerator table matches. For example, the accelerator tables store the basename of the type, so if you have "std::vector<int>", we would end up with an accelerator table entry for the type that contained "vector<int>", which we would then search for using a DWARFDeclContext object that contained:
[0] DW_TAG_class_type "vector<int>"
[1] DW_TAG_namespace "std"
This is currently used to track down forward declarations for things like "class a::b::Foo;".
llvm-svn: 155488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates. In an implicit instantiation of a member class, any member
templates don't get instantiated, so the existing check which only visited
the instantiations of a defined template skipped these templates'
instantiations.
Since there is only a single declaration of a member template of a class
template specialization, just use that to determine whether to visit the
instantiations. This introduces a slight inconsistency in that we will
visit the instantiations of such templates whether or not they are
defined, but we never visit a declared-but-not-defined instantiation, so
this turns out to not matter.
Patch by Daniel Jasper!
llvm-svn: 155487
|
|
|
|
| |
llvm-svn: 155486
|
|
|
|
|
|
| |
Fix 12592. Patch by Matt Pharr.
llvm-svn: 155480
|
|
|
|
| |
llvm-svn: 155477
|
|
|
|
| |
llvm-svn: 155475
|
|
|
|
|
|
|
| |
declaration of __block variables on same lines
with initializers. // rdsr://7547630
llvm-svn: 155473
|
|
|
|
|
|
| |
refuse to break edge to EH landing pad. rdar://11300144
llvm-svn: 155470
|
|
|
|
|
|
| |
<rdar://problem/11291436>.
llvm-svn: 155468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constants in C++11 mode. I have no idea why it required such particular
circumstances to get here, the code seems clearly to rely upon unchecked
assumptions.
Specifically, when we decide to form an index into a struct type, we may
have gone through (at least one) zero-length array indexing round, which
would have left the offset un-adjusted, and thus not necessarily valid
for use when indexing the struct type.
This is just an canonicalization step, so the correct thing is to refuse
to canonicalize nonsensical GEPs of this form. Implemented, and test
case added.
Fixes PR12642. Pair debugged and coded with Richard Smith. =] I credit
him with most of the debugging, and preventing me from writing the wrong
code.
llvm-svn: 155466
|
|
|
|
|
|
|
|
| |
r154362 was supposed to delete this bit, but obviously didn't.
rdar://11305594
llvm-svn: 155465
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
latest PR1255 discussion posts in llvm-commits.
Strategy.
0. Implement new classes. Classes doesn't affect anything. They still work with ConstantInt base values at this stage.
1. Fictitious replacement of current ConstantInt case values with ConstantRangesSet. Case ranges set will still hold single value, and ConstantInt *getCaseValue() will return it. But additionally implement new method in SwitchInst that allows to work with case ranges. Currenly I think it should be some wrapper that returns either single value or ConstantRangesSet object.
2. Step-by-step replacement of old "ConstantInt* getCaseValue()" with new alternative. Modify algorithms for all passes that works with SwitchInst. But don't modify LLParser and BitcodeReader/Writer. Still hold single value in each ConstantRangesSet object. On this stage some parts of LLVM will use old-style methods, and some ones new-style.
3. After all getCaseValue() usages will removed and whole LLVM and its clients will work in new style - modify LLParser, Reader and Writer. Remove getCaseValue().
4. Replace ConstantInt*-based case ranges set items with APInt ones.
Currently we are on Zero Stage: New classes.
ConstantRangesSet.
I selected ConstantArrays as case ranges set "holder" object (it is a temporary decision, I'll explain why below). The array items are may be ConstantVectors with single item, and ConstantVectors with two items (that means single number and range respectively).
The ConstantInt will used as basic value representation. It will replaced with APInt then. Of course ConstantArray and ConstantVector will go away after ConstantInt => APInt replacement.
New class mandatory features:
- bool isSatisfies(ConstantInt *V) method (need better name?). Returns true if the given value satisfies this case.
- Case's ranges and values enumeration. In some passes we need to analize each case (SwitchLowering for example).
Factory + unified clusterify.
I also propose to implement the factory that allows to build case object with user friendly way. I called it CRSBuilder by now.
Currenly I implemented the factory that allows add,remove pairs of range+successor. It also allows add existing ConstantRangesSet decompiling it to separated ranges. Factory can emit either clusters set (single case range + successor) or the set of "ConstantRangesSet + Successor" pairs.
So you can use it either as builder for new cases set for SwitchInst, or for clusterification of existing cases set.
Just call Factory.optimize() and it emits optimized and sorted clusters collection for you!
I tested clusterification on SelectionDAGBuilder - it works fine. Don't worry it was not included in this patch. Just new classes.
Factory is a template. There are two params: SuccessorClass and IsReadonly. So you can specify what successor you need (BB or MBB). And you can also restrict your factory to use values in read-only mode (SelectionDAGBuilder need IsReadonly=true). Read-only factory couldn't build the cases ranges.
llvm-svn: 155464
|
|
|
|
|
|
|
| |
multiple declaration of block variables
(with no initializer) on the same line.
llvm-svn: 155462
|
|
|
|
|
|
|
| |
Remove the v2f64 patterns because it does not match any vbroadcast
instruction.
llvm-svn: 155461
|
|
|
|
| |
llvm-svn: 155460
|
|
|
|
| |
llvm-svn: 155459
|
|
|
|
| |
llvm-svn: 155458
|
|
|
|
| |
llvm-svn: 155457
|
|
|
|
|
|
|
|
|
| |
current scheduling region.
The DAG builder is a convenient place to do it. Hopefully this is more
efficient than a separate traversal over the same region.
llvm-svn: 155456
|
|
|
|
|
|
|
|
|
|
|
| |
doesn't return a result. If that expression can't
be run in the current context (for example, if it
uses a function and there is no running process)
then we used to try to destroy the nonexistent
result variable. We now only destroy the result
variable if we actually made one.
llvm-svn: 155455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MachineInstr sequence.
This uses the new target interface for tracking register pressure
using pressure sets to model overlapping register classes and
subregisters.
RegisterPressure results can be tracked incrementally or stored at
region boundaries. Global register pressure can be deduced from local
RegisterPressure results if desired.
This is an early, somewhat untested implementation. I'm working on
testing it within the context of a register pressure reducing
MachineScheduler.
llvm-svn: 155454
|
|
|
|
|
|
| |
instructions.
llvm-svn: 155453
|
|
|
|
| |
llvm-svn: 155452
|
|
|
|
| |
llvm-svn: 155449
|
|
|
|
|
|
|
| |
Instead of -polly-run-import-jscop and -polly-run-export-jscop, we just use
-polly-import and -polly-export.
llvm-svn: 155446
|
|
|
|
|
|
|
| |
We now support -polly-optimizer=isl, -polly-optimizer=pocc and
-polly-optimizer=none. The option -polly-no-optimizer is gone.
llvm-svn: 155445
|
|
|
|
|
|
| |
instructions.
llvm-svn: 155444
|
|
|
|
|
|
|
| |
fix a typo
add punctuation
llvm-svn: 155443
|
|
|
|
|
|
| |
MSVC compatibility.
llvm-svn: 155441
|