| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
has hard float, when you compile the mips32 code you have to make sure
that it knows to compile any mips32 routines as hard float. I need to clean
up the way mips16 hard float is specified but I need to first think through
all the details. Mips16 always has a form of soft float, the difference being
whether the underlying hardware has floating point. So it's not really
necessary to pass the -soft-float to llvm since soft-float is always true
for mips16 by virtue of the fact that it will not register floating point
registers. By using this fact, I can simplify the way this is all handled.
llvm-svn: 189690
|
| |
|
|
|
|
|
|
|
| |
Yet another chunk of fast-isel code. This one handles various
conversions involving floating-point. (It also includes some
miscellaneous handling throughout the back end for LWA_32 and LWAX_32
that should have been part of the load-store patch.)
llvm-svn: 189677
|
| |
|
|
| |
llvm-svn: 189673
|
| |
|
|
|
|
| |
Currently this is just the atom model with SSE4.2 enabled.
llvm-svn: 189669
|
| |
|
|
| |
llvm-svn: 189656
|
| |
|
|
| |
llvm-svn: 189654
|
| |
|
|
|
|
| |
Y), -1)). Fixes PR17038.
llvm-svn: 189653
|
| |
|
|
|
|
|
|
| |
This reverts commit r189619.
The commit was breaking the arm_neon_intrinsic test.
llvm-svn: 189648
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
liveness later.
Created SUPressureDiffs array to hold the per node PDiff computed during DAG building.
Added a getUpwardPressureDelta API that will soon replace the old
one. Compute PressureDelta here from the precomputed PressureDiffs.
Updating for liveness will come next.
llvm-svn: 189640
|
| |
|
|
|
|
|
| |
Mostly trivial patch adding support for compares. The meat of the
work was added with the branch support.
llvm-svn: 189639
|
| |
|
|
| |
llvm-svn: 189638
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the next big chunk of fast-isel code. The primary purpose is
to implement selection of loads and stores, but there is a lot of
drag-along to support this. The common code to analyze addresses for
both loads and stores is substantial. It's also necessary to add the
materialization code for global values.
Related to load-store processing is the code to fold loads into
integer extends, since otherwise we generate lots of redundant
instructions. We also need to add some overrides to some FastEmit
routines to ensure we don't assign GPR 0 to a virtual register when
this would change the meaning of an instruction.
I added handling selection of a few binary arithmetic instructions, to
enable committing some test cases I wrote a while back.
Finally, ap couple of miscellaneous changes:
* I cleaned up some poor style from a previous patch in
PPCISelLowering.cpp, pointed out by David Blaikie.
* I enlarged the Addr.Offset field to avoid sign problems with 32-bit
offsets.
llvm-svn: 189636
|
| |
|
|
|
|
|
|
|
|
|
| |
In addition to recognizing when the multiply's second argument is
coming from an explicit VDUPLANE, also look for a plain scalar
f32 reference and reference it via the corresponding vector
lane.
rdar://14870054
llvm-svn: 189619
|
| |
|
|
|
|
| |
if the target is iOS and Linux.
llvm-svn: 189604
|
| |
|
|
| |
llvm-svn: 189580
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There are several optional (off-by-default) features in CodeGen that can make
use of alias analysis. These features are important for generating code for
some kinds of cores (for example the (in-order) PPC A2 core). This adds a
useAA() function to TargetSubtargetInfo to allow these features to be enabled
by default on a per-subtarget basis.
Here is the first use of this function: To control the default of the
-enable-aa-sched-mi feature.
llvm-svn: 189563
|
| |
|
|
|
|
|
|
|
|
|
|
| |
32-bit absolute addressing in instructions likei this:
mov $_f, %rsi
which is not supported in 64-bit mode.
rdar://8827134
llvm-svn: 189543
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix a few things in one swoop.
# Add some negative tests.
# Fix some formatting issues.
# Add some missing IsThumb / ARMv8
# Fix some outs / ins mistakes.
llvm-svn: 189490
|
| |
|
|
|
|
|
|
| |
The usual default of "dmb ish" (inner-shareable) isn't even a valid instruction
on v6M or v7M (well, it does the same thing but software is strongly
discouraged from using it) so we should emit a full-system barrier there.
llvm-svn: 189483
|
| |
|
|
| |
llvm-svn: 189482
|
| |
|
|
|
|
|
| |
Clang is now generating cleaner IR, so this removes the old variants which
should be completely unused.
llvm-svn: 189481
|
| |
|
|
|
|
|
|
|
| |
The vqdmlal and vqdmlls instructions are really just a fused pair consisting of
a vqdmull.sN and a vqadd.sN. This adds patterns to LLVM so that we can switch
Clang's CodeGen over to generating these instead of the special vqdmlal
intrinsics.
llvm-svn: 189480
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These intrinsics are legalized to V(ALL|ANY)_(NON)?ZERO nodes,
are matched as SN?Z_[BHWDV]_PSEUDO pseudo's, and emitted as
a branch/mov sequence to evaluate to 0 or 1.
Note: The resulting code is sub-optimal since it doesnt seem to be possible
to feed the result of an intrinsic directly into a brcond. At the moment
it uses (SETCC (VALL_ZERO $ws), 0, SETEQ) and similar which unnecessarily
evaluates the boolean twice.
llvm-svn: 189478
|
| |
|
|
| |
llvm-svn: 189476
|
| |
|
|
| |
llvm-svn: 189472
|
| |
|
|
| |
llvm-svn: 189471
|
| |
|
|
|
|
|
|
|
| |
For now just handles simple comparisons of an ANDed value with zero.
The CC value provides enough information to do any comparison for a
2-bit mask, and some nonzero comparisons with more populated masks,
but that's all future work.
llvm-svn: 189469
|
| |
|
|
|
|
|
|
| |
The MSA control registers have been added as reserved registers,
and are only used via ISD::Copy(To|From)Reg. The intrinsics are lowered
into these nodes.
llvm-svn: 189468
|
| |
|
|
|
|
| |
ftrunc_[su], hadd_[su], hsub_[su], sr[al]r, sr[al]ri
llvm-svn: 189467
|
| |
|
|
|
|
| |
This uses the infrastructure added for memcpy and memmove in r189331.
llvm-svn: 189458
|
| |
|
|
| |
llvm-svn: 189456
|
| |
|
|
|
|
| |
in use supports it.
llvm-svn: 189439
|
| |
|
|
|
|
| |
For now, (defined(X86_64_JIT) && defined(__CYGWIN__)) satisfies Cygwin64.
llvm-svn: 189437
|
| |
|
|
|
|
| |
In the LLVM side, x86_64-cygwin is almost as same as x86_64-mingw32.
llvm-svn: 189436
|
| |
|
|
|
|
| |
Also, fix predicates.
llvm-svn: 189432
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 189431
|
| |
|
|
| |
llvm-svn: 189430
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: MASM let's you do stuff like 'MOV FS:20, EAX' and 'MOV EAX, FS:20'
Reviewers: craig.topper, rnk
Reviewed By: rnk
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1470
llvm-svn: 189407
|
| |
|
|
|
|
|
| |
first. Use this to turn the PPC modifiers into PPC specific expressions,
allowing them to work on constants.
llvm-svn: 189400
|
| |
|
|
| |
llvm-svn: 189396
|
| |
|
|
| |
llvm-svn: 189388
|
| |
|
|
| |
llvm-svn: 189349
|
| |
|
|
|
|
| |
Fix two issues I found while writing these tests.
llvm-svn: 189341
|
| |
|
|
|
|
|
|
| |
These instructions aren't particularly complicated and it's well worth having
patterns for some reasonably useful LLVM IR that will match them. Soon we
should be able to switch Clang over to producing this natural version.
llvm-svn: 189335
|
| |
|
|
| |
llvm-svn: 189332
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lengths up to a certain threshold (currently 6 * 256) use a series of MVCs.
Lengths above that threshold use a loop to handle X*256 bytes followed
by a single MVC to handle the excess (if any). This loop will also be
needed in future when support for variable lengths is added.
Because the same tablegen classes are used to define MVC and CLC,
the patch also has the side-effect of defining a pseudo loop instruction
for CLC. That instruction isn't used yet (and wouldn't be handled correctly
if it were). I'm planning to use it soon though.
llvm-svn: 189331
|
| |
|
|
| |
llvm-svn: 189330
|
| |
|
|
| |
llvm-svn: 189326
|
| |
|
|
|
|
|
|
|
| |
Object/MachOFormat.h over to Support/MachO.h."
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
llvm-svn: 189321
|
| |
|
|
| |
llvm-svn: 189315
|