| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This bug was introduced in r213006 which makes an assumption that MCSection is COFF for Windows MSVC. This assumption is broken for MCJIT users where ELF is used instead [1]. The fix is to change the MCSection cast to a dyn_cast.
[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-December/068407.html.
Reviewers: majnemer
Reviewed By: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D4872
llvm-svn: 216173
|
| |
|
|
|
|
| |
While there remove noop casts.
llvm-svn: 216168
|
| |
|
|
| |
llvm-svn: 216164
|
| |
|
|
| |
llvm-svn: 216163
|
| |
|
|
| |
llvm-svn: 216162
|
| |
|
|
|
|
|
|
| |
Added FeatureSMAP.
Broadwell ISA includes Haswell ISA + ADX + RDSEED + SMAP
llvm-svn: 216161
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for PR20648 - http://llvm.org/bugs/show_bug.cgi?id=20648
This patch checks the operands of a vselect to see if all values are constants.
If yes, bail out of any further attempts to create a blend or shuffle because
SelectionDAGLegalize knows how to turn this kind of vselect into a single load.
This already happens for machines without SSE4.1, so the added checks just send
more targets down that path.
Differential Revision: http://reviews.llvm.org/D4934
llvm-svn: 216121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of the patch is to implement section 3.2.3 of the AMD64 ABI
correctly. The controlling sentence is, "The size of each argument gets
rounded up to eightbytes. Therefore the stack will always be eightbyte
aligned." The equivalent sentence in the i386 ABI page 37 says, "At all
times, the stack pointer should point to a word-aligned area." For both
architectures, the stack pointer is not being rounded up to the nearest
eightbyte or word between the last normal argument and the first
variadic argument.
Patch by Thomas Jablin!
llvm-svn: 216119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This fixes http://llvm.org/bugs/show_bug.cgi?id=19530.
The problem is that X86ISelLowering erroneously thought the third call
was eligible for tail call elimination.
It would have been if it's return value was actually the one returned
by the calling function, but here that is not the case and
additional values are being returned.
Test Plan: Test case from the original bug report is included.
Reviewers: rafael
Reviewed By: rafael
Subscribers: rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D4968
llvm-svn: 216117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes http://llvm.org/bugs/show_bug.cgi?id=20016 reproducible on new
lea-5.ll case.
Also use RSP/RBP for x32 lea to save 1 byte used for 0x67 prefix in
ESP/EBP case.
Test Plan: lea tests modified to include x32/nacl and new test added
Reviewers: nadav, dschuff, t.p.northover
Subscribers: llvm-commits, zinovy.nis
Differential Revision: http://reviews.llvm.org/D4929
llvm-svn: 216065
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
floating-point constants (r215595).
Note: This was originally reverted to track down a buildbot error. Reapply
without any modifications.
Original commit message:
In the large code model for X86 floating-point constants are placed in the
constant pool and materialized by loading from it. Since the constant pool
could be far away, a PC relative load might not work. Therefore we first
materialize the address of the constant pool with a movabsq and then load
from there the floating-point value.
Fixes <rdar://problem/17674628>.
llvm-svn: 216012
|
| |
|
|
|
|
|
| |
Note: This was originally reverted to track down a buildbot error. Reapply
without any modifications.
llvm-svn: 216011
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant materialization (r215593).
Note: This was originally reverted to track down a buildbot error. Reapply
without any modifications.
Original commit message:
This mostly affects the i64 value type, which always resulted in an 15byte
mobavsq instruction to materialize any constant. The custom code checks the
value of the immediate and tries to use a different and smaller mov
instruction when possible.
This fixes <rdar://problem/17420988>.
llvm-svn: 216010
|
| |
|
|
|
|
| |
<rdar://problem/16952634>
llvm-svn: 215962
|
| |
|
|
|
|
| |
<rdar://problem/15607571>
llvm-svn: 215924
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point XMM and YMM instructions.
Sub-group: Other instructions.
<rdar://problem/15607571>
llvm-svn: 215923
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point XMM and YMM instructions.
Sub-group: Logic instructions.
<rdar://problem/15607571>
llvm-svn: 215922
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point XMM and YMM instructions.
Sub-group: Math instructions.
<rdar://problem/15607571>
llvm-svn: 215921
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point XMM and YMM instructions.
Sub-group: Arithmetic instructions.
<rdar://problem/15607571>
llvm-svn: 215920
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point XMM and YMM instructions.
Sub-group: Conversion instructions.
<rdar://problem/15607571>
llvm-svn: 215919
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point XMM and YMM instructions.
Sub-group: Move instructions.
<rdar://problem/15607571>
llvm-svn: 215918
|
| |
|
|
|
|
|
|
|
| |
Group: Integer MMX and XMM instructions.
Sub-group: Other instructions.
<rdar://problem/15607571>
llvm-svn: 215917
|
| |
|
|
|
|
|
|
|
| |
Group: Integer MMX and XMM instructions.
Sub-group: Logic instructions.
<rdar://problem/15607571>
llvm-svn: 215916
|
| |
|
|
|
|
|
|
|
| |
Group: Integer MMX and XMM instructions.
Sub-group: Arithmetic instructions.
<rdar://problem/15607571>
llvm-svn: 215915
|
| |
|
|
|
|
|
|
|
| |
Group: Integer MMX and XMM instructions.
Sub-group: Move instructions.
<rdar://problem/15607571>
llvm-svn: 215914
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point x87 instructions.
Sub-group: Math instructions.
<rdar://problem/15607571>
llvm-svn: 215913
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point x87 instructions.
Sub-group: Arithmetic instructions.
<rdar://problem/15607571>
llvm-svn: 215912
|
| |
|
|
|
|
|
|
|
| |
Group: Floating Point x87 instructions.
Sub-group: Move instructions.
<rdar://problem/15607571>
llvm-svn: 215911
|
| |
|
|
|
|
|
|
|
| |
Group: Integer instructions.
Sub-group: Other instructions.
<rdar://problem/15607571>
llvm-svn: 215910
|
| |
|
|
|
|
|
|
|
| |
Group: Integer instructions.
Sub-group: Synchronization instructions.
<rdar://problem/15607571>
llvm-svn: 215909
|
| |
|
|
|
|
|
|
|
| |
Group: Integer instructions.
Sub-group: String instructions.
<rdar://problem/15607571>
llvm-svn: 215908
|
| |
|
|
|
|
|
|
|
| |
Group: Integer instructions.
Sub-group: Control transfer instructions.
<rdar://problem/15607571>
llvm-svn: 215907
|
| |
|
|
|
|
|
|
|
| |
Group: Integer instructions.
Sub-group: Logic instructions.
<rdar://problem/15607571>
llvm-svn: 215906
|
| |
|
|
|
|
|
|
|
| |
Group: Integer instructions.
Sub-group: Arithmetic instructions.
<rdar://problem/15607571>
llvm-svn: 215905
|
| |
|
|
|
|
|
|
|
| |
Group: Integer instructions.
Sub-group: Move instructions.
<rdar://problem/15607571>
llvm-svn: 215904
|
| |
|
|
|
|
| |
Added a test.
llvm-svn: 215889
|
| |
|
|
|
|
|
|
|
|
| |
ARM in particular is getting dangerously close to exceeding 32 bits worth of
possible subtarget features. When this happens, various parts of MC start to
fail inexplicably as masks get truncated to "unsigned".
Mostly just refactoring at present, and there's probably no way to test.
llvm-svn: 215887
|
| |
|
|
| |
llvm-svn: 215828
|
| |
|
|
| |
llvm-svn: 215827
|
| |
|
|
|
|
|
| |
It should remove dosens of lines in handling instrinsics (in a huge switch) and give an easy way to add new intrinsics.
I did not completed to move al intrnsics to the table, I'll do this in the upcomming commits.
llvm-svn: 215826
|
| |
|
|
|
|
| |
clang-format.
llvm-svn: 215824
|
| |
|
|
|
|
|
| |
instructions for blend operations at 128 bits. This was a serious hole
in our prior blend lowering.
llvm-svn: 215819
|
| |
|
|
| |
llvm-svn: 215789
|
| |
|
|
|
|
|
|
|
|
|
|
| |
MSVC gives this awesome diagnostic:
..\lib\Target\X86\X86ISelLowering.cpp(7085) : error C2971: 'llvm::VariadicFunction1' : template parameter 'Func' : 'isShuffleEquivalentImpl' : a local variable cannot be used as a non-type argument
..\include\llvm/ADT/VariadicFunction.h(153) : see declaration of 'llvm::VariadicFunction1'
..\lib\Target\X86\X86ISelLowering.cpp(7061) : see declaration of 'isShuffleEquivalentImpl'
Using an anonymous namespace makes the problem go away.
llvm-svn: 215744
|
| |
|
|
|
|
| |
where applicable for blending.
llvm-svn: 215737
|
| |
|
|
|
|
| |
We already require CFI, so it should be safe to require .leb128 and .uleb128.
llvm-svn: 215712
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the new shuffle lowering and an implementation for v4 shuffles.
This allows us to handle non-half-crossing shuffles directly for v4
shuffles, both integer and floating point. This currently misses places
where we could perform the blend via UNPCK instructions, but otherwise
generates equally good or better code for the test cases included to the
existing vector shuffle lowering. There are a few cases that are
entertainingly better. ;]
llvm-svn: 215702
|
| |
|
|
|
|
|
|
|
| |
BLENDPS, BLENDPD, and PBLENDW instructions into pretty shuffle comments.
These will be used in my next commit as part of test cases for AVX
shuffles which can directly use blend in more places.
llvm-svn: 215701
|
| |
|
|
|
|
|
| |
elements of a shuffle mask and simplify how it works. No functionality
changed now that the bug that was here has been fixed.
llvm-svn: 215696
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target-specific shuffl DAG combines.
We were recognizing the paired shuffles backwards. This code needs to be
replaced anyways as we have the same functionality elsewhere, but I'll
do the refactoring in a follow-up, this is the minimal fix to the
behavior.
In addition to fixing miscompiles with the new vector shuffle lowering,
it also causes the canonicalization to kick in much better, selecting
the smaller encoding variants in lots of places in the new AVX path.
This still isn't quite ideal as we don't need both the shufpd and the
punpck instructions, but that'll get fixed in a follow-up patch.
llvm-svn: 215690
|