| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
The most important part here is that we should actuall emit the stubs we refer
to in the exception table, but as a side issue this uses more sensible & GCC
compatible representations for some of the bits of information.
llvm-svn: 206380
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If we know that a particular 64-bit constant has all high bits zero, then we
can rely on the fact that 32-bit ARM64 instructions automatically zero out the
high bits of an x-register. This gives the expansion logic less constraints to
satisfy and so sometimes allows it to pick better sequences.
Came up while porting test/CodeGen/AArch64/movw-consts.ll: this will allow a
32-bit MOVN to be used in @test8 soon.
llvm-svn: 206379
|
| |
|
|
| |
llvm-svn: 206378
|
| |
|
|
|
|
|
|
|
|
|
| |
if not in micromips mode.
The test (elf_st_other.ll) was renamed as the name and description didn't
make sense as the test wasn't checking any symbol table entry.
Differential Revision: http://reviews.llvm.org/D3346
llvm-svn: 206377
|
| |
|
|
|
|
| |
range-based for loop is confused by the DEBUG macro expansion unless a compound statement is used.
llvm-svn: 206376
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D3339
Reviewers: matheusalmeida, vmedic
Reviewed By: matheusalmeida
Differential Revision: http://reviews.llvm.org/D3340
llvm-svn: 206371
|
| |
|
|
|
|
|
|
| |
The second half of a split i128 was ending up in x7, which is not a good thing.
This is another part of PR19432.
llvm-svn: 206366
|
| |
|
|
|
|
|
|
|
|
|
| |
This particular DAG combine is designed to kick in when both ConstantFPs will
end up being loaded via a litpool, however those nodes have a semi-legal
status, dictated by isFPImmLegal so in some cases there wouldn't have been a
litpool in the first place. Don't try to be clever in those circumstances.
Picked up while merging some AArch64 tests.
llvm-svn: 206365
|
| |
|
|
| |
llvm-svn: 206363
|
| |
|
|
|
|
|
|
|
|
| |
Adjust the tests to validate the number of auxiliary entries used to store the
filename.
Thanks to majnemer's sharp eye for catching the missing - 1 in the round up
calculation.
llvm-svn: 206359
|
| |
|
|
| |
llvm-svn: 206357
|
| |
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206356
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for emitting .file records. This is mostly a quality of
implementation change (more complete support for COFF file emission) that was
noticed while working on COFF file emission for Windows on ARM.
A .file record is emitted as a symbol with storage class FILE (103) and the name
".file". A series of auxiliary format 4 records follow which contain the file
name. The filename is stored as an ANSI string and is padded with NULL if the
length is not a multiple of COFF::SymbolSize (18).
llvm-svn: 206355
|
| |
|
|
| |
llvm-svn: 206353
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting vector types to expand will result in scalarization on pre SI hw,
as those gpus don't have vector shifts either.
Expand also i32 vectors, this helps llvm make the correct decision
about scalarizing the vector ops.
v2: move setOperation() calls to R600ISelLowering.cpp.
cleanup the SI code to make it obvious that this patch does is nop for SI
Patch by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 206348
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 206344
|
| |
|
|
|
|
| |
Missed in previous commit.
llvm-svn: 206343
|
| |
|
|
|
|
|
|
| |
Range'ify a bunch of loops, mainly. As a result, we have a variety
of objects via reference rather than by pointer, so propogate that
through the various helper functions where it makes sense.
llvm-svn: 206337
|
| |
|
|
| |
llvm-svn: 206336
|
| |
|
|
|
|
|
|
|
| |
Print in decimal for inline immediates, and hex otherwise. Use hex
always for offsets in addressing offsets.
This approximately matches what the shader compiler does.
llvm-svn: 206335
|
| |
|
|
|
|
| |
Try to figure out the class and number of subregisters.
llvm-svn: 206334
|
| |
|
|
| |
llvm-svn: 206330
|
| |
|
|
|
|
| |
This fixes a regression introduced in r206310.
llvm-svn: 206328
|
| |
|
|
|
|
|
|
|
|
|
| |
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 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: 206313
|
| |
|
|
|
|
| |
It has already been reverted on the 3.4 branch in r196521.
llvm-svn: 206311
|
| |
|
|
| |
llvm-svn: 206310
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 206297
|
| |
|
|
|
|
| |
managed by k_Memory itself.
llvm-svn: 206293
|
| |
|
|
|
|
| |
temporary Operands.
llvm-svn: 206292
|
| |
|
|
| |
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: 206281
|
| |
|
|
| |
llvm-svn: 206279
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D3328
llvm-svn: 206276
|
| |
|
|
|
|
| |
CodeGenOnly defined instructions and post matcher expansion methods to emit real instructions add with immediate. However, they can directly alias add with immediate instruction and remove unnecessary definitions and code in MipsAsmParser.cpp. This patch makes no change in functionality, just removes unnecessary definitions and code.
llvm-svn: 206272
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by removing the MallocSlabAllocator entirely and just using
MallocAllocator directly. This makes all off these allocators expose and
utilize the same core interface.
The only ugly part of this is that it exposes the fact that the JIT
allocator has no real handling of alignment, any more than the malloc
allocator does. =/ It would be nice to fix both of these to support
alignments, and then to leverage that in the BumpPtrAllocator to do less
over allocation in order to manually align pointers. But, that's another
patch for another day. This patch has no functional impact, it just
removes the somewhat meaningless wrapper around MallocAllocator.
llvm-svn: 206267
|