| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
type as the static type. Instead use the TypeImpl() constructor correctly
llvm-svn: 219142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch's author points out that, despite the function's documentation,
getSetCCResultType is only used to get the SETCC result type (with one
here-removed problematic exception). In one case, getSetCCResultType was being
used to get the predicate type to use for a SELECT node, and then
SIGN_EXTENDing (or truncating) to get the input predicate to match that type.
Unfortunately, this was happening inside visitSIGN_EXTEND, and creating new
SIGN_EXTEND nodes was causing an infinite loop. In addition, this behavior was
wrong if a target was not using ZeroOrNegativeOneBooleanContent. Lastly, the
extension/truncation seems unnecessary here: SELECT is defined as:
Select(COND, TRUEVAL, FALSEVAL). If the type of the boolean COND is not i1
then the high bits must conform to getBooleanContents.
So here we remove this use of getSetCCResultType and update
getSetCCResultType's documentation to reflect its actual uses.
Patch by deadal nix!
llvm-svn: 219141
|
| |
|
|
|
|
| |
These functions are defined as static in the mingw32 headers.
llvm-svn: 219140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivation is to recognize code such as this from /llvm/projects/test-suite/SingleSource/Benchmarks/BenchmarkGame/n-body.c:
float distance = sqrt(dx * dx + dy * dy + dz * dz);
float mag = dt / (distance * distance * distance);
Without this patch, we don't match the sqrt as a reciprocal sqrt, so for PPC the new testcase in this patch produces:
addis 3, 2, .LCPI4_2@toc@ha
lfs 4, .LCPI4_2@toc@l(3)
addis 3, 2, .LCPI4_1@toc@ha
lfs 0, .LCPI4_1@toc@l(3)
fcmpu 0, 1, 4
beq 0, .LBB4_2
# BB#1:
frsqrtes 4, 1
addis 3, 2, .LCPI4_0@toc@ha
lfs 5, .LCPI4_0@toc@l(3)
fnmsubs 13, 1, 5, 1
fmuls 6, 4, 4
fmadds 1, 13, 6, 5
fmuls 1, 4, 1
fres 4, 1 <--- reciprocal of reciprocal square root
fnmsubs 1, 1, 4, 0
fmadds 4, 4, 1, 4
.LBB4_2:
fmuls 1, 4, 2
fres 2, 1
fnmsubs 0, 1, 2, 0
fmadds 0, 2, 0, 2
fmuls 1, 3, 0
blr
After the patch, this simplifies to:
frsqrtes 0, 1
addis 3, 2, .LCPI4_1@toc@ha
fres 5, 2
lfs 4, .LCPI4_1@toc@l(3)
addis 3, 2, .LCPI4_0@toc@ha
lfs 7, .LCPI4_0@toc@l(3)
fnmsubs 13, 1, 4, 1
fmuls 6, 0, 0
fnmsubs 2, 2, 5, 7
fmadds 1, 13, 6, 4
fmadds 2, 5, 2, 5
fmuls 0, 0, 1
fmuls 0, 0, 2
fmuls 1, 3, 0
blr
Differential Revision: http://reviews.llvm.org/D5628
llvm-svn: 219139
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The use of the vec_lvsl and vec_lvsr interfaces are discouraged for
little endian targets since Power8 hardware is a minimum requirement,
and Power8 provides reasonable performance for unaligned vector loads
and stores. Up till now we have not provided "correct" (i.e., big-
endian-compatible) code generation for these interfaces, as to do so
produces poorly performing code. However, this has become the source
of too many questions.
With this patch, LLVM will now produce compatible code for these
interfaces, but will also produce a deprecation warning message for
PPC64LE when one of them is used. This should make the porting direction
clearer to programmers. A similar patch has recently been committed to
GCC.
This patch includes a test for the warning message. There is a companion
patch that adds two unit tests to projects/test-suite.
llvm-svn: 219137
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
information."
This reverts r218944, which reverted r218714, plus a bug fix.
Description of the bug in r218714 (by Nick)
The original patch forgot to check if the Scale in VariableGEPIndex flipped the
sign of the variable. The BasicAA pass iterates over the instructions in the
order they appear in the function, and so BasicAliasAnalysis::aliasGEP is
called with the variable it first comes across as parameter GEP1. Adding a
%reorder label puts the definition of %a after %b so aliasGEP is called with %b
as the first parameter and %a as the second. aliasGEP later calculates that %a
== %b + 1 - %idxprom where %idxprom >= 0 (if %a was passed as the first
parameter it would calculate %b == %a - 1 + %idxprom where %idxprom >= 0) -
ignoring that %idxprom is scaled by -1 here lead the patch to incorrectly
conclude that %a > %b.
Revised patch by Nick White, thanks! Thanks to Lang to isolating the bug.
Slightly modified by me to add an early exit from the loop and avoid
unnecessary, but expensive, function calls.
Original commit message:
Two related things:
1. Fixes a bug when calculating the offset in GetLinearExpression. The code
previously used zext to extend the offset, so negative offsets were converted
to large positive ones.
2. Enhance aliasGEP to deduce that, if the difference between two GEP
allocations is positive and all the variables that govern the offset are also
positive (i.e. the offset is strictly after the higher base pointer), then
locations that fit in the gap between the two base pointers are NoAlias.
Patch by Nick White!
llvm-svn: 219135
|
| |
|
|
| |
llvm-svn: 219134
|
| |
|
|
|
|
| |
lines at arbitrary points.
llvm-svn: 219133
|
| |
|
|
| |
llvm-svn: 219132
|
| |
|
|
|
|
|
|
| |
This fixes http://llvm.org/bugs/show_bug.cgi?id=21166 .
Differential Revision: http://reviews.llvm.org/D5623
llvm-svn: 219131
|
| |
|
|
|
|
|
| |
This assertion is firing because -loop-unroll is failing to preserve
-loop-info (see PR20987). Improve it.
llvm-svn: 219130
|
| |
|
|
|
|
|
|
| |
ppc64le.
Reviewed by Hal Finkel and Bill Schmidt.
llvm-svn: 219129
|
| |
|
|
| |
llvm-svn: 219128
|
| |
|
|
|
|
|
| |
This instruction form is handled by different AsmOperands now, so the code is
completely dead (and wrong anyway).
llvm-svn: 219127
|
| |
|
|
|
|
|
|
| |
This is a follow-up to r207670 (ELF) and r218636 (COFF).
Differential Revision: http://reviews.llvm.org/D5622
llvm-svn: 219126
|
| |
|
|
|
|
|
|
|
|
| |
Codeview line tables for functions in different sections refer to a common
STRING_TABLE_SUBSECTION for filenames.
This happens when building with -Gy or with inline functions with MSVC.
Original patch by Jeff Muizelaar!
llvm-svn: 219125
|
| |
|
|
|
|
|
|
|
| |
in availability attribute by preserving this info.
in VersionTuple and using it in pretty printing of attributes
and yet using '.' as separator when diagnosing unavailable
message calls. rdar://18490958
llvm-svn: 219124
|
| |
|
|
|
|
|
|
|
| |
of std::set.
And iterate over the smaller map instead of the larger set first. Reduces the time spent in
calculateDbgValueHistory by 30-40%.
llvm-svn: 219123
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to return PartialAlias if *either* variable being queried interacted
with arguments or globals. AFAICT, we can change this to only returning
MayAlias iff *both* variables being queried interacted with arguments or
globals.
Also, adding some basic functionality tests: some basic IPA tests, checking
that we give conservative responses with arguments/globals thrown in the mix,
and ensuring that we trace values through stores and loads.
Note that saying that 'x' interacted with arguments or globals means that the
Attributes of the StratifiedSet that 'x' belongs to has any bits set.
Patch by George Burgess IV, thanks!
llvm-svn: 219122
|
| |
|
|
| |
llvm-svn: 219121
|
| |
|
|
| |
llvm-svn: 219120
|
| |
|
|
|
|
|
|
|
|
| |
Before:
#define LENGTH(x, y) (x) - (y)+1
After:
#define LENGTH(x, y) (x) - (y) + 1
llvm-svn: 219119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
negatives.
Summary:
DynTypedMatcher::constructVariadic() where the restrict kind of the
different matchers are not related causes the matcher to have a "None"
restrict kind. This causes false negatives for anyOf and eachOf.
Change the logic to get a common ancestor if there is one.
Also added regression tests that fail without the fix.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D5580
llvm-svn: 219118
|
| |
|
|
|
|
|
| |
Add another wait-for-device which may fix a flaky setup error.
Fix output message.
llvm-svn: 219117
|
| |
|
|
|
|
| |
operator as expected. NFC, should fix the MSVC build bots.
llvm-svn: 219116
|
| |
|
|
|
|
| |
We should be able to stop working around it at some point in the future.
llvm-svn: 219115
|
| |
|
|
| |
llvm-svn: 219114
|
| |
|
|
| |
llvm-svn: 219113
|
| |
|
|
|
|
| |
convert them anymore.
llvm-svn: 219112
|
| |
|
|
|
|
|
|
|
| |
output of the llvm-dwarfdump and llvm-objdump report the endianness
used when the object files were generated.
Patch by Charlie Turner.
llvm-svn: 219110
|
| |
|
|
|
|
|
|
| |
RelocVisitor.
Patch by Charlie Turner.
llvm-svn: 219109
|
| |
|
|
|
|
|
|
|
| |
string comparisons and makes it a bit easier to check individual
targets.
Patch by Charlie Turner.
llvm-svn: 219108
|
| |
|
|
|
|
| |
Patch by Charlie Turner.
llvm-svn: 219107
|
| |
|
|
|
|
|
|
|
| |
These will make it easier to test further changes to the
code generation and optimization pipelines as those are
moved to subtargets initialized with target feature and
target cpu.
llvm-svn: 219106
|
| |
|
|
|
|
|
| |
Intorduced in r219098.
llvm-svn: 219105
|
| |
|
|
| |
llvm-svn: 219104
|
| |
|
|
|
|
|
|
| |
It was just calling a bunch of DwarfUnit functions anyway, as can be
seen by the simplification of removing "TheCU" from all the function
calls in the implementation.
llvm-svn: 219103
|
| |
|
|
|
|
|
| |
The above change permits developers using the lldb C++ API to
code applications in a more logical manner.
llvm-svn: 219102
|
| |
|
|
|
|
|
|
| |
By leaving these members out of the member list, we avoid them being
emitted into type unit definitions - while still allowing the
definition/declaration to be injected into the compile unit as expected.
llvm-svn: 219101
|
| |
|
|
|
|
|
|
|
|
| |
list of class members
By leaving these members out of the member list, we avoid them being
emitted into type unit definitions - while still allowing the
definition/declaration to be injected into the compile unit as expected.
llvm-svn: 219100
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: dblaikie, samsonov, echristo, aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5466
llvm-svn: 219099
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: No functional change.
Reviewers: dblaikie, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5522
llvm-svn: 219098
|
| |
|
|
|
|
|
|
| |
group's interface to all of the implementations of that analysis group.
The groups themselves can and do manage this anyways, the pass registry
needn't involve itself.
llvm-svn: 219097
|
| |
|
|
|
|
|
|
|
|
|
|
| |
pass registry.
This style of registry is somewhat questionable, but it being
non-monotonic is crazy. No one is (or should be) unloading DSOs with
passes and unregistering them here. I've checked with a few folks and
I don't know of anyone using this functionality or any important use
case where it is necessary.
llvm-svn: 219096
|
| |
|
|
|
|
| |
places.
llvm-svn: 219095
|
| |
|
|
|
|
| |
code prior to hacking on it more significantly.
llvm-svn: 219094
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we would not check the target machine type and the module (object)
machine type. Add a check to ensure that we do not attempt to use an object
file with a different target architecture.
This change identified a couple of tests which were incorrectly mixing up
architecture types, using x86 input for a x64 target. Adjust the tests
appropriately. The renaming of the input and the architectures covers the
changes to the existing tests.
One significant change to the existing tests is that the newly added test input
for x64 uses the correct user label prefix for X64.
llvm-svn: 219093
|
| |
|
|
|
|
|
|
|
|
| |
optimizing expressions.
Particularly, it addresses cases where Reassociate breaks Subtracts but then fails to optimize combinations like I1 + -I2 where I1 and I2 have the same rank and are identical.
Patch by Dmitri Shtilman.
llvm-svn: 219092
|
| |
|
|
| |
llvm-svn: 219091
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This trades a (register-renamer-friendly) movaps for a floating point
/ integer domain cross. That is a very bad trade, even on architectures
where domain crossing is relatively fast. On any chip where there is
even a cycle stall, this is a Very Bad Idea. It doesn't even seem likely
to cause a spill to be introduced because the reason for the copy is to
destructively shuffle in place.
Thanks to Ben Kramer for fixing a bug in this code that my new shuffle
lowering exposed and highlighting that perhaps it should just go away.
=]
llvm-svn: 219090
|