| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
During LTO, the target options on functions within the same Module may
change. This would necessitate resetting some of the back-end. Do this for X86,
because it's a Friday afternoon.
llvm-svn: 178917
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverting because this breaks one of the LTO builders. Original commit message:
This change fixes a bug that I introduced in r178058. After a register is
scavenged using one of the available spills slots the instruction defining the
virtual register needs to be moved to after the spill code. The scavenger has
already processed the defining instruction so that registers killed by that
instruction are available for definition in that same instruction. Unfortunately,
after this, the scavenger needs to iterate through the spill code and then
visit, again, the instruction that defines the now-scavenged register. In order
to avoid confusion, the register scavenger needs the ability to 'back up'
through the spill code so that it can again process the instructions in the
appropriate order. Prior to this fix, once the scavenger reached the
just-moved instruction, it would assert if it killed any registers because,
having already processed the instruction, it believed they were undefined.
Unfortunately, I don't yet have a small test case. Thanks to Pranav Bhandarkar
for diagnosing the problem and testing this fix.
llvm-svn: 178916
|
|
|
|
| |
llvm-svn: 178915
|
|
|
|
| |
llvm-svn: 178914
|
|
|
|
| |
llvm-svn: 178913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
index.
This optimization is unstable at this moment; it
1) block us on a very important application
2) PR15200
3) test6 and test7 in test/Transforms/ScalarRepl/dynamic-vector-gep.ll
(the CHECK command compare the output against wrong result)
I personally believe this optimization should not have any impact on the
autovectorized code, as auto-vectorizer is supposed to put gather/scatter
in a "right" way. Although in theory downstream optimizaters might reveal
some gather/scatter optimization opportunities, the chance is quite slim.
For the hand-crafted vectorizing code, in term of redundancy elimination,
load-CSE, copy-propagation and DSE can collectively achieve the same result,
but in much simpler way. On the other hand, these optimizers are able to
improve the code in a incremental way; in contrast, SROA is sort of all-or-none
approach. However, SROA might slighly win in stack size, as it tries to figure
out a stretch of memory tightenly cover the area accessed by the dynamic index.
rdar://13174884
PR15200
llvm-svn: 178912
|
|
|
|
|
|
|
|
| |
out-of-line member functions.
rdar://13535645
llvm-svn: 178911
|
|
|
|
|
|
|
|
|
| |
llvm-mips-linux green.
llvm-mips-linux runs on a big endian machine. This test passes if I change 'e'
to 'E' in the target data layout string.
llvm-svn: 178910
|
|
|
|
|
|
|
|
| |
It's possible for the lock file to disappear and the owning process to
return before we're able to see the generated file. Spin for a little
while to see if it shows up before failing.
llvm-svn: 178909
|
|
|
|
|
|
|
|
|
| |
If the directory that will contain the unique file doesn't exist when
we tried to create the file, but another process creates it before we
get a chance to try creating it, we would bail out rather than try to
create the unique file.
llvm-svn: 178908
|
|
|
|
|
|
|
|
|
|
|
|
| |
cast
UseNullptr previously matched the implicit cast to const pointer as well as
the explicit cast within that has an implicit cast to nullptr as a descendant.
-Refactored UseNullptr to avoid special-casing certain kinds of cast sequences
-Added test cases.
llvm-svn: 178907
|
|
|
|
|
|
| |
address space in OpenCL.
llvm-svn: 178906
|
|
|
|
| |
llvm-svn: 178905
|
|
|
|
| |
llvm-svn: 178904
|
|
|
|
|
|
| |
// rdar://12379114
llvm-svn: 178903
|
|
|
|
| |
llvm-svn: 178902
|
|
|
|
|
|
|
|
|
|
| |
With cpp11-migrate core functionality moved to a separate library (for enabling
unit tests) this library contained code that referenced symbols that are still
in the main binary. On some platforms, the shared library build broke as a
result. This revision fixes the dependency problem and is safe for the eventual
lib-ification of the transforms as well.
llvm-svn: 178901
|
|
|
|
|
|
|
|
| |
With the lib-ification of cpp11-migrate, real unit tests can be written.
Replacing dummy tests with some simple tests for the Transform public
interface.
llvm-svn: 178900
|
|
|
|
|
|
| |
Now treat AF_None family as impossible in isTrackedFamily()
llvm-svn: 178899
|
|
|
|
| |
llvm-svn: 178898
|
|
|
|
|
|
|
|
|
|
| |
Introducing a negative cache for ObjCLanguageRuntime::LookupInCompleteClassCache()
This helps speed up the (common) case of us looking for classes that are hidden deep within Cocoa internals and repeatedly failing at finding type information for them.
In order for this to work, we need to clean this cache whenever debug information is added. A new symbols loaded event is added that is triggered with add-dsym (before modules loaded would be triggered for both adding modules and adding symbols).
Interested parties can register for this event. Internally, we make sure to clean the negative cache whenever symbols are added.
Lastly, ClassDescriptor::IsTagged() has been refactored to GetTaggedPointerInfo() that also (optionally) returns info and value bits. In this way, data formatters can share tagged pointer code instead of duplicating the required arithmetic.
llvm-svn: 178897
|
|
|
|
|
|
| |
These should really be templated like ELF, but this is a start.
llvm-svn: 178896
|
|
|
|
|
|
| |
VisitInstructionsBottomUp.
llvm-svn: 178895
|
|
|
|
| |
llvm-svn: 178894
|
|
|
|
| |
llvm-svn: 178893
|
|
|
|
| |
llvm-svn: 178892
|
|
|
|
|
|
|
|
| |
As mentioned in the previous commit message, the use-after-free and
double-free warnings for 'delete' are worth enabling even while the
leak warnings still have false positives.
llvm-svn: 178891
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits the leak-checking part of alpha.cplusplus.NewDelete into a
separate user-level checker, alpha.cplusplus.NewDeleteLeaks. All the
difficult false positives we've seen with the new/delete checker have been
spurious leak warnings; the use-after-free warnings and mismatched
deallocator warnings, while rare, have always been valid.
<rdar://problem/6194569>
llvm-svn: 178890
|
|
|
|
| |
llvm-svn: 178889
|
|
|
|
|
|
| |
(Don't ask, this was a user request).
llvm-svn: 178888
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
bool operator<
(const aaaaaaaaaaaaaaaaaaaaa &left, const aaaaaaaaaaaaaaaaaaaaa &right) {
return left.group < right.group;
}
After:
bool operator<(const aaaaaaaaaaaaaaaaaaaaa &left,
const aaaaaaaaaaaaaaaaaaaaa &right) {
return left.group < right.group;
}
llvm-svn: 178887
|
|
|
|
| |
llvm-svn: 178886
|
|
|
|
|
|
| |
specifying the -mcpu
llvm-svn: 178885
|
|
|
|
| |
llvm-svn: 178883
|
|
|
|
| |
llvm-svn: 178882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memory operands.
Essentially, this layers an infix calculator on top of the parsing state
machine. The scale on the index register is still expected to be an immediate
__asm mov eax, [eax + ebx*4]
and will not work with more complex expressions. For example,
__asm mov eax, [eax + ebx*(2*2)]
The plus and minus binary operators assume the numeric value of a register is
zero so as to not change the displacement. Register operands should never
be an operand for a multiply or divide operation; the scale*indexreg
expression is always replaced with a zero on the operand stack to prevent
such a case.
rdar://13521380
llvm-svn: 178881
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Sets a report hook that emulates pressing "retry" in the "abort, retry,
ignore" dialog box that _CrtDbgReport normally raises. There are many
other ways to disable assertion reports, but this was the only way I
could find that still calls our exception handler.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D625
llvm-svn: 178880
|
|
|
|
|
|
| |
What was missing was were the type strong operator|.
llvm-svn: 178879
|
|
|
|
| |
llvm-svn: 178878
|
|
|
|
| |
llvm-svn: 178877
|
|
|
|
| |
llvm-svn: 178876
|
|
|
|
|
|
|
|
| |
InMemoryStruct is extremely dangerous as it returns data from an internal
buffer when the endiannes doesn't match. This should fix the tests on big
endian hosts.
llvm-svn: 178875
|
|
|
|
| |
llvm-svn: 178874
|
|
|
|
| |
llvm-svn: 178873
|
|
|
|
|
|
| |
CHECK(a==b). Was puzzled why lint did not catch it. Turns out this check was disabled for asan source. fix all cases and enable the check
llvm-svn: 178872
|
|
|
|
|
|
|
|
|
| |
Change unittests/ExecutionEngine/Makefile to include Makefile.config before
TARGET_HAS_JIT flag is checked.
Fixes bug: http://llvm.org/bugs/show_bug.cgi?id=15669
llvm-svn: 178871
|
|
|
|
|
|
|
|
|
|
|
| |
The prefixes and names used are now identical to 32-bit ARM, which is also
expected to remain unchanged.
If we made this change after a release, we'd probably have to support both
variants for a while, but I think since AArch64 exists only on trunk now, it's
acceptable to simply swap them now.
llvm-svn: 178870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the RuntimeDyldELF::processRelocationRef routine finds the target
symbol of a relocation in the local or global symbol table, it performs
a section-relative relocation:
Value.SectionID = lsi->second.first;
Value.Addend = lsi->second.second;
At this point, however, any Addend that might have been specified in
the original relocation record is lost. This is somewhat difficult to
trigger for relocations within the code section since they usually
do not contain non-zero Addends (when built with the default JIT code
model, in any case). However, the problem can be reliably triggered
by a relocation within the data section caused by code like:
int test[2] = { -1, 0 };
int *p = &test[1];
The initializer of "p" will need a relocation to "test + 4". On
platforms using RelA relocations this means an Addend of 4 is required.
Current code ignores this addend when processing the relocation,
resulting in incorrect execution.
Fixed by taking the Addend into account when processing relocations
to symbols found in the local or global symbol table.
Tested on x86_64-linux and powerpc64-linux.
llvm-svn: 178869
|
|
|
|
| |
llvm-svn: 178868
|
|
|
|
|
|
| |
To be used with static libstdc++.
llvm-svn: 178866
|