| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 206330
|
| |
|
|
| |
llvm-svn: 206329
|
| |
|
|
|
|
| |
This fixes a regression introduced in r206310.
llvm-svn: 206328
|
| |
|
|
|
|
|
| |
a default argument. The allocator interface we're modeling doesn't
distinguish between array and non-array allocation.
llvm-svn: 206327
|
| |
|
|
|
|
|
| |
in r206312, but others don't seem to show up on build bots? Unsure of
why, they showed up for me.
llvm-svn: 206326
|
| |
|
|
|
|
|
|
|
| |
because there is another (size_t, size_t) overload of Allocator, and the
only distinguishing factor is that one is a tempalte and the other
isn't. There was only one usage of this and that one was easily
converted to carry the alignment constraint in the type itself.
llvm-svn: 206325
|
| |
|
|
|
|
|
|
|
| |
alignment constraint rather than using the allocator function's over
alignment "feature". This was the only use of the "feature" which I plan
to remove next. =] Attaching the alignment to the type seems cleaner and
more principled anyways.
llvm-svn: 206324
|
| |
|
|
|
|
|
|
|
|
|
| |
handles Intrinsic::trap if TargetOptions::TrapFuncName is set.
This fixes a bug in which the trap function was not taken into consideration
when a program was compiled without optimization (at -O0).
<rdar://problem/16291933>
llvm-svn: 206323
|
| |
|
|
|
|
|
|
|
| |
This adds a warning that triggers when profile data doesn't match for
the source that's being compiled with -fprofile-instr-use=. This fires
only once per translation unit, as warning on every mismatched
function would be quite noisy.
llvm-svn: 206322
|
| |
|
|
|
|
|
| |
This comment also appears elsewhere where it actually makes sense, and
it's just confusing here.
llvm-svn: 206321
|
| |
|
|
| |
llvm-svn: 206320
|
| |
|
|
| |
llvm-svn: 206319
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following example shows a non-parallel loop
void f(int a[]) {
int i;
for (i = 0; i < 10; ++i)
A[i] = A[i+5];
}
which, in case we import a schedule that limits the iteration domain
to 0 <= i < 5, becomes parallel. Previously we crashed in such cases, now we
just recognize it as parallel.
This fixes http://llvm.org/PR19435
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 206318
|
| |
|
|
|
|
|
|
|
| |
When instantiating an array that has an alignment attribute on it, we
were looking through the array type and only considering the element
type for the resulting alignment. We need to make sure we take the
array's requirements into account too.
llvm-svn: 206317
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches the backend how to efficiently lower logical and
arithmetic packed shifts on both SSE and AVX/AVX2 machines.
When possible, instead of scalarizing a vector shift, the backend should try
to expand the shift into a sequence of two packed shifts by immedate count
followed by a MOVSS/MOVSD.
Example
(v4i32 (srl A, (build_vector < X, Y, Y, Y>)))
Can be rewritten as:
(v4i32 (MOVSS (srl A, <Y,Y,Y,Y>), (srl A, <X,X,X,X>)))
[with X and Y ConstantInt]
The advantage is that the two new shifts from the example would be lowered into
X86ISD::VSRLI nodes. This is always cheaper than scalarizing the vector into
four scalar shifts plus four pairs of vector insert/extract.
llvm-svn: 206316
|
| |
|
|
| |
llvm-svn: 206314
|
| |
|
|
| |
llvm-svn: 206313
|
| |
|
|
| |
llvm-svn: 206312
|
| |
|
|
|
|
| |
It has already been reverted on the 3.4 branch in r196521.
llvm-svn: 206311
|
| |
|
|
| |
llvm-svn: 206310
|
| |
|
|
|
|
|
| |
This allows code indexing, etc. to use the VFS in the same way as the
compiler.
llvm-svn: 206309
|
| |
|
|
|
|
| |
appear in the InlineFunctionInfo.
llvm-svn: 206308
|
| |
|
|
|
|
| |
beginning of the first new block after inlining.
llvm-svn: 206307
|
| |
|
|
|
|
|
|
|
| |
Similar to r202051, add missing loop simplification passes to the LTO
optimization pipeline.
Patch by Rafael Espindola.
llvm-svn: 206306
|
| |
|
|
|
|
|
|
| |
Fixup after r206300.
<rdar://problem/15500563>
llvm-svn: 206305
|
| |
|
|
| |
llvm-svn: 206304
|
| |
|
|
| |
llvm-svn: 206303
|
| |
|
|
|
|
|
|
|
|
| |
Sema does have a CUDALaunchBoundsAttr, but CodeGen was doing nothing with it.
This change translates CUDALaunchBoundsAttr to maxntidx and minctasm
metadata, which NVPTX then translates to the correct PTX directives.
Patch by Manjunath Kudlur.
llvm-svn: 206302
|
| |
|
|
|
|
|
|
|
| |
This is paired with a patch to LLVM that creates a separate pass for
verifying debug info.
<rdar://problem/15500563>
llvm-svn: 206301
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement DebugInfoVerifier, which steals verification relying on
DebugInfoFinder from Verifier.
- Adds LegacyDebugInfoVerifierPassPass, a ModulePass which wraps
DebugInfoVerifier. Uses -verify-di command-line flag.
- Change verifyModule() to invoke DebugInfoVerifier as well as
Verifier.
- Add a call to createDebugInfoVerifierPass() wherever there was a
call to createVerifierPass().
This implementation as a module pass should sidestep efficiency issues,
allowing us to turn debug info verification back on.
<rdar://problem/15500563>
llvm-svn: 206300
|
| |
|
|
|
|
|
|
|
| |
Split out assertion and output helpers from Verifier in preparation for
writing the DebugInfoVerifier.
<rdar://problem/15500563>
llvm-svn: 206299
|
| |
|
|
| |
llvm-svn: 206298
|
| |
|
|
| |
llvm-svn: 206297
|
| |
|
|
|
|
|
|
|
|
| |
This implements clause C.8 of the AAPCS in the front-end, so that Clang
accurately knows when the registers run out and it has to insert padding before
the stack objects begin.
PR19432.
llvm-svn: 206296
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes http://llvm.org/PR19368
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D3379
llvm-svn: 206295
|
| |
|
|
|
|
| |
This has been failing since r206202.
llvm-svn: 206294
|
| |
|
|
|
|
| |
managed by k_Memory itself.
llvm-svn: 206293
|
| |
|
|
|
|
| |
temporary Operands.
llvm-svn: 206292
|
| |
|
|
|
|
| |
No code changes for this bunch, just some test rejigs.
llvm-svn: 206291
|
| |
|
|
| |
llvm-svn: 206290
|
| |
|
|
|
|
|
|
| |
Sometimes we need emit the bits that would actually be a MOVN when producing a
relocated MOVZ instruction (don't ask). But not always, a check which ARM64 got
wrong until now.
llvm-svn: 206289
|
| |
|
|
|
|
|
| |
I've left the MachO CodeGen as it is, there's a reasonable chance it should use
the GOT like ConstPools, but I'm not certain.
llvm-svn: 206288
|
| |
|
|
| |
llvm-svn: 206287
|
| |
|
|
|
|
|
| |
This brings it into line with the AArch64 behaviour and should open the way for
certain OpenCL features.
llvm-svn: 206286
|
| |
|
|
|
|
|
|
| |
Code is mostly copied directly across, with a slight extension of the
ISelDAGToDAG function so that it can cope with the floating-point constants
being behind a litpool.
llvm-svn: 206285
|
| |
|
|
| |
llvm-svn: 206284
|
| |
|
|
|
|
|
|
|
|
|
| |
ARM64 suffered multiple -verify-machineinstr failures (principally over the
xsp/xzr issue) because FastISel was completely ignoring which subset of the
general-purpose registers each instruction required.
More fixes are coming in ARM64 specific FastISel, but this should cover the
generic problems.
llvm-svn: 206283
|
| |
|
|
| |
llvm-svn: 206282
|
| |
|
|
| |
llvm-svn: 206281
|
| |
|
|
|
|
| |
larger than needed. This was a leftover of the allocator1=>allocator2 migration; thanks Yuri Gribov for reminding
llvm-svn: 206280
|