| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Patch by Nick Tomlinson!
llvm-svn: 206177
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add support for named values in the parser.
Reviewers: pcc
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D3276
llvm-svn: 206176
|
| |
|
|
| |
llvm-svn: 206175
|
| |
|
|
|
|
| |
Should be no other change.
llvm-svn: 206174
|
| |
|
|
| |
llvm-svn: 206173
|
| |
|
|
|
|
| |
The 32-bit pattern is still valid: 0123 -> 3210 -> 1032.
llvm-svn: 206172
|
| |
|
|
|
|
|
| |
Code change is because optimizeCompareInstr didn't know how to pull the
condition code out of FCSEL instructions.
llvm-svn: 206171
|
| |
|
|
|
|
|
| |
AArch64 tests for this, and it's obviously a good idea. Have to invert the
condition code, of course.
llvm-svn: 206170
|
| |
|
|
| |
llvm-svn: 206169
|
| |
|
|
|
|
|
|
|
| |
There was one definite issue in ARM64 (the off-by-1 check for whether
a shift could be folded in) and one difference that is probably
correct: ARM64 didn't fold nodes with multiple uses into the
arithmetic operations unless optimising for code size.
llvm-svn: 206168
|
| |
|
|
|
|
|
| |
This transformation is only valid when being used for an EQ or NE
comparison since the flags change otherwise.
llvm-svn: 206167
|
| |
|
|
| |
llvm-svn: 206166
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
#define A(a, b) (a &&b)
After:
#define A(a, b) (a && b)
This fixes llvm.org/PR19343.
llvm-svn: 206165
|
| |
|
|
| |
llvm-svn: 206164
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously loadImmediate() would produce MKMSK instructions with invalid
immediate values such as mkmsk r0, 9. Fix this by checking the mask size
is valid.
Reviewers: robertlytton
Reviewed By: robertlytton
CC: llvm-commits
Differential Revision: http://reviews.llvm.org/D3289
llvm-svn: 206163
|
| |
|
|
|
|
|
| |
Instead of choosing based on the number of elements, simply respect the
user's choice of where to wrap array literals.
llvm-svn: 206162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
NSArray* a = [[NSArray alloc] initWithArray:@[
@"a"
]
copyItems:YES];
After:
NSArray* a = [[NSArray alloc] initWithArray:@[ @"a" ]
copyItems:YES];
This fixed llvm.org/PR19080.
llvm-svn: 206161
|
| |
|
|
|
|
| |
are usable in plain C
llvm-svn: 206160
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
if (aaaaaaaa && bbbbbbbbbbbbbbb // need to wrap
== cccccccccccccc) ...
After:
if (aaaaaaaa
&& bbbbbbbbbbbbbbb // need to wrap
== cccccccccccccc) ...
The same rule has already be implemented for BreakBeforeBinaryOperators
set to false in r205527.
llvm-svn: 206159
|
| |
|
|
|
|
| |
parameter. Also fix a typo found by Tetsuo Kiso
llvm-svn: 206158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now correctly formats:
{
int a;
void f() {
callme(some(parameter1,
<<<<<<< text by the vcs
parameter2),
||||||| text by the vcs
parameter2),
parameter3,
======= text by the vcs
parameter2, parameter3),
>>>>>>> text by the vcs
otherparameter);
}
}
llvm-svn: 206157
|
| |
|
|
|
|
|
| |
This fixes PR19421.
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 206156
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
bool aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa GUARDED_BY(
aaaaaaaaaaaa) = aaaaaaaa::aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
bool aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa GUARDED_BY(aaaaaaaaaaaa) =
aaaaaaaa::aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 206155
|
| |
|
|
| |
llvm-svn: 206154
|
| |
|
|
|
|
| |
It broke some builders, at least, i686.
llvm-svn: 206153
|
| |
|
|
|
|
|
| |
declaration. GCC 4.7 appears to get hopelessly confused by declaring
this function within a member function of a class template. Go figure.
llvm-svn: 206152
|
| |
|
|
|
|
|
| |
of '@foo'. The slash variant is prefered in LLVM and the file was
already using a mixture. =/
llvm-svn: 206151
|
| |
|
|
|
|
|
|
| |
BasicTTI::getMemoryOpCost must explicitly check for non-simple types; setting
AllowUnknown=true with TLI->getSimpleValueType is not sufficient because, for
example, non-power-of-two vector types return non-simple EVTs (not MVT::Other).
llvm-svn: 206150
|
| |
|
|
|
|
|
|
|
|
|
|
| |
abstract interface. The only user of this functionality is the JIT
memory manager and it is quite happy to have a custom type here. This
removes a virtual function call and a lot of unnecessary abstraction
from the common case where this is just a *very* thin vaneer around
a call to malloc.
Hopefully still no functionality changed here. =]
llvm-svn: 206149
|
| |
|
|
|
|
|
| |
declaration outside of #ifndef NDEBUG -- its used elsewhere. Sorry for
the noise.
llvm-svn: 206148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
slabs rather than embedding a singly linked list in the slabs
themselves. This has a few advantages:
- Better utilization of the slab's memory by not wasting 16-bytes at the
front.
- Simpler allocation strategy by not having a struct packed at the
front.
- Avoids paging every allocated slab in just to traverse them for
deallocating or dumping stats.
The latter is the really nice part. Folks have complained from time to
time bitterly that tearing down a BumpPtrAllocator, even if it doesn't
run any destructors, pages in all of the memory allocated. Now it won't.
=]
Also resolves a FIXME with the scaling of the slab sizes. The scaling
now disregards specially sized slabs for allocations larger than the
threshold.
llvm-svn: 206147
|
| |
|
|
|
|
|
|
|
| |
Rather than switching behaviour on whether a previous symbol has an auxiliary
symbol record for the next count of elements, simply iterate over the auxiliary
symbols right after processing the current symbol entry. This makes the
behaviour much simpler to follow and similar to llvm-readobj and yaml2obj.
llvm-svn: 206146
|
| |
|
|
|
|
|
|
|
| |
If a filename is a multiple of 18 characters, there will be no null-terminator.
This will result in an invalid access by the constructed StringRef. Add a test
case to exercise this and fix that handling. Address this same vulnerability in
llvm-readobj as well.
llvm-svn: 206145
|
| |
|
|
| |
llvm-svn: 206144
|
| |
|
|
| |
llvm-svn: 206143
|
| |
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206142
|
| |
|
|
|
|
|
|
|
|
| |
Implements the various TTI functions to enable constant hoisting on PPC. The
only significant test-suite change is this:
MultiSource/Benchmarks/VersaBench/bmm/bmm - 20% speedup
(which essentially reverses the slowdown from r206120).
llvm-svn: 206141
|
| |
|
|
|
|
|
| |
Now that COFF::coff_aux_file is defined, use that rather than redefining the
type locally.
llvm-svn: 206140
|
| |
|
|
|
|
|
|
|
| |
The auxiliary file records are contiguous and only contain the filename.
Construct a StringRef directly rather than copying to a temporary buffer.
Suggested by majnemer on IRC!
llvm-svn: 206139
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The values for the relocation type can (and do) overlap across various
architectures. When performing an adjustment of the emitted relocation in the
final object file, check that the file magic matches the target for which the
relocation type is valid (e.g. a I386 relocation is only applied to an X86
object file, and an AMD64 relocation is only applied to an X86_64 object file).
This was noticed while adding support for ARM WinCOFF object file emission.
A test case for this is not really possible as the values for REL32 do not
overlap on I386 and AMD64, which is why this was never noticed in practice. The
ARM WinCOFF emission is not yet ready to merge into the tree.
llvm-svn: 206138
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If multiplication involves zero-extended arguments and the result is
compared as in the patterns:
%mul32 = trunc i64 %mul64 to i32
%zext = zext i32 %mul32 to i64
%overflow = icmp ne i64 %mul64, %zext
or
%overflow = icmp ugt i64 %mul64 , 0xffffffff
then the multiplication may be replaced by call to umul.with.overflow.
This change fixes PR4917 and PR4918.
Differential Revision: http://llvm-reviews.chandlerc.com/D2814
llvm-svn: 206137
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had been using the known-zero values of the operand of the or to construct
the mask for an rlwimi; this is not quite correct, but fine when the mask is
constant. When the mask is constant, then the known zeros of the operand must
be a superset of the zeros in the mask. However, when the mask is not a
constant, then there might be bits in the operand that are not known to be zero
that, at runtime, might be zero in the mask. Therefore, we check that any bits
not known to be zero *are* known to be one in the mask. Otherwise, we can't
fold the mask with the or and shift.
This was revealed as a miscompile of
MultiSource/Benchmarks/BitBench/drop3/drop3 when I started experimenting with
constant hoisting.
llvm-svn: 206136
|
| |
|
|
|
|
|
|
|
|
| |
Parse of nested name spacifier is modified so that it properly recovers
if colon is mistyped as double colon in case statement.
This patch fixes PR15133.
Differential Revision: http://llvm-reviews.chandlerc.com/D2870
llvm-svn: 206135
|
| |
|
|
| |
llvm-svn: 206134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the C-style type cast is applied to the overloaded
function and the destination type is function type,
then Clang will crash with assertion failure. For example,
void foo(int);
void foo(int, int);
void bar() {
typedef void (ft)(int);
ft p = (ft)foo;
}
In this case, the overloaded function foo will be cast to
a function type, which should be considered as an error.
But, unfortunately, since the function resolution is using
canonical type, the matched function will be returned, and
result in SEGV.
This patch fixes this issue by removing the assertion and
add some error diagnostics as the one in static_cast.
llvm-svn: 206133
|
| |
|
|
|
|
|
|
|
| |
Don't consider a __declspec(align) on a bitfield's declaration if it didn't
allocate any underlying storage.
This fixes PR19414.
llvm-svn: 206132
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I found this from a particular GDB test suite case of inlining
(something similar is provided as a test case) but came across a few
other related cases (other callers of the same functions, and one other
instance of the same coding mistake in a separate function).
I'm not sure what the best way to test this is (let alone to cover the
other cases I discovered), so hopefully this sufficies - open to ideas.
llvm-svn: 206130
|
| |
|
|
|
|
| |
check instead of comparing to nullptr.
llvm-svn: 206129
|
| |
|
|
|
|
| |
properly.
llvm-svn: 206128
|
| |
|
|
| |
llvm-svn: 206127
|