| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 175310
|
| |
|
|
|
|
|
|
|
|
|
| |
is a vararg function.
The original code was examining flag OutputArg::IsFixed to determine whether
CC_MipsN_VarArg or CC_MipsN should be called. This is not correct, since this
flag is often set to false when the function being analyzed is a non-variadic
function.
llvm-svn: 174442
|
| |
|
|
| |
llvm-svn: 174410
|
| |
|
|
|
|
| |
Patch by Sasa Stankovic.
llvm-svn: 173862
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conditions are met:
1. They share the same operand and are in the same BB.
2. Both outputs are used.
3. The target has a native instruction that maps to ISD::FSINCOS node or
the target provides a sincos library call.
Implemented the generic optimization in sdisel and enabled it for
Mac OSX. Also added an additional optimization for x86_64 Mac OSX by
using an alternative entry point __sincos_stret which returns the two
results in xmm0 / xmm1.
rdar://13087969
PR13204
llvm-svn: 173755
|
| |
|
|
|
|
| |
Fixes a -Wunused warning.
llvm-svn: 173664
|
| |
|
|
| |
llvm-svn: 173649
|
| |
|
|
| |
llvm-svn: 173563
|
| |
|
|
|
|
|
|
| |
[-Wsometimes-uninitialized]
FIXME: Could they, unreachable(s), be removed?
FIXME: I could prefer the coding standards...
llvm-svn: 173325
|
| |
|
|
|
|
| |
...and fix a typo, s/#ifdef/#ifndef/
llvm-svn: 173324
|
| |
|
|
| |
llvm-svn: 173323
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow Mips16 routines to call Mips32 routines that have abi requirements
that either arguments or return values are passed in floating point
registers. This handles only the pic case. We have not done non pic
for Mips16 yet in any form.
The libm functions are Mips32, so with this addition we have a complete
Mips16 hard float implementation.
We still are not able to complete mix Mip16 and Mips32 with hard float.
That will be the next phase which will have several steps. For Mips32
to freely call Mips16 some stub functions must be created.
llvm-svn: 173320
|
| |
|
|
|
|
| |
intended
llvm-svn: 173189
|
| |
|
|
|
|
| |
vectors are being compared.
llvm-svn: 171517
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
| |
|
|
| |
llvm-svn: 170669
|
| |
|
|
| |
llvm-svn: 170667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this case, essentially it is soft float with different library routines.
The next step will be to make this fully interoperational with mips32 floating
point and that requires creating stubs for functions with signatures that
contain floating point types.
I have a more sophisticated design for mips16 hardfloat which I hope to
implement at a later time that directly does floating point without the need
for function calls.
The mips16 encoding has no floating point instructions so one needs to
switch to mips32 mode to execute floating point instructions.
llvm-svn: 170259
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Accordingly, add helper funtions getSimpleValueType (in parallel to
getValueType) in SDValue, SDNode, and TargetLowering.
This is the first, in a series of patches.
This is the second attempt. In the first attempt (r169837), a few
getSimpleVT() were hoisted too far, detected by bootstrap failures.
llvm-svn: 170104
|
| |
|
|
|
|
| |
internal linkage.
llvm-svn: 170092
|
| |
|
|
|
|
|
|
|
|
|
|
| |
mention the inline memcpy / memset expansion code is a mess?
This patch split the ZeroOrLdSrc argument into two: IsMemset and ZeroMemset.
The first indicates whether it is expanding a memset or a memcpy / memmove.
The later is whether the memset is a memset of zero. It's totally possible
(likely even) that targets may want to do different things for memcpy and
memset of zero.
llvm-svn: 169959
|
| |
|
|
|
|
|
|
|
| |
Also added more comments to explain why it is generally ok to return true.
- Rename getOptimalMemOpType argument IsZeroVal to ZeroOrLdSrc. It's meant to
be true for loaded source (memcpy) or zero constants (memset). The poor name
choice is probably some kind of legacy issue.
llvm-svn: 169954
|
| |
|
|
| |
llvm-svn: 169854
|
| |
|
|
|
|
|
|
|
| |
Accordingly, add helper funtions getSimpleValueType (in parallel to
getValueType) in SDValue, SDNode, and TargetLowering.
This is the first, in a series of patches.
llvm-svn: 169837
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Teach it to use overlapping unaligned load / store to copy / set the trailing
bytes. e.g. On 86, use two pairs of movups / movaps for 17 - 31 byte copies.
2. Use f64 for memcpy / memset on targets where i64 is not legal but f64 is. e.g.
x86 and ARM.
3. When memcpy from a constant string, do *not* replace the load with a constant
if it's not possible to materialize an integer immediate with a single
instruction (required a new target hook: TLI.isIntImmLegal()).
4. Use unaligned load / stores more aggressively if target hooks indicates they
are "fast".
5. Update ARM target hooks to use unaligned load / stores. e.g. vld1.8 / vst1.8.
Also increase the threshold to something reasonable (8 for memset, 4 pairs
for memcpy).
This significantly improves Dhrystone, up to 50% on ARM iOS devices.
rdar://12760078
llvm-svn: 169791
|
| |
|
|
|
|
| |
use.
llvm-svn: 169580
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
| |
|
|
| |
llvm-svn: 168460
|
| |
|
|
|
|
| |
functions added in r168456.
llvm-svn: 168458
|
| |
|
|
| |
llvm-svn: 168456
|
| |
|
|
| |
llvm-svn: 168455
|
| |
|
|
|
|
| |
referring to a GOT entry.
llvm-svn: 168453
|
| |
|
|
| |
llvm-svn: 168230
|
| |
|
|
|
|
| |
Patch by Sasa Stankovic.
llvm-svn: 167548
|
| |
|
|
| |
llvm-svn: 167546
|
| |
|
|
|
|
| |
of the incoming argument area.
llvm-svn: 167312
|
| |
|
|
|
|
| |
use the caller's stack.
llvm-svn: 167048
|
| |
|
|
|
|
|
| |
information will be used by IsEligibleForTailCallOptimization to determine
whether a call can be tail-call optimized.
llvm-svn: 167043
|
| |
|
|
|
|
| |
for passing a function call argument on a stack.
llvm-svn: 167041
|
| |
|
|
| |
llvm-svn: 167039
|
| |
|
|
| |
llvm-svn: 166935
|
| |
|
|
|
|
|
|
| |
arguments.
This is rather conservative and should be fixed later to be more aggressive.
llvm-svn: 166851
|
| |
|
|
|
|
| |
previous iteration.
llvm-svn: 166850
|
| |
|
|
|
|
|
|
| |
LowerFormalArguments in MipsTargetLowering.
No functionality change intended.
llvm-svn: 166846
|
| |
|
|
|
|
| |
of vararg functions back to the stack.
llvm-svn: 166844
|
| |
|
|
|
|
|
|
| |
This method emits nodes for passing byval arguments in registers and stack.
This has the same functionality as existing functions PassByValArg64 and
WriteByValArg which will be deleted later.
llvm-svn: 166843
|
| |
|
|
|
|
|
|
| |
This method copies byval arguments passed in registers onto the stack and has
the same functionality as existing functions CopyMips64ByValRegs and
ReadByValArg which will be deleted later.
llvm-svn: 166841
|
| |
|
|
|
|
| |
arguments and inquire about calling convention information.
llvm-svn: 166840
|
| |
|
|
| |
llvm-svn: 166837
|
| |
|
|
| |
llvm-svn: 166539
|