2005-10-16 13:39:50 +08:00
|
|
|
//===-- PPCISelLowering.h - PPC32 DAG Lowering Interface --------*- C++ -*-===//
|
2005-08-17 01:14:42 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-08-17 01:14:42 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines the interfaces that PPC uses to lower LLVM code into a
|
|
|
|
// selection DAG.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:26:38 +08:00
|
|
|
#ifndef LLVM_LIB_TARGET_POWERPC_PPCISELLOWERING_H
|
|
|
|
#define LLVM_LIB_TARGET_POWERPC_PPCISELLOWERING_H
|
2005-08-17 01:14:42 +08:00
|
|
|
|
2005-10-15 07:51:18 +08:00
|
|
|
#include "PPC.h"
|
2013-04-06 07:29:01 +08:00
|
|
|
#include "PPCInstrInfo.h"
|
2013-03-22 05:37:52 +08:00
|
|
|
#include "PPCRegisterInfo.h"
|
2013-06-13 00:39:22 +08:00
|
|
|
#include "llvm/CodeGen/CallingConvLower.h"
|
2014-01-07 19:48:04 +08:00
|
|
|
#include "llvm/CodeGen/SelectionDAG.h"
|
2012-12-04 15:12:27 +08:00
|
|
|
#include "llvm/Target/TargetLowering.h"
|
2005-08-17 01:14:42 +08:00
|
|
|
|
|
|
|
namespace llvm {
|
2005-08-27 04:25:03 +08:00
|
|
|
namespace PPCISD {
|
2015-05-08 05:33:59 +08:00
|
|
|
enum NodeType : unsigned {
|
2007-01-27 06:40:50 +08:00
|
|
|
// Start the numbering where the builtin ops and target ops leave off.
|
2008-09-24 02:42:32 +08:00
|
|
|
FIRST_NUMBER = ISD::BUILTIN_OP_END,
|
2005-08-27 04:25:03 +08:00
|
|
|
|
|
|
|
/// FSEL - Traditional three-operand fsel node.
|
|
|
|
///
|
|
|
|
FSEL,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2005-09-07 06:03:27 +08:00
|
|
|
/// FCFID - The FCFID instruction, taking an f64 operand and producing
|
|
|
|
/// and f64 value containing the FP representation of the integer that
|
|
|
|
/// was temporarily in the f64 operand.
|
|
|
|
FCFID,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2013-04-02 01:52:07 +08:00
|
|
|
/// Newer FCFID[US] integer-to-floating-point conversion instructions for
|
|
|
|
/// unsigned integers and single-precision outputs.
|
|
|
|
FCFIDU, FCFIDS, FCFIDUS,
|
|
|
|
|
2013-09-26 13:22:11 +08:00
|
|
|
/// FCTI[D,W]Z - The FCTIDZ and FCTIWZ instructions, taking an f32 or f64
|
|
|
|
/// operand, producing an f64 value containing the integer representation
|
|
|
|
/// of that FP value.
|
|
|
|
FCTIDZ, FCTIWZ,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2013-04-02 01:52:07 +08:00
|
|
|
/// Newer FCTI[D,W]UZ floating-point-to-integer conversion instructions for
|
|
|
|
/// unsigned integers.
|
|
|
|
FCTIDUZ, FCTIWUZ,
|
|
|
|
|
2013-04-03 12:01:11 +08:00
|
|
|
/// Reciprocal estimate instructions (unary FP ops).
|
|
|
|
FRE, FRSQRTE,
|
|
|
|
|
2005-12-14 06:55:22 +08:00
|
|
|
// VMADDFP, VNMSUBFP - The VMADDFP and VNMSUBFP instructions, taking
|
|
|
|
// three v4f32 operands and producing a v4f32 result.
|
|
|
|
VMADDFP, VNMSUBFP,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-03-20 09:53:53 +08:00
|
|
|
/// VPERM - The PPC VPERM Instruction.
|
|
|
|
///
|
|
|
|
VPERM,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2016-05-05 00:04:02 +08:00
|
|
|
/// XXSPLT - The PPC VSX splat instructions
|
|
|
|
///
|
|
|
|
XXSPLT,
|
|
|
|
|
2016-07-13 05:00:10 +08:00
|
|
|
/// XXINSERT - The PPC VSX insert instruction
|
|
|
|
///
|
|
|
|
XXINSERT,
|
|
|
|
|
|
|
|
/// VECSHL - The PPC VSX shift left instruction
|
|
|
|
///
|
|
|
|
VECSHL,
|
|
|
|
|
2015-01-03 09:16:37 +08:00
|
|
|
/// The CMPB instruction (takes two operands of i32 or i64).
|
|
|
|
CMPB,
|
|
|
|
|
2005-11-17 15:30:41 +08:00
|
|
|
/// Hi/Lo - These represent the high and low 16-bit parts of a global
|
|
|
|
/// address respectively. These nodes have two operands, the first of
|
|
|
|
/// which must be a TargetGlobalAddress, and the second of which must be a
|
|
|
|
/// Constant. Selected naively, these turn into 'lis G+C' and 'li G+C',
|
|
|
|
/// though these are usually folded into other nodes.
|
|
|
|
Hi, Lo,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
[PowerPC] Simplify and improve loading into TOC register
During an indirect function call sequence on the 64-bit SVR4 ABI,
generate code must load and then restore the TOC register.
This does not use a regular LOAD instruction since the TOC
register r2 is marked as reserved. Instead, the are two
special instruction patterns:
let RST = 2, DS = 2 in
def LDinto_toc: DSForm_1a<58, 0, (outs), (ins g8rc:$reg),
"ld 2, 8($reg)", IIC_LdStLD,
[(PPCload_toc i64:$reg)]>, isPPC64;
let RST = 2, DS = 10, RA = 1 in
def LDtoc_restore : DSForm_1a<58, 0, (outs), (ins),
"ld 2, 40(1)", IIC_LdStLD,
[(PPCtoc_restore)]>, isPPC64;
Note that these not only restrict the destination of the
load to r2, but they also restrict the *source* of the
load to particular address combinations. The latter is
a problem when we want to support the ELFv2 ABI, since
there the TOC save slot is no longer at 40(1).
This patch replaces those two instructions with a single
instruction pattern that only hard-codes r2 as destination,
but supports generic addresses as source. This will allow
supporting the ELFv2 ABI, and also helps generate more
efficient code for calls to absolute addresses (allowing
simplification of the ppc64-calls.ll test case).
llvm-svn: 211193
2014-06-19 01:52:49 +08:00
|
|
|
/// The following two target-specific nodes are used for calls through
|
2009-12-18 21:00:15 +08:00
|
|
|
/// function pointers in the 64-bit SVR4 ABI.
|
|
|
|
|
2006-11-17 06:43:37 +08:00
|
|
|
/// OPRC, CHAIN = DYNALLOC(CHAIN, NEGSIZE, FRAME_INDEX)
|
|
|
|
/// This instruction is lowered in PPCRegisterInfo::eliminateFrameIndex to
|
|
|
|
/// compute an allocation on the stack.
|
|
|
|
DYNALLOC,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2015-12-01 19:40:55 +08:00
|
|
|
/// This instruction is lowered in PPCRegisterInfo::eliminateFrameIndex to
|
|
|
|
/// compute an offset from native SP to the address of the most recent
|
|
|
|
/// dynamic alloca.
|
|
|
|
DYNAREAOFFSET,
|
|
|
|
|
2005-11-17 15:30:41 +08:00
|
|
|
/// GlobalBaseReg - On Darwin, this node represents the result of the mflr
|
|
|
|
/// at function entry, used for PIC code.
|
|
|
|
GlobalBaseReg,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2005-12-06 10:10:38 +08:00
|
|
|
/// These nodes represent the 32-bit PPC shifts that operate on 6-bit
|
|
|
|
/// shift amounts. These nodes are generated by the multi-precision shift
|
|
|
|
/// code.
|
|
|
|
SRL, SRA, SHL,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2014-12-12 02:37:52 +08:00
|
|
|
/// The combination of sra[wd]i and addze used to implemented signed
|
|
|
|
/// integer division by a power of 2. The first operand is the dividend,
|
|
|
|
/// and the second is the constant shift amount (representing the
|
|
|
|
/// divisor).
|
|
|
|
SRA_ADDZE,
|
|
|
|
|
2006-05-18 03:00:46 +08:00
|
|
|
/// CALL - A direct function call.
|
2013-03-22 23:24:13 +08:00
|
|
|
/// CALL_NOP is a call with the special NOP which follows 64-bit
|
2012-03-31 22:45:15 +08:00
|
|
|
/// SVR4 calls.
|
2013-03-22 23:24:13 +08:00
|
|
|
CALL, CALL_NOP,
|
2009-08-15 19:54:46 +08:00
|
|
|
|
2006-05-18 03:00:46 +08:00
|
|
|
/// CHAIN,FLAG = MTCTR(VAL, CHAIN[, INFLAG]) - Directly corresponds to a
|
|
|
|
/// MTCTR instruction.
|
|
|
|
MTCTR,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-05-18 03:00:46 +08:00
|
|
|
/// CHAIN,FLAG = BCTRL(CHAIN, INFLAG) - Directly corresponds to a
|
|
|
|
/// BCTRL instruction.
|
2013-03-22 23:24:13 +08:00
|
|
|
BCTRL,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2014-12-24 06:29:40 +08:00
|
|
|
/// CHAIN,FLAG = BCTRL(CHAIN, ADDR, INFLAG) - The combination of a bctrl
|
|
|
|
/// instruction and the TOC reload required on SVR4 PPC64.
|
|
|
|
BCTRL_LOAD_TOC,
|
|
|
|
|
2005-12-20 08:26:01 +08:00
|
|
|
/// Return with a flag operand, matched by 'blr'
|
|
|
|
RET_FLAG,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
[PowerPC] Always use mfocrf if available
When accessing just a single CR register, it is always preferable to
use mfocrf instead of mfcr, if the former is available on the CPU.
Current code makes that distinction in many, but not all places
where a single CR register value is retrieved. One missing
location is PPCRegisterInfo::lowerCRSpilling.
To fix this and make this simpler in the future, this patch changes
the bulk of the back-end to always assume mfocrf is available and
simply generate it when needed.
On machines that actually do not support mfocrf, the instruction
is replaced by mfcr at the very end, in EmitInstruction.
This has the additional benefit that we no longer need the
MFCRpseud hack, since before EmitInstruction we always have
a MFOCRF instruction pattern, which already models data flow
as required.
The patch also adds the MFOCRF8 version of the instruction,
which was missing so far.
Except for the PPCRegisterInfo::lowerCRSpilling case, no change
in generated code intended.
llvm-svn: 185556
2013-07-04 01:05:42 +08:00
|
|
|
/// R32 = MFOCRF(CRREG, INFLAG) - Represents the MFOCRF instruction.
|
|
|
|
/// This copies the bits corresponding to the specified CRREG into the
|
|
|
|
/// resultant GPR. Bits corresponding to other CR regs are undefined.
|
|
|
|
MFOCRF,
|
2006-03-31 13:13:27 +08:00
|
|
|
|
2015-04-11 18:40:42 +08:00
|
|
|
/// Direct move from a VSX register to a GPR
|
|
|
|
MFVSR,
|
|
|
|
|
|
|
|
/// Direct move from a GPR to a VSX register (algebraic)
|
|
|
|
MTVSRA,
|
|
|
|
|
|
|
|
/// Direct move from a GPR to a VSX register (zero)
|
|
|
|
MTVSRZ,
|
|
|
|
|
2016-07-05 17:22:29 +08:00
|
|
|
/// Extract a subvector from signed integer vector and convert to FP.
|
|
|
|
/// It is primarily used to convert a (widened) illegal integer vector
|
|
|
|
/// type to a legal floating point vector type.
|
|
|
|
/// For example v2i32 -> widened to v4i32 -> v2f64
|
|
|
|
SINT_VEC_TO_FP,
|
|
|
|
|
|
|
|
/// Extract a subvector from unsigned integer vector and convert to FP.
|
|
|
|
/// As with SINT_VEC_TO_FP, used for converting illegal types.
|
|
|
|
UINT_VEC_TO_FP,
|
|
|
|
|
Add CR-bit tracking to the PowerPC backend for i1 values
This change enables tracking i1 values in the PowerPC backend using the
condition register bits. These bits can be treated on PowerPC as separate
registers; individual bit operations (and, or, xor, etc.) are supported.
Tracking booleans in CR bits has several advantages:
- Reduction in register pressure (because we no longer need GPRs to store
boolean values).
- Logical operations on booleans can be handled more efficiently; we used to
have to move all results from comparisons into GPRs, perform promoted
logical operations in GPRs, and then move the result back into condition
register bits to be used by conditional branches. This can be very
inefficient, because the throughput of these CR <-> GPR moves have high
latency and low throughput (especially when other associated instructions
are accounted for).
- On the POWER7 and similar cores, we can increase total throughput by using
the CR bits. CR bit operations have a dedicated functional unit.
Most of this is more-or-less mechanical: Adjustments were needed in the
calling-convention code, support was added for spilling/restoring individual
condition-register bits, and conditional branch instruction definitions taking
specific CR bits were added (plus patterns and code for generating bit-level
operations).
This is enabled by default when running at -O2 and higher. For -O0 and -O1,
where the ability to debug is more important, this feature is disabled by
default. Individual CR bits do not have assigned DWARF register numbers,
and storing values in CR bits makes them invisible to the debugger.
It is critical, however, that we don't move i1 values that have been promoted
to larger values (such as those passed as function arguments) into bit
registers only to quickly turn around and move the values back into GPRs (such
as happens when values are returned by functions). A pair of target-specific
DAG combines are added to remove the trunc/extends in:
trunc(binary-ops(binary-ops(zext(x), zext(y)), ...)
and:
zext(binary-ops(binary-ops(trunc(x), trunc(y)), ...)
In short, we only want to use CR bits where some of the i1 values come from
comparisons or are used by conditional branches or selects. To put it another
way, if we can do the entire i1 computation in GPRs, then we probably should
(on the POWER7, the GPR-operation throughput is higher, and for all cores, the
CR <-> GPR moves are expensive).
POWER7 test-suite performance results (from 10 runs in each configuration):
SingleSource/Benchmarks/Misc/mandel-2: 35% speedup
MultiSource/Benchmarks/Prolangs-C++/city/city: 21% speedup
MultiSource/Benchmarks/MiBench/automotive-susan: 23% speedup
SingleSource/Benchmarks/CoyoteBench/huffbench: 13% speedup
SingleSource/Benchmarks/Misc-C++/Large/sphereflake: 13% speedup
SingleSource/Benchmarks/Misc-C++/mandel-text: 10% speedup
SingleSource/Benchmarks/Misc-C++-EH/spirit: 10% slowdown
MultiSource/Applications/lemon/lemon: 8% slowdown
llvm-svn: 202451
2014-02-28 08:27:01 +08:00
|
|
|
// FIXME: Remove these once the ANDI glue bug is fixed:
|
|
|
|
/// i1 = ANDIo_1_[EQ|GT]_BIT(i32 or i64 x) - Represents the result of the
|
|
|
|
/// eq or gt bit of CR0 after executing andi. x, 1. This is used to
|
|
|
|
/// implement truncation of i32 or i64 to i1.
|
|
|
|
ANDIo_1_EQ_BIT, ANDIo_1_GT_BIT,
|
|
|
|
|
2014-12-03 06:01:00 +08:00
|
|
|
// READ_TIME_BASE - A read of the 64-bit time-base register on a 32-bit
|
|
|
|
// target (returns (Lo, Hi)). It takes a chain operand.
|
|
|
|
READ_TIME_BASE,
|
|
|
|
|
2013-03-22 05:37:52 +08:00
|
|
|
// EH_SJLJ_SETJMP - SjLj exception handling setjmp.
|
|
|
|
EH_SJLJ_SETJMP,
|
|
|
|
|
|
|
|
// EH_SJLJ_LONGJMP - SjLj exception handling longjmp.
|
|
|
|
EH_SJLJ_LONGJMP,
|
|
|
|
|
2006-03-31 13:13:27 +08:00
|
|
|
/// RESVEC = VCMP(LHS, RHS, OPC) - Represents one of the altivec VCMP*
|
|
|
|
/// instructions. For lack of better number, we use the opcode number
|
|
|
|
/// encoding for the OPC field to identify the compare. For example, 838
|
|
|
|
/// is VCMPGTSH.
|
|
|
|
VCMP,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-03-26 18:06:40 +08:00
|
|
|
/// RESVEC, OUTFLAG = VCMPo(LHS, RHS, OPC) - Represents one of the
|
2011-02-26 05:41:48 +08:00
|
|
|
/// altivec VCMP*o instructions. For lack of better number, we use the
|
2006-03-26 18:06:40 +08:00
|
|
|
/// opcode number encoding for the OPC field to identify the compare. For
|
|
|
|
/// example, 838 is VCMPGTSH.
|
Implement an important entry from README_ALTIVEC:
If an altivec predicate compare is used immediately by a branch, don't
use a (serializing) MFCR instruction to read the CR6 register, which requires
a compare to get it back to CR's. Instead, just branch on CR6 directly. :)
For example, for:
void foo2(vector float *A, vector float *B) {
if (!vec_any_eq(*A, *B))
*B = (vector float){0,0,0,0};
}
We now generate:
_foo2:
mfspr r2, 256
oris r5, r2, 12288
mtspr 256, r5
lvx v2, 0, r4
lvx v3, 0, r3
vcmpeqfp. v2, v3, v2
bne cr6, LBB1_2 ; UnifiedReturnBlock
LBB1_1: ; cond_true
vxor v2, v2, v2
stvx v2, 0, r4
mtspr 256, r2
blr
LBB1_2: ; UnifiedReturnBlock
mtspr 256, r2
blr
instead of:
_foo2:
mfspr r2, 256
oris r5, r2, 12288
mtspr 256, r5
lvx v2, 0, r4
lvx v3, 0, r3
vcmpeqfp. v2, v3, v2
mfcr r3, 2
rlwinm r3, r3, 27, 31, 31
cmpwi cr0, r3, 0
beq cr0, LBB1_2 ; UnifiedReturnBlock
LBB1_1: ; cond_true
vxor v2, v2, v2
stvx v2, 0, r4
mtspr 256, r2
blr
LBB1_2: ; UnifiedReturnBlock
mtspr 256, r2
blr
This implements CodeGen/PowerPC/vec_br_cmp.ll.
llvm-svn: 27804
2006-04-19 01:59:36 +08:00
|
|
|
VCMPo,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
Implement an important entry from README_ALTIVEC:
If an altivec predicate compare is used immediately by a branch, don't
use a (serializing) MFCR instruction to read the CR6 register, which requires
a compare to get it back to CR's. Instead, just branch on CR6 directly. :)
For example, for:
void foo2(vector float *A, vector float *B) {
if (!vec_any_eq(*A, *B))
*B = (vector float){0,0,0,0};
}
We now generate:
_foo2:
mfspr r2, 256
oris r5, r2, 12288
mtspr 256, r5
lvx v2, 0, r4
lvx v3, 0, r3
vcmpeqfp. v2, v3, v2
bne cr6, LBB1_2 ; UnifiedReturnBlock
LBB1_1: ; cond_true
vxor v2, v2, v2
stvx v2, 0, r4
mtspr 256, r2
blr
LBB1_2: ; UnifiedReturnBlock
mtspr 256, r2
blr
instead of:
_foo2:
mfspr r2, 256
oris r5, r2, 12288
mtspr 256, r5
lvx v2, 0, r4
lvx v3, 0, r3
vcmpeqfp. v2, v3, v2
mfcr r3, 2
rlwinm r3, r3, 27, 31, 31
cmpwi cr0, r3, 0
beq cr0, LBB1_2 ; UnifiedReturnBlock
LBB1_1: ; cond_true
vxor v2, v2, v2
stvx v2, 0, r4
mtspr 256, r2
blr
LBB1_2: ; UnifiedReturnBlock
mtspr 256, r2
blr
This implements CodeGen/PowerPC/vec_br_cmp.ll.
llvm-svn: 27804
2006-04-19 01:59:36 +08:00
|
|
|
/// CHAIN = COND_BRANCH CHAIN, CRRC, OPC, DESTBB [, INFLAG] - This
|
|
|
|
/// corresponds to the COND_BRANCH pseudo instruction. CRRC is the
|
|
|
|
/// condition register to branch on, OPC is the branch opcode to use (e.g.
|
|
|
|
/// PPC::BLE), DESTBB is the destination block to branch to, and INFLAG is
|
|
|
|
/// an optional input flag argument.
|
2006-07-11 04:56:58 +08:00
|
|
|
COND_BRANCH,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
Implement PPC counter loops as a late IR-level pass
The old PPCCTRLoops pass, like the Hexagon pass version from which it was
derived, could only handle some simple loops in canonical form. We cannot
directly adapt the new Hexagon hardware loops pass, however, because the
Hexagon pass contains a fundamental assumption that non-constant-trip-count
loops will contain a guard, and this is not always true (the result being that
incorrect negative counts can be generated). With this commit, we replace the
pass with a late IR-level pass which makes use of SE to calculate the
backedge-taken counts and safely generate the loop-count expressions (including
any necessary max() parts). This IR level pass inserts custom intrinsics that
are lowered into the desired decrement-and-branch instructions.
The most fragile part of this new implementation is that interfering uses of
the counter register must be detected on the IR level (and, on PPC, this also
includes any indirect branches in addition to function calls). Also, to make
all of this work, we need a variant of the mtctr instruction that is marked
as having side effects. Without this, machine-code level CSE, DCE, etc.
illegally transform the resulting code. Hopefully, this can be improved
in the future.
This new pass is smaller than the original (and much smaller than the new
Hexagon hardware loops pass), and can handle many additional cases correctly.
In addition, the preheader-creation code has been copied from LoopSimplify, and
after we decide on where it belongs, this code will be refactored so that it
can be explicitly shared (making this implementation even smaller).
The new test-case files ctrloop-{le,lt,ne}.ll have been adapted from tests for
the new Hexagon pass. There are a few classes of loops that this pass does not
transform (noted by FIXMEs in the files), but these deficiencies can be
addressed within the SE infrastructure (thus helping many other passes as well).
llvm-svn: 181927
2013-05-16 05:37:41 +08:00
|
|
|
/// CHAIN = BDNZ CHAIN, DESTBB - These are used to create counter-based
|
|
|
|
/// loops.
|
|
|
|
BDNZ, BDZ,
|
|
|
|
|
2013-03-26 18:56:22 +08:00
|
|
|
/// F8RC = FADDRTZ F8RC, F8RC - This is an FADD done with rounding
|
|
|
|
/// towards zero. Used only as part of the long double-to-int
|
|
|
|
/// conversion sequence.
|
2007-10-10 09:01:31 +08:00
|
|
|
FADDRTZ,
|
|
|
|
|
2013-03-26 18:56:22 +08:00
|
|
|
/// F8RC = MFFS - This moves the FPSCR (not modeled) into the register.
|
|
|
|
MFFS,
|
2008-04-19 09:30:48 +08:00
|
|
|
|
2008-04-30 17:16:33 +08:00
|
|
|
/// TC_RETURN - A tail call return.
|
|
|
|
/// operand #0 chain
|
|
|
|
/// operand #1 callee (register or absolute)
|
|
|
|
/// operand #2 stack adjustment
|
|
|
|
/// operand #3 optional in flag
|
2009-09-26 04:36:54 +08:00
|
|
|
TC_RETURN,
|
|
|
|
|
2012-08-28 10:10:27 +08:00
|
|
|
/// ch, gl = CR6[UN]SET ch, inglue - Toggle CR bit 6 for SVR4 vararg calls
|
|
|
|
CR6SET,
|
|
|
|
CR6UNSET,
|
|
|
|
|
2013-12-22 17:48:38 +08:00
|
|
|
/// GPRC = address of _GLOBAL_OFFSET_TABLE_. Used by initial-exec TLS
|
|
|
|
/// on PPC32.
|
2013-12-21 02:08:54 +08:00
|
|
|
PPC32_GOT,
|
|
|
|
|
2014-07-26 01:47:22 +08:00
|
|
|
/// GPRC = address of _GLOBAL_OFFSET_TABLE_. Used by general dynamic and
|
2015-02-26 02:06:45 +08:00
|
|
|
/// local dynamic TLS on PPC32.
|
2014-07-26 01:47:22 +08:00
|
|
|
PPC32_PICGOT,
|
|
|
|
|
This patch improves the 64-bit PowerPC InitialExec TLS support by providing
for a wider range of GOT entries that can hold thread-relative offsets.
This matches the behavior of GCC, which was not documented in the PPC64 TLS
ABI. The ABI will be updated with the new code sequence.
Former sequence:
ld 9,x@got@tprel(2)
add 9,9,x@tls
New sequence:
addis 9,2,x@got@tprel@ha
ld 9,x@got@tprel@l(9)
add 9,9,x@tls
Note that a linker optimization exists to transform the new sequence into
the shorter sequence when appropriate, by replacing the addis with a nop
and modifying the base register and relocation type of the ld.
llvm-svn: 170209
2012-12-15 01:02:38 +08:00
|
|
|
/// G8RC = ADDIS_GOT_TPREL_HA %X2, Symbol - Used by the initial-exec
|
|
|
|
/// TLS model, produces an ADDIS8 instruction that adds the GOT
|
2013-05-16 02:01:35 +08:00
|
|
|
/// base to sym\@got\@tprel\@ha.
|
This patch improves the 64-bit PowerPC InitialExec TLS support by providing
for a wider range of GOT entries that can hold thread-relative offsets.
This matches the behavior of GCC, which was not documented in the PPC64 TLS
ABI. The ABI will be updated with the new code sequence.
Former sequence:
ld 9,x@got@tprel(2)
add 9,9,x@tls
New sequence:
addis 9,2,x@got@tprel@ha
ld 9,x@got@tprel@l(9)
add 9,9,x@tls
Note that a linker optimization exists to transform the new sequence into
the shorter sequence when appropriate, by replacing the addis with a nop
and modifying the base register and relocation type of the ld.
llvm-svn: 170209
2012-12-15 01:02:38 +08:00
|
|
|
ADDIS_GOT_TPREL_HA,
|
|
|
|
|
|
|
|
/// G8RC = LD_GOT_TPREL_L Symbol, G8RReg - Used by the initial-exec
|
2012-12-05 00:18:08 +08:00
|
|
|
/// TLS model, produces a LD instruction with base register G8RReg
|
2013-05-16 02:01:35 +08:00
|
|
|
/// and offset sym\@got\@tprel\@l. This completes the addition that
|
This patch improves the 64-bit PowerPC InitialExec TLS support by providing
for a wider range of GOT entries that can hold thread-relative offsets.
This matches the behavior of GCC, which was not documented in the PPC64 TLS
ABI. The ABI will be updated with the new code sequence.
Former sequence:
ld 9,x@got@tprel(2)
add 9,9,x@tls
New sequence:
addis 9,2,x@got@tprel@ha
ld 9,x@got@tprel@l(9)
add 9,9,x@tls
Note that a linker optimization exists to transform the new sequence into
the shorter sequence when appropriate, by replacing the addis with a nop
and modifying the base register and relocation type of the ld.
llvm-svn: 170209
2012-12-15 01:02:38 +08:00
|
|
|
/// finds the offset of "sym" relative to the thread pointer.
|
|
|
|
LD_GOT_TPREL_L,
|
2012-12-05 00:18:08 +08:00
|
|
|
|
|
|
|
/// G8RC = ADD_TLS G8RReg, Symbol - Used by the initial-exec TLS
|
|
|
|
/// model, produces an ADD instruction that adds the contents of
|
|
|
|
/// G8RReg to the thread pointer. Symbol contains a relocation
|
2013-05-16 02:01:35 +08:00
|
|
|
/// sym\@tls which is to be replaced by the thread pointer and
|
2012-12-05 00:18:08 +08:00
|
|
|
/// identifies to the linker that the instruction is part of a
|
|
|
|
/// TLS sequence.
|
|
|
|
ADD_TLS,
|
|
|
|
|
This patch implements the general dynamic TLS model for 64-bit PowerPC.
Given a thread-local symbol x with global-dynamic access, the generated
code to obtain x's address is:
Instruction Relocation Symbol
addis ra,r2,x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x
addi r3,ra,x@got@tlsgd@l R_PPC64_GOT_TLSGD16_L x
bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
R_PPC64_REL24 __tls_get_addr
nop
<use address in r3>
The implementation borrows from the medium code model work for introducing
special forms of ADDIS and ADDI into the DAG representation. This is made
slightly more complicated by having to introduce a call to the external
function __tls_get_addr. Using the full call machinery is overkill and,
more importantly, makes it difficult to add a special relocation. So I've
introduced another opcode GET_TLS_ADDR to represent the function call, and
surrounded it with register copies to set up the parameter and return value.
Most of the code is pretty straightforward. I ran into one peculiarity
when I introduced a new PPC opcode BL8_NOP_ELF_TLSGD, which is just like
BL8_NOP_ELF except that it takes another parameter to represent the symbol
("x" above) that requires a relocation on the call. Something in the
TblGen machinery causes BL8_NOP_ELF and BL8_NOP_ELF_TLSGD to be treated
identically during the emit phase, so this second operand was never
visited to generate relocations. This is the reason for the slightly
messy workaround in PPCMCCodeEmitter.cpp:getDirectBrEncoding().
Two new tests are included to demonstrate correct external assembly and
correct generation of relocations using the integrated assembler.
Comments welcome!
Thanks,
Bill
llvm-svn: 169910
2012-12-12 04:30:11 +08:00
|
|
|
/// G8RC = ADDIS_TLSGD_HA %X2, Symbol - For the general-dynamic TLS
|
|
|
|
/// model, produces an ADDIS8 instruction that adds the GOT base
|
2013-05-16 02:01:35 +08:00
|
|
|
/// register to sym\@got\@tlsgd\@ha.
|
This patch implements the general dynamic TLS model for 64-bit PowerPC.
Given a thread-local symbol x with global-dynamic access, the generated
code to obtain x's address is:
Instruction Relocation Symbol
addis ra,r2,x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x
addi r3,ra,x@got@tlsgd@l R_PPC64_GOT_TLSGD16_L x
bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
R_PPC64_REL24 __tls_get_addr
nop
<use address in r3>
The implementation borrows from the medium code model work for introducing
special forms of ADDIS and ADDI into the DAG representation. This is made
slightly more complicated by having to introduce a call to the external
function __tls_get_addr. Using the full call machinery is overkill and,
more importantly, makes it difficult to add a special relocation. So I've
introduced another opcode GET_TLS_ADDR to represent the function call, and
surrounded it with register copies to set up the parameter and return value.
Most of the code is pretty straightforward. I ran into one peculiarity
when I introduced a new PPC opcode BL8_NOP_ELF_TLSGD, which is just like
BL8_NOP_ELF except that it takes another parameter to represent the symbol
("x" above) that requires a relocation on the call. Something in the
TblGen machinery causes BL8_NOP_ELF and BL8_NOP_ELF_TLSGD to be treated
identically during the emit phase, so this second operand was never
visited to generate relocations. This is the reason for the slightly
messy workaround in PPCMCCodeEmitter.cpp:getDirectBrEncoding().
Two new tests are included to demonstrate correct external assembly and
correct generation of relocations using the integrated assembler.
Comments welcome!
Thanks,
Bill
llvm-svn: 169910
2012-12-12 04:30:11 +08:00
|
|
|
ADDIS_TLSGD_HA,
|
|
|
|
|
2015-02-11 03:09:05 +08:00
|
|
|
/// %X3 = ADDI_TLSGD_L G8RReg, Symbol - For the general-dynamic TLS
|
This patch implements the general dynamic TLS model for 64-bit PowerPC.
Given a thread-local symbol x with global-dynamic access, the generated
code to obtain x's address is:
Instruction Relocation Symbol
addis ra,r2,x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x
addi r3,ra,x@got@tlsgd@l R_PPC64_GOT_TLSGD16_L x
bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
R_PPC64_REL24 __tls_get_addr
nop
<use address in r3>
The implementation borrows from the medium code model work for introducing
special forms of ADDIS and ADDI into the DAG representation. This is made
slightly more complicated by having to introduce a call to the external
function __tls_get_addr. Using the full call machinery is overkill and,
more importantly, makes it difficult to add a special relocation. So I've
introduced another opcode GET_TLS_ADDR to represent the function call, and
surrounded it with register copies to set up the parameter and return value.
Most of the code is pretty straightforward. I ran into one peculiarity
when I introduced a new PPC opcode BL8_NOP_ELF_TLSGD, which is just like
BL8_NOP_ELF except that it takes another parameter to represent the symbol
("x" above) that requires a relocation on the call. Something in the
TblGen machinery causes BL8_NOP_ELF and BL8_NOP_ELF_TLSGD to be treated
identically during the emit phase, so this second operand was never
visited to generate relocations. This is the reason for the slightly
messy workaround in PPCMCCodeEmitter.cpp:getDirectBrEncoding().
Two new tests are included to demonstrate correct external assembly and
correct generation of relocations using the integrated assembler.
Comments welcome!
Thanks,
Bill
llvm-svn: 169910
2012-12-12 04:30:11 +08:00
|
|
|
/// model, produces an ADDI8 instruction that adds G8RReg to
|
2015-02-11 03:09:05 +08:00
|
|
|
/// sym\@got\@tlsgd\@l and stores the result in X3. Hidden by
|
|
|
|
/// ADDIS_TLSGD_L_ADDR until after register assignment.
|
This patch implements the general dynamic TLS model for 64-bit PowerPC.
Given a thread-local symbol x with global-dynamic access, the generated
code to obtain x's address is:
Instruction Relocation Symbol
addis ra,r2,x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x
addi r3,ra,x@got@tlsgd@l R_PPC64_GOT_TLSGD16_L x
bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
R_PPC64_REL24 __tls_get_addr
nop
<use address in r3>
The implementation borrows from the medium code model work for introducing
special forms of ADDIS and ADDI into the DAG representation. This is made
slightly more complicated by having to introduce a call to the external
function __tls_get_addr. Using the full call machinery is overkill and,
more importantly, makes it difficult to add a special relocation. So I've
introduced another opcode GET_TLS_ADDR to represent the function call, and
surrounded it with register copies to set up the parameter and return value.
Most of the code is pretty straightforward. I ran into one peculiarity
when I introduced a new PPC opcode BL8_NOP_ELF_TLSGD, which is just like
BL8_NOP_ELF except that it takes another parameter to represent the symbol
("x" above) that requires a relocation on the call. Something in the
TblGen machinery causes BL8_NOP_ELF and BL8_NOP_ELF_TLSGD to be treated
identically during the emit phase, so this second operand was never
visited to generate relocations. This is the reason for the slightly
messy workaround in PPCMCCodeEmitter.cpp:getDirectBrEncoding().
Two new tests are included to demonstrate correct external assembly and
correct generation of relocations using the integrated assembler.
Comments welcome!
Thanks,
Bill
llvm-svn: 169910
2012-12-12 04:30:11 +08:00
|
|
|
ADDI_TLSGD_L,
|
|
|
|
|
2015-02-11 03:09:05 +08:00
|
|
|
/// %X3 = GET_TLS_ADDR %X3, Symbol - For the general-dynamic TLS
|
|
|
|
/// model, produces a call to __tls_get_addr(sym\@tlsgd). Hidden by
|
|
|
|
/// ADDIS_TLSGD_L_ADDR until after register assignment.
|
|
|
|
GET_TLS_ADDR,
|
|
|
|
|
|
|
|
/// G8RC = ADDI_TLSGD_L_ADDR G8RReg, Symbol, Symbol - Op that
|
|
|
|
/// combines ADDI_TLSGD_L and GET_TLS_ADDR until expansion following
|
|
|
|
/// register assignment.
|
|
|
|
ADDI_TLSGD_L_ADDR,
|
|
|
|
|
2012-12-13 03:29:35 +08:00
|
|
|
/// G8RC = ADDIS_TLSLD_HA %X2, Symbol - For the local-dynamic TLS
|
|
|
|
/// model, produces an ADDIS8 instruction that adds the GOT base
|
2013-05-16 02:01:35 +08:00
|
|
|
/// register to sym\@got\@tlsld\@ha.
|
2012-12-13 03:29:35 +08:00
|
|
|
ADDIS_TLSLD_HA,
|
|
|
|
|
2015-02-11 03:09:05 +08:00
|
|
|
/// %X3 = ADDI_TLSLD_L G8RReg, Symbol - For the local-dynamic TLS
|
2012-12-13 03:29:35 +08:00
|
|
|
/// model, produces an ADDI8 instruction that adds G8RReg to
|
2015-02-11 03:09:05 +08:00
|
|
|
/// sym\@got\@tlsld\@l and stores the result in X3. Hidden by
|
|
|
|
/// ADDIS_TLSLD_L_ADDR until after register assignment.
|
2012-12-13 03:29:35 +08:00
|
|
|
ADDI_TLSLD_L,
|
|
|
|
|
2015-02-11 03:09:05 +08:00
|
|
|
/// %X3 = GET_TLSLD_ADDR %X3, Symbol - For the local-dynamic TLS
|
|
|
|
/// model, produces a call to __tls_get_addr(sym\@tlsld). Hidden by
|
|
|
|
/// ADDIS_TLSLD_L_ADDR until after register assignment.
|
|
|
|
GET_TLSLD_ADDR,
|
|
|
|
|
|
|
|
/// G8RC = ADDI_TLSLD_L_ADDR G8RReg, Symbol, Symbol - Op that
|
|
|
|
/// combines ADDI_TLSLD_L and GET_TLSLD_ADDR until expansion
|
|
|
|
/// following register assignment.
|
|
|
|
ADDI_TLSLD_L_ADDR,
|
|
|
|
|
|
|
|
/// G8RC = ADDIS_DTPREL_HA %X3, Symbol - For the local-dynamic TLS
|
|
|
|
/// model, produces an ADDIS8 instruction that adds X3 to
|
|
|
|
/// sym\@dtprel\@ha.
|
2012-12-13 03:29:35 +08:00
|
|
|
ADDIS_DTPREL_HA,
|
|
|
|
|
|
|
|
/// G8RC = ADDI_DTPREL_L G8RReg, Symbol - For the local-dynamic TLS
|
|
|
|
/// model, produces an ADDI8 instruction that adds G8RReg to
|
2013-05-16 02:01:35 +08:00
|
|
|
/// sym\@got\@dtprel\@l.
|
2012-12-13 03:29:35 +08:00
|
|
|
ADDI_DTPREL_L,
|
|
|
|
|
2013-02-20 23:50:31 +08:00
|
|
|
/// VRRC = VADD_SPLAT Elt, EltSize - Temporary node to be expanded
|
2013-02-21 04:41:42 +08:00
|
|
|
/// during instruction selection to optimize a BUILD_VECTOR into
|
|
|
|
/// operations on splats. This is necessary to avoid losing these
|
|
|
|
/// optimizations due to constant folding.
|
2013-02-20 23:50:31 +08:00
|
|
|
VADD_SPLAT,
|
|
|
|
|
2013-05-15 03:35:45 +08:00
|
|
|
/// CHAIN = SC CHAIN, Imm128 - System call. The 7-bit unsigned
|
|
|
|
/// operand identifies the operating system entry point.
|
|
|
|
SC,
|
|
|
|
|
2015-05-23 00:44:10 +08:00
|
|
|
/// CHAIN = CLRBHRB CHAIN - Clear branch history rolling buffer.
|
|
|
|
CLRBHRB,
|
|
|
|
|
|
|
|
/// GPRC, CHAIN = MFBHRBE CHAIN, Entry, Dummy - Move from branch
|
|
|
|
/// history rolling buffer entry.
|
|
|
|
MFBHRBE,
|
|
|
|
|
|
|
|
/// CHAIN = RFEBB CHAIN, State - Return from event-based branch.
|
|
|
|
RFEBB,
|
|
|
|
|
[PowerPC 1/4] Little-endian adjustments for VSX loads/stores
This patch addresses the inherent big-endian bias in the lxvd2x,
lxvw4x, stxvd2x, and stxvw4x instructions. These instructions load
vector elements into registers left-to-right (with the first element
loaded into the high-order bits of the register), regardless of the
endian setting of the processor. However, these are the only
vector memory instructions that permit unaligned storage accesses, so
we want to use them for little-endian.
To make this work, a lxvd2x or lxvw4x is replaced with an lxvd2x
followed by an xxswapd, which swaps the doublewords. This works for
lxvw4x as well as lxvd2x, because for lxvw4x on an LE system the
vector elements are in LE order (right-to-left) within each
doubleword. (Thus after lxvw2x of a <4 x float> the elements will
appear as 1, 0, 3, 2. Following the swap, they will appear as 3, 2,
0, 1, as desired.) For stores, an stxvd2x or stxvw4x is replaced
with an stxvd2x preceded by an xxswapd.
Introduction of extra swap instructions provides correctness, but
obviously is not ideal from a performance perspective. Future patches
will address this with optimizations to remove most of the introduced
swaps, which have proven effective in other implementations.
The introduction of the swaps is performed during lowering of LOAD,
STORE, INTRINSIC_W_CHAIN, and INTRINSIC_VOID operations. The latter
are used to translate intrinsics that specify the VSX loads and stores
directly into equivalent sequences for little endian. Thus code that
uses vec_vsx_ld and vec_vsx_st does not have to be modified to be
ported from BE to LE.
We introduce new PPCISD opcodes for LXVD2X, STXVD2X, and XXSWAPD for
use during this lowering step. In PPCInstrVSX.td, we add new SDType
and SDNode definitions for these (PPClxvd2x, PPCstxvd2x, PPCxxswapd).
These are recognized during instruction selection and mapped to the
correct instructions.
Several tests that were written to use -mcpu=pwr7 or pwr8 are modified
to disable VSX on LE variants because code generation changes with
this and subsequent patches in this set. I chose to include all of
these in the first patch than try to rigorously sort out which tests
were broken by one or another of the patches. Sorry about that.
The new test vsx-ldst-builtin-le.ll, and the changes to vsx-ldst.ll,
are disabled until LE support is enabled because of breakages that
occur as noted in those tests. They are re-enabled in patch 4/4.
llvm-svn: 223783
2014-12-10 00:35:51 +08:00
|
|
|
/// VSRC, CHAIN = XXSWAPD CHAIN, VSRC - Occurs only for little
|
|
|
|
/// endian. Maps to an xxswapd instruction that corrects an lxvd2x
|
|
|
|
/// or stxvd2x instruction. The chain is necessary because the
|
|
|
|
/// sequence replaces a load and needs to provide the same number
|
|
|
|
/// of outputs.
|
|
|
|
XXSWAPD,
|
|
|
|
|
2016-07-12 20:16:27 +08:00
|
|
|
/// An SDNode for swaps that are not associated with any loads/stores
|
|
|
|
/// and thereby have no chain.
|
|
|
|
SWAP_NO_CHAIN,
|
|
|
|
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
/// QVFPERM = This corresponds to the QPX qvfperm instruction.
|
|
|
|
QVFPERM,
|
|
|
|
|
|
|
|
/// QVGPCI = This corresponds to the QPX qvgpci instruction.
|
|
|
|
QVGPCI,
|
|
|
|
|
|
|
|
/// QVALIGNI = This corresponds to the QPX qvaligni instruction.
|
|
|
|
QVALIGNI,
|
|
|
|
|
|
|
|
/// QVESPLATI = This corresponds to the QPX qvesplati instruction.
|
|
|
|
QVESPLATI,
|
|
|
|
|
|
|
|
/// QBFLT = Access the underlying QPX floating-point boolean
|
|
|
|
/// representation.
|
|
|
|
QBFLT,
|
|
|
|
|
2011-02-26 05:41:48 +08:00
|
|
|
/// CHAIN = STBRX CHAIN, GPRC, Ptr, Type - This is a
|
2009-09-26 04:36:54 +08:00
|
|
|
/// byte-swapping store instruction. It byte-swaps the low "Type" bits of
|
|
|
|
/// the GPRC input, then stores it through Ptr. Type can be either i16 or
|
|
|
|
/// i32.
|
2013-03-31 09:58:02 +08:00
|
|
|
STBRX = ISD::FIRST_TARGET_MEMORY_OPCODE,
|
2011-02-26 05:41:48 +08:00
|
|
|
|
|
|
|
/// GPRC, CHAIN = LBRX CHAIN, Ptr, Type - This is a
|
2009-09-26 04:36:54 +08:00
|
|
|
/// byte-swapping load instruction. It loads "Type" bits, byte swaps it,
|
|
|
|
/// then puts it in the bottom bits of the GPRC. TYPE can be either i16
|
|
|
|
/// or i32.
|
This patch implements medium code model support for 64-bit PowerPC.
The default for 64-bit PowerPC is small code model, in which TOC entries
must be addressable using a 16-bit offset from the TOC pointer. Additionally,
only TOC entries are addressed via the TOC pointer.
With medium code model, TOC entries and data sections can all be addressed
via the TOC pointer using a 32-bit offset. Cooperation with the linker
allows 16-bit offsets to be used when these are sufficient, reducing the
number of extra instructions that need to be executed. Medium code model
also does not generate explicit TOC entries in ".section toc" for variables
that are wholly internal to the compilation unit.
Consider a load of an external 4-byte integer. With small code model, the
compiler generates:
ld 3, .LC1@toc(2)
lwz 4, 0(3)
.section .toc,"aw",@progbits
.LC1:
.tc ei[TC],ei
With medium model, it instead generates:
addis 3, 2, .LC1@toc@ha
ld 3, .LC1@toc@l(3)
lwz 4, 0(3)
.section .toc,"aw",@progbits
.LC1:
.tc ei[TC],ei
Here .LC1@toc@ha is a relocation requesting the upper 16 bits of the
32-bit offset of ei's TOC entry from the TOC base pointer. Similarly,
.LC1@toc@l is a relocation requesting the lower 16 bits. Note that if
the linker determines that ei's TOC entry is within a 16-bit offset of
the TOC base pointer, it will replace the "addis" with a "nop", and
replace the "ld" with the identical "ld" instruction from the small
code model example.
Consider next a load of a function-scope static integer. For small code
model, the compiler generates:
ld 3, .LC1@toc(2)
lwz 4, 0(3)
.section .toc,"aw",@progbits
.LC1:
.tc test_fn_static.si[TC],test_fn_static.si
.type test_fn_static.si,@object
.local test_fn_static.si
.comm test_fn_static.si,4,4
For medium code model, the compiler generates:
addis 3, 2, test_fn_static.si@toc@ha
addi 3, 3, test_fn_static.si@toc@l
lwz 4, 0(3)
.type test_fn_static.si,@object
.local test_fn_static.si
.comm test_fn_static.si,4,4
Again, the linker may replace the "addis" with a "nop", calculating only
a 16-bit offset when this is sufficient.
Note that it would be more efficient for the compiler to generate:
addis 3, 2, test_fn_static.si@toc@ha
lwz 4, test_fn_static.si@toc@l(3)
The current patch does not perform this optimization yet. This will be
addressed as a peephole optimization in a later patch.
For the moment, the default code model for 64-bit PowerPC will remain the
small code model. We plan to eventually change the default to medium code
model, which matches current upstream GCC behavior. Note that the different
code models are ABI-compatible, so code compiled with different models will
be linked and execute correctly.
I've tested the regression suite and the application/benchmark test suite in
two ways: Once with the patch as submitted here, and once with additional
logic to force medium code model as the default. The tests all compile
cleanly, with one exception. The mandel-2 application test fails due to an
unrelated ABI compatibility with passing complex numbers. It just so happens
that small code model was incredibly lucky, in that temporary values in
floating-point registers held the expected values needed by the external
library routine that was called incorrectly. My current thought is to correct
the ABI problems with _Complex before making medium code model the default,
to avoid introducing this "regression."
Here are a few comments on how the patch works, since the selection code
can be difficult to follow:
The existing logic for small code model defines three pseudo-instructions:
LDtoc for most uses, LDtocJTI for jump table addresses, and LDtocCPT for
constant pool addresses. These are expanded by SelectCodeCommon(). The
pseudo-instruction approach doesn't work for medium code model, because
we need to generate two instructions when we match the same pattern.
Instead, new logic in PPCDAGToDAGISel::Select() intercepts the TOC_ENTRY
node for medium code model, and generates an ADDIStocHA followed by either
a LDtocL or an ADDItocL. These new node types correspond naturally to
the sequences described above.
The addis/ld sequence is generated for the following cases:
* Jump table addresses
* Function addresses
* External global variables
* Tentative definitions of global variables (common linkage)
The addis/addi sequence is generated for the following cases:
* Constant pool entries
* File-scope static global variables
* Function-scope static variables
Expanding to the two-instruction sequences at select time exposes the
instructions to subsequent optimization, particularly scheduling.
The rest of the processing occurs at assembly time, in
PPCAsmPrinter::EmitInstruction. Each of the instructions is converted to
a "real" PowerPC instruction. When a TOC entry needs to be created, this
is done here in the same manner as for the existing LDtoc, LDtocJTI, and
LDtocCPT pseudo-instructions (I factored out a new routine to handle this).
I had originally thought that if a TOC entry was needed for LDtocL or
ADDItocL, it would already have been generated for the previous ADDIStocHA.
However, at higher optimization levels, the ADDIStocHA may appear in a
different block, which may be assembled textually following the block
containing the LDtocL or ADDItocL. So it is necessary to include the
possibility of creating a new TOC entry for those two instructions.
Note that for LDtocL, we generate a new form of LD called LDrs. This
allows specifying the @toc@l relocation for the offset field of the LD
instruction (i.e., the offset is replaced by a SymbolLo relocation).
When the peephole optimization described above is added, we will need
to do similar things for all immediate-form load and store operations.
The seven "mcm-n.ll" test cases are kept separate because otherwise the
intermingling of various TOC entries and so forth makes the tests fragile
and hard to understand.
The above assumes use of an external assembler. For use of the
integrated assembler, new relocations are added and used by
PPCELFObjectWriter. Testing is done with "mcm-obj.ll", which tests for
proper generation of the various relocations for the same sequences
tested with the external assembler.
llvm-svn: 168708
2012-11-28 01:35:46 +08:00
|
|
|
LBRX,
|
|
|
|
|
2013-04-01 23:37:53 +08:00
|
|
|
/// STFIWX - The STFIWX instruction. The first operand is an input token
|
|
|
|
/// chain, then an f64 value to store, then an address to store it to.
|
|
|
|
STFIWX,
|
|
|
|
|
2013-03-31 18:12:51 +08:00
|
|
|
/// GPRC, CHAIN = LFIWAX CHAIN, Ptr - This is a floating-point
|
|
|
|
/// load which sign-extends from a 32-bit integer value into the
|
|
|
|
/// destination 64-bit register.
|
|
|
|
LFIWAX,
|
|
|
|
|
2013-04-02 01:52:07 +08:00
|
|
|
/// GPRC, CHAIN = LFIWZX CHAIN, Ptr - This is a floating-point
|
|
|
|
/// load which zero-extends from a 32-bit integer value into the
|
|
|
|
/// destination 64-bit register.
|
|
|
|
LFIWZX,
|
|
|
|
|
[PowerPC 1/4] Little-endian adjustments for VSX loads/stores
This patch addresses the inherent big-endian bias in the lxvd2x,
lxvw4x, stxvd2x, and stxvw4x instructions. These instructions load
vector elements into registers left-to-right (with the first element
loaded into the high-order bits of the register), regardless of the
endian setting of the processor. However, these are the only
vector memory instructions that permit unaligned storage accesses, so
we want to use them for little-endian.
To make this work, a lxvd2x or lxvw4x is replaced with an lxvd2x
followed by an xxswapd, which swaps the doublewords. This works for
lxvw4x as well as lxvd2x, because for lxvw4x on an LE system the
vector elements are in LE order (right-to-left) within each
doubleword. (Thus after lxvw2x of a <4 x float> the elements will
appear as 1, 0, 3, 2. Following the swap, they will appear as 3, 2,
0, 1, as desired.) For stores, an stxvd2x or stxvw4x is replaced
with an stxvd2x preceded by an xxswapd.
Introduction of extra swap instructions provides correctness, but
obviously is not ideal from a performance perspective. Future patches
will address this with optimizations to remove most of the introduced
swaps, which have proven effective in other implementations.
The introduction of the swaps is performed during lowering of LOAD,
STORE, INTRINSIC_W_CHAIN, and INTRINSIC_VOID operations. The latter
are used to translate intrinsics that specify the VSX loads and stores
directly into equivalent sequences for little endian. Thus code that
uses vec_vsx_ld and vec_vsx_st does not have to be modified to be
ported from BE to LE.
We introduce new PPCISD opcodes for LXVD2X, STXVD2X, and XXSWAPD for
use during this lowering step. In PPCInstrVSX.td, we add new SDType
and SDNode definitions for these (PPClxvd2x, PPCstxvd2x, PPCxxswapd).
These are recognized during instruction selection and mapped to the
correct instructions.
Several tests that were written to use -mcpu=pwr7 or pwr8 are modified
to disable VSX on LE variants because code generation changes with
this and subsequent patches in this set. I chose to include all of
these in the first patch than try to rigorously sort out which tests
were broken by one or another of the patches. Sorry about that.
The new test vsx-ldst-builtin-le.ll, and the changes to vsx-ldst.ll,
are disabled until LE support is enabled because of breakages that
occur as noted in those tests. They are re-enabled in patch 4/4.
llvm-svn: 223783
2014-12-10 00:35:51 +08:00
|
|
|
/// VSRC, CHAIN = LXVD2X_LE CHAIN, Ptr - Occurs only for little endian.
|
|
|
|
/// Maps directly to an lxvd2x instruction that will be followed by
|
|
|
|
/// an xxswapd.
|
|
|
|
LXVD2X,
|
|
|
|
|
|
|
|
/// CHAIN = STXVD2X CHAIN, VSRC, Ptr - Occurs only for little endian.
|
|
|
|
/// Maps directly to an stxvd2x instruction that will be preceded by
|
|
|
|
/// an xxswapd.
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
STXVD2X,
|
|
|
|
|
|
|
|
/// QBRC, CHAIN = QVLFSb CHAIN, Ptr
|
|
|
|
/// The 4xf32 load used for v4i1 constants.
|
[PowerPC] Make LDtocL and friends invariant loads
LDtocL, and other loads that roughly correspond to the TOC_ENTRY SDAG node,
represent loads from the TOC, which is invariant. As a result, these loads can
be hoisted out of loops, etc. In order to do this, we need to generate
GOT-style MMOs for TOC_ENTRY, which requires treating it as a legitimate memory
intrinsic node type. Once this is done, the MMO transfer is automatically
handled for TableGen-driven instruction selection, and for nodes generated
directly in PPCISelDAGToDAG, we need to transfer the MMOs manually.
Also, we were not transferring MMOs associated with pre-increment loads, so do
that too.
Lastly, this fixes an exposed bug where R30 was not added as a defined operand of
UpdateGBR.
This problem was highlighted by an example (used to generate the test case)
posted to llvmdev by Francois Pichet.
llvm-svn: 230553
2015-02-26 05:36:59 +08:00
|
|
|
QVLFSb,
|
|
|
|
|
|
|
|
/// GPRC = TOC_ENTRY GA, TOC
|
|
|
|
/// Loads the entry for GA from the TOC, where the TOC base is given by
|
|
|
|
/// the last operand.
|
|
|
|
TOC_ENTRY
|
2006-01-28 07:34:02 +08:00
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2006-03-20 14:15:45 +08:00
|
|
|
|
|
|
|
/// Define some predicates that are used for node matching.
|
|
|
|
namespace PPC {
|
2006-04-07 01:23:16 +08:00
|
|
|
/// isVPKUHUMShuffleMask - Return true if this is the shuffle mask for a
|
|
|
|
/// VPKUHUM instruction.
|
2014-08-04 21:53:40 +08:00
|
|
|
bool isVPKUHUMShuffleMask(ShuffleVectorSDNode *N, unsigned ShuffleKind,
|
2014-06-10 22:35:01 +08:00
|
|
|
SelectionDAG &DAG);
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-04-07 01:23:16 +08:00
|
|
|
/// isVPKUWUMShuffleMask - Return true if this is the shuffle mask for a
|
|
|
|
/// VPKUWUM instruction.
|
2014-08-04 21:53:40 +08:00
|
|
|
bool isVPKUWUMShuffleMask(ShuffleVectorSDNode *N, unsigned ShuffleKind,
|
2014-06-10 22:35:01 +08:00
|
|
|
SelectionDAG &DAG);
|
2006-04-07 05:11:54 +08:00
|
|
|
|
2015-05-16 09:02:12 +08:00
|
|
|
/// isVPKUDUMShuffleMask - Return true if this is the shuffle mask for a
|
|
|
|
/// VPKUDUM instruction.
|
|
|
|
bool isVPKUDUMShuffleMask(ShuffleVectorSDNode *N, unsigned ShuffleKind,
|
|
|
|
SelectionDAG &DAG);
|
|
|
|
|
2006-04-07 05:11:54 +08:00
|
|
|
/// isVMRGLShuffleMask - Return true if this is a shuffle mask suitable for
|
|
|
|
/// a VRGL* instruction with the specified unit size (1,2 or 4 bytes).
|
2009-04-28 02:41:29 +08:00
|
|
|
bool isVMRGLShuffleMask(ShuffleVectorSDNode *N, unsigned UnitSize,
|
2014-07-25 09:55:55 +08:00
|
|
|
unsigned ShuffleKind, SelectionDAG &DAG);
|
2006-04-07 05:11:54 +08:00
|
|
|
|
|
|
|
/// isVMRGHShuffleMask - Return true if this is a shuffle mask suitable for
|
|
|
|
/// a VRGH* instruction with the specified unit size (1,2 or 4 bytes).
|
2009-04-28 02:41:29 +08:00
|
|
|
bool isVMRGHShuffleMask(ShuffleVectorSDNode *N, unsigned UnitSize,
|
2014-07-25 09:55:55 +08:00
|
|
|
unsigned ShuffleKind, SelectionDAG &DAG);
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2015-06-25 23:17:40 +08:00
|
|
|
/// isVMRGEOShuffleMask - Return true if this is a shuffle mask suitable for
|
|
|
|
/// a VMRGEW or VMRGOW instruction
|
|
|
|
bool isVMRGEOShuffleMask(ShuffleVectorSDNode *N, bool CheckEven,
|
|
|
|
unsigned ShuffleKind, SelectionDAG &DAG);
|
|
|
|
|
2014-08-06 04:47:25 +08:00
|
|
|
/// isVSLDOIShuffleMask - If this is a vsldoi shuffle mask, return the
|
|
|
|
/// shift amount, otherwise return -1.
|
|
|
|
int isVSLDOIShuffleMask(SDNode *N, unsigned ShuffleKind,
|
|
|
|
SelectionDAG &DAG);
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-03-20 14:15:45 +08:00
|
|
|
/// isSplatShuffleMask - Return true if the specified VECTOR_SHUFFLE operand
|
|
|
|
/// specifies a splat of a single element that is suitable for input to
|
|
|
|
/// VSPLTB/VSPLTH/VSPLTW.
|
2009-04-28 02:41:29 +08:00
|
|
|
bool isSplatShuffleMask(ShuffleVectorSDNode *N, unsigned EltSize);
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2016-07-13 05:00:10 +08:00
|
|
|
/// isXXINSERTWMask - Return true if this VECTOR_SHUFFLE can be handled by
|
|
|
|
/// the XXINSERTW instruction introduced in ISA 3.0. This is essentially any
|
|
|
|
/// shuffle of v4f32/v4i32 vectors that just inserts one element from one
|
|
|
|
/// vector into the other. This function will also set a couple of
|
|
|
|
/// output parameters for how much the source vector needs to be shifted and
|
|
|
|
/// what byte number needs to be specified for the instruction to put the
|
|
|
|
/// element in the desired location of the target vector.
|
|
|
|
bool isXXINSERTWMask(ShuffleVectorSDNode *N, unsigned &ShiftElts,
|
|
|
|
unsigned &InsertAtByte, bool &Swap, bool IsLE);
|
|
|
|
|
2006-03-20 14:15:45 +08:00
|
|
|
/// getVSPLTImmediate - Return the appropriate VSPLT* immediate to splat the
|
|
|
|
/// specified isSplatShuffleMask VECTOR_SHUFFLE mask.
|
2014-06-10 22:35:01 +08:00
|
|
|
unsigned getVSPLTImmediate(SDNode *N, unsigned EltSize, SelectionDAG &DAG);
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-04-13 01:37:20 +08:00
|
|
|
/// get_VSPLTI_elt - If this is a build_vector of constants which can be
|
2006-04-08 14:46:53 +08:00
|
|
|
/// formed by using a vspltis[bhw] instruction of the specified element
|
|
|
|
/// size, return the constant being splatted. The ByteSize field indicates
|
|
|
|
/// the number of bytes of each element [124] -> [bhw].
|
2008-07-28 05:46:04 +08:00
|
|
|
SDValue get_VSPLTI_elt(SDNode *N, unsigned ByteSize, SelectionDAG &DAG);
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
|
|
|
|
/// If this is a qvaligni shuffle mask, return the shift
|
|
|
|
/// amount, otherwise return -1.
|
|
|
|
int isQVALIGNIShuffleMask(SDNode *N);
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2005-10-16 13:39:50 +08:00
|
|
|
class PPCTargetLowering : public TargetLowering {
|
2014-06-13 06:38:18 +08:00
|
|
|
const PPCSubtarget &Subtarget;
|
2010-04-17 22:41:14 +08:00
|
|
|
|
2005-08-17 01:14:42 +08:00
|
|
|
public:
|
2015-01-31 06:02:31 +08:00
|
|
|
explicit PPCTargetLowering(const PPCTargetMachine &TM,
|
|
|
|
const PPCSubtarget &STI);
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-01-10 07:52:17 +08:00
|
|
|
/// getTargetNodeName() - This method returns the name of a target specific
|
|
|
|
/// DAG node.
|
2014-04-29 15:57:37 +08:00
|
|
|
const char *getTargetNodeName(unsigned Opcode) const override;
|
2006-11-08 10:15:41 +08:00
|
|
|
|
2016-07-05 17:22:29 +08:00
|
|
|
/// getPreferredVectorAction - The code we generate when vector types are
|
|
|
|
/// legalized by promoting the integer element type is often much worse
|
|
|
|
/// than code we generate if we widen the type for applicable vector types.
|
|
|
|
/// The issue with promoting is that the vector is scalaraized, individual
|
|
|
|
/// elements promoted and then the vector is rebuilt. So say we load a pair
|
|
|
|
/// of v4i8's and shuffle them. This will turn into a mess of 8 extending
|
|
|
|
/// loads, moves back into VSR's (or memory ops if we don't have moves) and
|
|
|
|
/// then the VPERM for the shuffle. All in all a very slow sequence.
|
|
|
|
TargetLoweringBase::LegalizeTypeAction getPreferredVectorAction(EVT VT)
|
|
|
|
const override {
|
2016-09-15 00:37:15 +08:00
|
|
|
if (VT.getScalarSizeInBits() % 8 == 0)
|
2016-07-05 17:22:29 +08:00
|
|
|
return TypeWidenVector;
|
|
|
|
return TargetLoweringBase::getPreferredVectorAction(VT);
|
|
|
|
}
|
2015-12-15 01:57:33 +08:00
|
|
|
bool useSoftFloat() const override;
|
|
|
|
|
2015-07-09 23:12:23 +08:00
|
|
|
MVT getScalarShiftAmountTy(const DataLayout &, EVT) const override {
|
2015-07-09 10:09:20 +08:00
|
|
|
return MVT::i32;
|
|
|
|
}
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2015-01-05 13:24:42 +08:00
|
|
|
bool isCheapToSpeculateCttz() const override {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isCheapToSpeculateCtlz() const override {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-08-16 21:53:53 +08:00
|
|
|
bool isCtlzFast() const override {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-09-02 10:58:25 +08:00
|
|
|
bool hasAndNotCompare(SDValue) const override {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-04-08 20:04:32 +08:00
|
|
|
bool supportSplitCSR(MachineFunction *MF) const override {
|
|
|
|
return
|
|
|
|
MF->getFunction()->getCallingConv() == CallingConv::CXX_FAST_TLS &&
|
|
|
|
MF->getFunction()->hasFnAttribute(Attribute::NoUnwind);
|
|
|
|
}
|
|
|
|
|
|
|
|
void initializeSplitCSR(MachineBasicBlock *Entry) const override;
|
|
|
|
|
|
|
|
void insertCopiesSplitCSR(
|
|
|
|
MachineBasicBlock *Entry,
|
|
|
|
const SmallVectorImpl<MachineBasicBlock *> &Exits) const override;
|
|
|
|
|
2008-03-10 23:42:14 +08:00
|
|
|
/// getSetCCResultType - Return the ISD::SETCC ValueType
|
2015-07-09 10:09:04 +08:00
|
|
|
EVT getSetCCResultType(const DataLayout &DL, LLVMContext &Context,
|
|
|
|
EVT VT) const override;
|
2008-03-10 23:42:14 +08:00
|
|
|
|
Optionally enable more-aggressive FMA formation in DAGCombine
The heuristic used by DAGCombine to form FMAs checks that the FMUL has only one
use, but this is overly-conservative on some systems. Specifically, if the FMA
and the FADD have the same latency (and the FMA does not compete for resources
with the FMUL any more than the FADD does), there is no need for the
restriction, and furthermore, forming the FMA leaving the FMUL can still allow
for higher overall throughput and decreased critical-path length.
Here we add a new TLI callback, enableAggressiveFMAFusion, false by default, to
elide the hasOneUse check. This is enabled for PowerPC by default, as most
PowerPC systems will benefit.
Patch by Olivier Sallenave, thanks!
llvm-svn: 218120
2014-09-19 19:42:56 +08:00
|
|
|
/// Return true if target always beneficiates from combining into FMA for a
|
|
|
|
/// given value type. This must typically return false on targets where FMA
|
|
|
|
/// takes more cycles to execute than FADD.
|
|
|
|
bool enableAggressiveFMAFusion(EVT VT) const override;
|
|
|
|
|
2006-11-08 10:15:41 +08:00
|
|
|
/// getPreIndexedAddressParts - returns true by value, base pointer and
|
|
|
|
/// offset pointer and addressing mode by reference if the node's address
|
|
|
|
/// can be legally represented as pre-indexed load / store address.
|
2014-04-29 15:57:37 +08:00
|
|
|
bool getPreIndexedAddressParts(SDNode *N, SDValue &Base,
|
|
|
|
SDValue &Offset,
|
|
|
|
ISD::MemIndexedMode &AM,
|
|
|
|
SelectionDAG &DAG) const override;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-11-08 10:15:41 +08:00
|
|
|
/// SelectAddressRegReg - Given the specified addressed, check to see if it
|
|
|
|
/// can be represented as an indexed [r+r] operation. Returns false if it
|
|
|
|
/// can be more efficiently represented with [r+imm].
|
2008-07-28 05:46:04 +08:00
|
|
|
bool SelectAddressRegReg(SDValue N, SDValue &Base, SDValue &Index,
|
2009-01-16 00:29:45 +08:00
|
|
|
SelectionDAG &DAG) const;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-11-08 10:15:41 +08:00
|
|
|
/// SelectAddressRegImm - Returns true if the address N can be represented
|
|
|
|
/// by a base register plus a signed 16-bit displacement [r+imm], and if it
|
2013-05-17 01:58:02 +08:00
|
|
|
/// is not better represented as reg+reg. If Aligned is true, only accept
|
|
|
|
/// displacements suitable for STD and friends, i.e. multiples of 4.
|
2008-07-28 05:46:04 +08:00
|
|
|
bool SelectAddressRegImm(SDValue N, SDValue &Disp, SDValue &Base,
|
2013-05-17 01:58:02 +08:00
|
|
|
SelectionDAG &DAG, bool Aligned) const;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2006-11-08 10:15:41 +08:00
|
|
|
/// SelectAddressRegRegOnly - Given the specified addressed, force it to be
|
|
|
|
/// represented as an indexed [r+r] operation.
|
2008-07-28 05:46:04 +08:00
|
|
|
bool SelectAddressRegRegOnly(SDValue N, SDValue &Base, SDValue &Index,
|
2009-01-16 00:29:45 +08:00
|
|
|
SelectionDAG &DAG) const;
|
2006-11-08 10:15:41 +08:00
|
|
|
|
2014-04-29 15:57:37 +08:00
|
|
|
Sched::Preference getSchedulingPreference(SDNode *N) const override;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2005-08-26 08:52:45 +08:00
|
|
|
/// LowerOperation - Provide custom lowering hooks for some operations.
|
|
|
|
///
|
2014-04-29 15:57:37 +08:00
|
|
|
SDValue LowerOperation(SDValue Op, SelectionDAG &DAG) const override;
|
2007-11-29 02:44:47 +08:00
|
|
|
|
2008-12-01 19:39:25 +08:00
|
|
|
/// ReplaceNodeResults - Replace the results of node with an illegal result
|
|
|
|
/// type with new values built out of custom code.
|
|
|
|
///
|
2014-04-29 15:57:37 +08:00
|
|
|
void ReplaceNodeResults(SDNode *N, SmallVectorImpl<SDValue>&Results,
|
|
|
|
SelectionDAG &DAG) const override;
|
2008-12-01 19:39:25 +08:00
|
|
|
|
[PowerPC 1/4] Little-endian adjustments for VSX loads/stores
This patch addresses the inherent big-endian bias in the lxvd2x,
lxvw4x, stxvd2x, and stxvw4x instructions. These instructions load
vector elements into registers left-to-right (with the first element
loaded into the high-order bits of the register), regardless of the
endian setting of the processor. However, these are the only
vector memory instructions that permit unaligned storage accesses, so
we want to use them for little-endian.
To make this work, a lxvd2x or lxvw4x is replaced with an lxvd2x
followed by an xxswapd, which swaps the doublewords. This works for
lxvw4x as well as lxvd2x, because for lxvw4x on an LE system the
vector elements are in LE order (right-to-left) within each
doubleword. (Thus after lxvw2x of a <4 x float> the elements will
appear as 1, 0, 3, 2. Following the swap, they will appear as 3, 2,
0, 1, as desired.) For stores, an stxvd2x or stxvw4x is replaced
with an stxvd2x preceded by an xxswapd.
Introduction of extra swap instructions provides correctness, but
obviously is not ideal from a performance perspective. Future patches
will address this with optimizations to remove most of the introduced
swaps, which have proven effective in other implementations.
The introduction of the swaps is performed during lowering of LOAD,
STORE, INTRINSIC_W_CHAIN, and INTRINSIC_VOID operations. The latter
are used to translate intrinsics that specify the VSX loads and stores
directly into equivalent sequences for little endian. Thus code that
uses vec_vsx_ld and vec_vsx_st does not have to be modified to be
ported from BE to LE.
We introduce new PPCISD opcodes for LXVD2X, STXVD2X, and XXSWAPD for
use during this lowering step. In PPCInstrVSX.td, we add new SDType
and SDNode definitions for these (PPClxvd2x, PPCstxvd2x, PPCxxswapd).
These are recognized during instruction selection and mapped to the
correct instructions.
Several tests that were written to use -mcpu=pwr7 or pwr8 are modified
to disable VSX on LE variants because code generation changes with
this and subsequent patches in this set. I chose to include all of
these in the first patch than try to rigorously sort out which tests
were broken by one or another of the patches. Sorry about that.
The new test vsx-ldst-builtin-le.ll, and the changes to vsx-ldst.ll,
are disabled until LE support is enabled because of breakages that
occur as noted in those tests. They are re-enabled in patch 4/4.
llvm-svn: 223783
2014-12-10 00:35:51 +08:00
|
|
|
SDValue expandVSXLoadForLE(SDNode *N, DAGCombinerInfo &DCI) const;
|
|
|
|
SDValue expandVSXStoreForLE(SDNode *N, DAGCombinerInfo &DCI) const;
|
|
|
|
|
2014-04-29 15:57:37 +08:00
|
|
|
SDValue PerformDAGCombine(SDNode *N, DAGCombinerInfo &DCI) const override;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2014-12-12 02:37:52 +08:00
|
|
|
SDValue BuildSDIVPow2(SDNode *N, const APInt &Divisor, SelectionDAG &DAG,
|
|
|
|
std::vector<SDNode *> *Created) const override;
|
|
|
|
|
2015-07-10 01:40:29 +08:00
|
|
|
unsigned getRegisterByName(const char* RegName, EVT VT,
|
|
|
|
SelectionDAG &DAG) const override;
|
2014-05-12 03:29:11 +08:00
|
|
|
|
2014-05-15 05:14:37 +08:00
|
|
|
void computeKnownBitsForTargetNode(const SDValue Op,
|
|
|
|
APInt &KnownZero,
|
|
|
|
APInt &KnownOne,
|
|
|
|
const SelectionDAG &DAG,
|
|
|
|
unsigned Depth = 0) const override;
|
2005-10-19 07:23:37 +08:00
|
|
|
|
2015-01-04 01:58:24 +08:00
|
|
|
unsigned getPrefLoopAlignment(MachineLoop *ML) const override;
|
|
|
|
|
2016-03-17 06:12:04 +08:00
|
|
|
bool shouldInsertFencesForAtomic(const Instruction *I) const override {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-09-24 04:46:49 +08:00
|
|
|
Instruction* emitLeadingFence(IRBuilder<> &Builder, AtomicOrdering Ord,
|
|
|
|
bool IsStore, bool IsLoad) const override;
|
|
|
|
Instruction* emitTrailingFence(IRBuilder<> &Builder, AtomicOrdering Ord,
|
|
|
|
bool IsStore, bool IsLoad) const override;
|
|
|
|
|
2014-04-29 15:57:37 +08:00
|
|
|
MachineBasicBlock *
|
2016-07-01 06:52:52 +08:00
|
|
|
EmitInstrWithCustomInserter(MachineInstr &MI,
|
|
|
|
MachineBasicBlock *MBB) const override;
|
|
|
|
MachineBasicBlock *EmitAtomicBinary(MachineInstr &MI,
|
2015-03-11 04:51:07 +08:00
|
|
|
MachineBasicBlock *MBB,
|
|
|
|
unsigned AtomicSize,
|
2016-08-29 00:17:58 +08:00
|
|
|
unsigned BinOpcode,
|
|
|
|
unsigned CmpOpcode = 0,
|
|
|
|
unsigned CmpPred = 0) const;
|
2016-07-01 06:52:52 +08:00
|
|
|
MachineBasicBlock *EmitPartwordAtomicBinary(MachineInstr &MI,
|
2011-02-26 05:41:48 +08:00
|
|
|
MachineBasicBlock *MBB,
|
2016-07-01 06:52:52 +08:00
|
|
|
bool is8bit,
|
2016-08-29 00:17:58 +08:00
|
|
|
unsigned Opcode,
|
|
|
|
unsigned CmpOpcode = 0,
|
|
|
|
unsigned CmpPred = 0) const;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2016-07-01 06:52:52 +08:00
|
|
|
MachineBasicBlock *emitEHSjLjSetJmp(MachineInstr &MI,
|
2013-03-22 05:37:52 +08:00
|
|
|
MachineBasicBlock *MBB) const;
|
|
|
|
|
2016-07-01 06:52:52 +08:00
|
|
|
MachineBasicBlock *emitEHSjLjLongJmp(MachineInstr &MI,
|
2013-03-22 05:37:52 +08:00
|
|
|
MachineBasicBlock *MBB) const;
|
|
|
|
|
2015-07-06 03:29:18 +08:00
|
|
|
ConstraintType getConstraintType(StringRef Constraint) const override;
|
2010-10-30 01:29:13 +08:00
|
|
|
|
|
|
|
/// Examine constraint string and operand type and determine a weight value.
|
|
|
|
/// The operand object must already have been set up with the operand type.
|
|
|
|
ConstraintWeight getSingleConstraintMatchWeight(
|
2014-04-29 15:57:37 +08:00
|
|
|
AsmOperandInfo &info, const char *constraint) const override;
|
2010-10-30 01:29:13 +08:00
|
|
|
|
2015-02-27 06:38:43 +08:00
|
|
|
std::pair<unsigned, const TargetRegisterClass *>
|
|
|
|
getRegForInlineAsmConstraint(const TargetRegisterInfo *TRI,
|
2015-07-06 03:29:18 +08:00
|
|
|
StringRef Constraint, MVT VT) const override;
|
2006-03-14 07:20:37 +08:00
|
|
|
|
2008-02-29 06:31:51 +08:00
|
|
|
/// getByValTypeAlignment - Return the desired alignment for ByVal aggregate
|
|
|
|
/// function arguments in the caller parameter area. This is the actual
|
|
|
|
/// alignment, not its logarithm.
|
2015-07-09 10:09:28 +08:00
|
|
|
unsigned getByValTypeAlignment(Type *Ty,
|
|
|
|
const DataLayout &DL) const override;
|
2008-02-29 06:31:51 +08:00
|
|
|
|
2007-08-25 08:47:38 +08:00
|
|
|
/// LowerAsmOperandForConstraint - Lower the specified operand into the Ops
|
2010-06-26 05:55:36 +08:00
|
|
|
/// vector. If it is invalid, don't add anything to Ops.
|
2014-04-29 15:57:37 +08:00
|
|
|
void LowerAsmOperandForConstraint(SDValue Op,
|
|
|
|
std::string &Constraint,
|
|
|
|
std::vector<SDValue> &Ops,
|
|
|
|
SelectionDAG &DAG) const override;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2015-07-06 03:29:18 +08:00
|
|
|
unsigned
|
|
|
|
getInlineAsmMemConstraint(StringRef ConstraintCode) const override {
|
2015-03-17 19:09:13 +08:00
|
|
|
if (ConstraintCode == "es")
|
|
|
|
return InlineAsm::Constraint_es;
|
|
|
|
else if (ConstraintCode == "o")
|
|
|
|
return InlineAsm::Constraint_o;
|
|
|
|
else if (ConstraintCode == "Q")
|
|
|
|
return InlineAsm::Constraint_Q;
|
|
|
|
else if (ConstraintCode == "Z")
|
|
|
|
return InlineAsm::Constraint_Z;
|
|
|
|
else if (ConstraintCode == "Zy")
|
|
|
|
return InlineAsm::Constraint_Zy;
|
|
|
|
return TargetLowering::getInlineAsmMemConstraint(ConstraintCode);
|
2015-03-16 21:13:41 +08:00
|
|
|
}
|
|
|
|
|
2007-03-31 07:15:24 +08:00
|
|
|
/// isLegalAddressingMode - Return true if the addressing mode represented
|
|
|
|
/// by AM is legal for this target, for a load/store of the specified type.
|
2015-07-09 10:09:40 +08:00
|
|
|
bool isLegalAddressingMode(const DataLayout &DL, const AddrMode &AM,
|
|
|
|
Type *Ty, unsigned AS) const override;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2014-04-13 05:52:38 +08:00
|
|
|
/// isLegalICmpImmediate - Return true if the specified immediate is legal
|
|
|
|
/// icmp immediate, that is the target has icmp instructions which can
|
|
|
|
/// compare a register against the immediate without having to materialize
|
|
|
|
/// the immediate into a register.
|
|
|
|
bool isLegalICmpImmediate(int64_t Imm) const override;
|
|
|
|
|
|
|
|
/// isLegalAddImmediate - Return true if the specified immediate is legal
|
|
|
|
/// add immediate, that is the target has add instructions which can
|
|
|
|
/// add a register and the immediate without having to materialize
|
|
|
|
/// the immediate into a register.
|
|
|
|
bool isLegalAddImmediate(int64_t Imm) const override;
|
|
|
|
|
|
|
|
/// isTruncateFree - Return true if it's free to truncate a value of
|
|
|
|
/// type Ty1 to type Ty2. e.g. On PPC it's free to truncate a i64 value in
|
|
|
|
/// register X1 to i32 by referencing its sub-register R1.
|
|
|
|
bool isTruncateFree(Type *Ty1, Type *Ty2) const override;
|
|
|
|
bool isTruncateFree(EVT VT1, EVT VT2) const override;
|
|
|
|
|
2015-01-10 16:21:59 +08:00
|
|
|
bool isZExtFree(SDValue Val, EVT VT2) const override;
|
|
|
|
|
2015-01-13 23:06:36 +08:00
|
|
|
bool isFPExtFree(EVT VT) const override;
|
|
|
|
|
2014-04-13 05:52:38 +08:00
|
|
|
/// \brief Returns true if it is beneficial to convert a load of a constant
|
|
|
|
/// to just the constant itself.
|
|
|
|
bool shouldConvertConstantLoadToIntImm(const APInt &Imm,
|
|
|
|
Type *Ty) const override;
|
|
|
|
|
2014-04-29 15:57:37 +08:00
|
|
|
bool isOffsetFoldingLegal(const GlobalAddressSDNode *GA) const override;
|
2011-02-26 05:41:48 +08:00
|
|
|
|
2014-08-13 09:15:40 +08:00
|
|
|
bool getTgtMemIntrinsic(IntrinsicInfo &Info,
|
|
|
|
const CallInst &I,
|
|
|
|
unsigned Intrinsic) const override;
|
|
|
|
|
2010-04-02 04:10:42 +08:00
|
|
|
/// getOptimalMemOpType - Returns the target specific optimal type for load
|
2010-04-03 03:36:14 +08:00
|
|
|
/// and store operations as a result of memset, memcpy, and memmove
|
|
|
|
/// lowering. If DstAlign is zero that means it's safe to destination
|
|
|
|
/// alignment can satisfy any constraint. Similarly if SrcAlign is zero it
|
|
|
|
/// means there isn't a need to check it against alignment requirement,
|
2012-12-12 10:34:41 +08:00
|
|
|
/// probably because the source does not need to be loaded. If 'IsMemset' is
|
|
|
|
/// true, that means it's expanding a memset. If 'ZeroMemset' is true, that
|
|
|
|
/// means it's a memset of zero. 'MemcpyStrSrc' indicates whether the memcpy
|
|
|
|
/// source is constant so it does not need to be loaded.
|
2010-04-17 04:11:05 +08:00
|
|
|
/// It returns EVT::Other if the type should be determined using generic
|
|
|
|
/// target-independent logic.
|
2014-04-29 15:57:37 +08:00
|
|
|
EVT
|
2013-05-16 02:01:28 +08:00
|
|
|
getOptimalMemOpType(uint64_t Size, unsigned DstAlign, unsigned SrcAlign,
|
2012-12-12 10:34:41 +08:00
|
|
|
bool IsMemset, bool ZeroMemset, bool MemcpyStrSrc,
|
2014-04-29 15:57:37 +08:00
|
|
|
MachineFunction &MF) const override;
|
2008-10-21 11:41:46 +08:00
|
|
|
|
2013-03-15 23:27:13 +08:00
|
|
|
/// Is unaligned memory access allowed for the given type, and is it fast
|
|
|
|
/// relative to software emulation.
|
2014-07-28 01:46:40 +08:00
|
|
|
bool allowsMisalignedMemoryAccesses(EVT VT,
|
|
|
|
unsigned AddrSpace,
|
|
|
|
unsigned Align = 1,
|
|
|
|
bool *Fast = nullptr) const override;
|
2013-03-15 23:27:13 +08:00
|
|
|
|
AArch64/PowerPC/SystemZ/X86: This patch fixes the interface, usage, and all
in-tree implementations of TargetLoweringBase::isFMAFasterThanMulAndAdd in
order to resolve the following issues with fmuladd (i.e. optional FMA)
intrinsics:
1. On X86(-64) targets, ISD::FMA nodes are formed when lowering fmuladd
intrinsics even if the subtarget does not support FMA instructions, leading
to laughably bad code generation in some situations.
2. On AArch64 targets, ISD::FMA nodes are formed for operations on fp128,
resulting in a call to a software fp128 FMA implementation.
3. On PowerPC targets, FMAs are not generated from fmuladd intrinsics on types
like v2f32, v8f32, v4f64, etc., even though they promote, split, scalarize,
etc. to types that support hardware FMAs.
The function has also been slightly renamed for consistency and to force a
merge/build conflict for any out-of-tree target implementing it. To resolve,
see comments and fixed in-tree examples.
llvm-svn: 185956
2013-07-10 02:16:56 +08:00
|
|
|
/// isFMAFasterThanFMulAndFAdd - Return true if an FMA operation is faster
|
|
|
|
/// than a pair of fmul and fadd instructions. fmuladd intrinsics will be
|
|
|
|
/// expanded to FMAs when this method returns true, otherwise fmuladd is
|
|
|
|
/// expanded to fmul + fadd.
|
2014-04-29 15:57:37 +08:00
|
|
|
bool isFMAFasterThanFMulAndFAdd(EVT VT) const override;
|
2012-06-22 08:49:52 +08:00
|
|
|
|
Revert "r225811 - Revert "r225808 - [PowerPC] Add StackMap/PatchPoint support""
This re-applies r225808, fixed to avoid problems with SDAG dependencies along
with the preceding fix to ScheduleDAGSDNodes::RegDefIter::InitNodeNumDefs.
These problems caused the original regression tests to assert/segfault on many
(but not all) systems.
Original commit message:
This commit does two things:
1. Refactors PPCFastISel to use more of the common infrastructure for call
lowering (this lets us take advantage of this common code for lowering some
common intrinsics, stackmap/patchpoint among them).
2. Adds support for stackmap/patchpoint lowering. For the most part, this is
very similar to the support in the AArch64 target, with the obvious differences
(different registers, NOP instructions, etc.). The test cases are adapted
from the AArch64 test cases.
One difference of note is that the patchpoint call sequence takes 24 bytes, so
you can't use less than that (on AArch64 you can go down to 16). Also, as noted
in the docs, we take the patchpoint address to be the actual code address
(assuming the call is local in the TOC-sharing sense), which should yield
higher performance than generating the full cross-DSO indirect-call sequence
and is likely just as useful for JITed code (if not, we'll change it).
StackMaps and Patchpoints are still marked as experimental, and so this support
is doubly experimental. So go ahead and experiment!
llvm-svn: 225909
2015-01-14 09:07:51 +08:00
|
|
|
const MCPhysReg *getScratchRegisters(CallingConv::ID CC) const override;
|
|
|
|
|
2014-04-01 01:48:16 +08:00
|
|
|
// Should we expand the build vector with shuffles?
|
2014-04-29 15:57:37 +08:00
|
|
|
bool
|
2014-04-01 01:48:16 +08:00
|
|
|
shouldExpandBuildVectorWithShuffles(EVT VT,
|
2014-04-29 15:57:37 +08:00
|
|
|
unsigned DefinedValues) const override;
|
2014-04-01 01:48:16 +08:00
|
|
|
|
2013-07-30 08:50:39 +08:00
|
|
|
/// createFastISel - This method returns a target-specific FastISel object,
|
|
|
|
/// or null if the target does not support "fast" instruction selection.
|
2014-04-29 15:57:37 +08:00
|
|
|
FastISel *createFastISel(FunctionLoweringInfo &FuncInfo,
|
|
|
|
const TargetLibraryInfo *LibInfo) const override;
|
2013-07-30 08:50:39 +08:00
|
|
|
|
[PowerPC] ELFv2 aggregate passing support
This patch adds infrastructure support for passing array types
directly. These can be used by the front-end to pass aggregate
types (coerced to an appropriate array type). The details of the
array type being used inform the back-end about ABI-relevant
properties. Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
GPRs/stack slots (for float / vector / integer element types,
respectively)
- what the alignment requirements of the parameter are when passed in
GPRs/stack slots (8 for float / 16 for vector / the element type
size for integer element types) -- this corresponds to the
"byval align" field
Using the infrastructure provided by this patch, a companion patch
to clang will enable two features:
- In the ELFv2 ABI, pass (and return) "homogeneous" floating-point
or vector aggregates in FPRs and VRs (this is similar to the ARM
homogeneous aggregate ABI)
- As an optimization for both ELFv1 and ELFv2 ABIs, pass aggregates
that fit fully in registers without using the "byval" mechanism
The patch uses the functionArgumentNeedsConsecutiveRegisters callback
to encode that special treatment is required for all directly-passed
array types. The isInConsecutiveRegs / isInConsecutiveRegsLast bits set
as a results are then used to implement the required size and alignment
rules in CalculateStackSlotSize / CalculateStackSlotAlignment etc.
As a related change, the ABI routines have to be modified to support
passing floating-point types in GPRs. This is necessary because with
homogeneous aggregates of 4-byte float type we can now run out of FPRs
*before* we run out of the 64-byte argument save area that is shadowed
by GPRs. Any extra floating-point arguments that no longer fit in FPRs
must now be passed in GPRs until we run out of those too.
Note that there was already code to pass floating-point arguments in
GPRs used with vararg parameters, which was done by writing the argument
out to the argument save area first and then reloading into GPRs. The
patch re-implements this, however, in favor of code packing float arguments
directly via extension/truncation, BITCAST, and BUILD_PAIR operations.
This is required to support the ELFv2 ABI, since we cannot unconditionally
write to the argument save area (which the caller might not have allocated).
The change does, however, affect ELFv1 varags routines too; but even here
the overall effect should be advantageous: Instead of loading the argument
into the FPR, then storing the argument to the stack slot, and finally
reloading the argument from the stack slot into a GPR, the new code now
just loads the argument into the FPR, and subsequently loads the argument
into the GPR (via BITCAST). That BITCAST might imply a save/reload from
a stack temporary (in which case we're no worse than before); but it
might be implemented more efficiently in some cases.
The final part of the patch enables up to 8 FPRs and VRs for argument
return in PPCCallingConv.td; this is required to support returning
ELFv2 homogeneous aggregates. (Note that this doesn't affect other ABIs
since LLVM wil only look for which register to use if the parameter is
marked as "direct" return anyway.)
Reviewed by Hal Finkel.
llvm-svn: 213493
2014-07-21 08:13:26 +08:00
|
|
|
/// \brief Returns true if an argument of type Ty needs to be passed in a
|
|
|
|
/// contiguous block of registers in calling convention CallConv.
|
|
|
|
bool functionArgumentNeedsConsecutiveRegisters(
|
|
|
|
Type *Ty, CallingConv::ID CallConv, bool isVarArg) const override {
|
|
|
|
// We support any array type as "consecutive" block in the parameter
|
|
|
|
// save area. The element type defines the alignment requirement and
|
|
|
|
// whether the argument should go in GPRs, FPRs, or VRs if available.
|
|
|
|
//
|
|
|
|
// Note that clang uses this capability both to implement the ELFv2
|
|
|
|
// homogeneous float/vector aggregate ABI, and to avoid having to use
|
|
|
|
// "byval" when passing aggregates that might fully fit in registers.
|
|
|
|
return Ty->isArrayTy();
|
|
|
|
}
|
|
|
|
|
2015-11-07 09:11:31 +08:00
|
|
|
/// If a physical register, this returns the register that receives the
|
|
|
|
/// exception address on entry to an EH pad.
|
|
|
|
unsigned
|
|
|
|
getExceptionPointerRegister(const Constant *PersonalityFn) const override;
|
2015-01-07 06:31:02 +08:00
|
|
|
|
2015-11-07 09:11:31 +08:00
|
|
|
/// If a physical register, this returns the register that receives the
|
|
|
|
/// exception typeid on entry to a landing pad.
|
|
|
|
unsigned
|
|
|
|
getExceptionSelectorRegister(const Constant *PersonalityFn) const override;
|
|
|
|
|
2016-04-20 04:14:52 +08:00
|
|
|
/// Override to support customized stack guard loading.
|
|
|
|
bool useLoadStackGuardNode() const override;
|
|
|
|
void insertSSPDeclarations(Module &M) const override;
|
|
|
|
|
2015-11-07 09:11:31 +08:00
|
|
|
private:
|
2015-01-07 06:31:02 +08:00
|
|
|
struct ReuseLoadInfo {
|
|
|
|
SDValue Ptr;
|
|
|
|
SDValue Chain;
|
|
|
|
SDValue ResChain;
|
|
|
|
MachinePointerInfo MPI;
|
[CodeGen] Split out the notions of MI invariance and MI dereferenceability.
Summary:
An IR load can be invariant, dereferenceable, neither, or both. But
currently, MI's notion of invariance is IR-invariant &&
IR-dereferenceable.
This patch splits up the notions of invariance and dereferenceability at
the MI level. It's NFC, so adds some probably-unnecessary
"is-dereferenceable" checks, which we can remove later if desired.
Reviewers: chandlerc, tstellarAMD
Subscribers: jholewinski, arsenm, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D23371
llvm-svn: 281151
2016-09-11 09:38:58 +08:00
|
|
|
bool IsDereferenceable;
|
2015-01-07 06:31:02 +08:00
|
|
|
bool IsInvariant;
|
|
|
|
unsigned Alignment;
|
|
|
|
AAMDNodes AAInfo;
|
|
|
|
const MDNode *Ranges;
|
|
|
|
|
[CodeGen] Split out the notions of MI invariance and MI dereferenceability.
Summary:
An IR load can be invariant, dereferenceable, neither, or both. But
currently, MI's notion of invariance is IR-invariant &&
IR-dereferenceable.
This patch splits up the notions of invariance and dereferenceability at
the MI level. It's NFC, so adds some probably-unnecessary
"is-dereferenceable" checks, which we can remove later if desired.
Reviewers: chandlerc, tstellarAMD
Subscribers: jholewinski, arsenm, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D23371
llvm-svn: 281151
2016-09-11 09:38:58 +08:00
|
|
|
ReuseLoadInfo()
|
|
|
|
: IsDereferenceable(false), IsInvariant(false), Alignment(0),
|
|
|
|
Ranges(nullptr) {}
|
|
|
|
|
|
|
|
MachineMemOperand::Flags MMOFlags() const {
|
|
|
|
MachineMemOperand::Flags F = MachineMemOperand::MONone;
|
|
|
|
if (IsDereferenceable)
|
|
|
|
F |= MachineMemOperand::MODereferenceable;
|
|
|
|
if (IsInvariant)
|
|
|
|
F |= MachineMemOperand::MOInvariant;
|
|
|
|
return F;
|
|
|
|
}
|
2015-01-07 06:31:02 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
bool canReuseLoadAddress(SDValue Op, EVT MemVT, ReuseLoadInfo &RLI,
|
2015-01-09 09:34:30 +08:00
|
|
|
SelectionDAG &DAG,
|
|
|
|
ISD::LoadExtType ET = ISD::NON_EXTLOAD) const;
|
2015-01-07 06:31:02 +08:00
|
|
|
void spliceIntoChain(SDValue ResChain, SDValue NewResChain,
|
|
|
|
SelectionDAG &DAG) const;
|
|
|
|
|
|
|
|
void LowerFP_TO_INTForReuse(SDValue Op, ReuseLoadInfo &RLI,
|
2016-06-12 23:39:02 +08:00
|
|
|
SelectionDAG &DAG, const SDLoc &dl) const;
|
2015-04-11 18:40:42 +08:00
|
|
|
SDValue LowerFP_TO_INTDirectMove(SDValue Op, SelectionDAG &DAG,
|
2016-06-12 23:39:02 +08:00
|
|
|
const SDLoc &dl) const;
|
2015-04-11 18:40:42 +08:00
|
|
|
SDValue LowerINT_TO_FPDirectMove(SDValue Op, SelectionDAG &DAG,
|
2016-06-12 23:39:02 +08:00
|
|
|
const SDLoc &dl) const;
|
2015-01-07 06:31:02 +08:00
|
|
|
|
2008-07-28 05:46:04 +08:00
|
|
|
SDValue getFramePointerFrameIndex(SelectionDAG & DAG) const;
|
|
|
|
SDValue getReturnAddrFrameIndex(SelectionDAG & DAG) const;
|
2008-04-30 17:16:33 +08:00
|
|
|
|
2010-01-27 08:07:07 +08:00
|
|
|
bool
|
|
|
|
IsEligibleForTailCallOptimization(SDValue Callee,
|
|
|
|
CallingConv::ID CalleeCC,
|
|
|
|
bool isVarArg,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins,
|
|
|
|
SelectionDAG& DAG) const;
|
|
|
|
|
2016-04-06 10:04:38 +08:00
|
|
|
bool
|
|
|
|
IsEligibleForTailCallOptimization_64SVR4(
|
|
|
|
SDValue Callee,
|
|
|
|
CallingConv::ID CalleeCC,
|
|
|
|
ImmutableCallSite *CS,
|
|
|
|
bool isVarArg,
|
|
|
|
const SmallVectorImpl<ISD::OutputArg> &Outs,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins,
|
|
|
|
SelectionDAG& DAG) const;
|
|
|
|
|
2016-06-12 23:39:02 +08:00
|
|
|
SDValue EmitTailCallLoadFPAndRetAddr(SelectionDAG &DAG, int SPDiff,
|
|
|
|
SDValue Chain, SDValue &LROpOut,
|
2016-07-07 09:08:21 +08:00
|
|
|
SDValue &FPOpOut,
|
2016-06-12 23:39:02 +08:00
|
|
|
const SDLoc &dl) const;
|
2010-04-17 23:26:15 +08:00
|
|
|
|
|
|
|
SDValue LowerRETURNADDR(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerFRAMEADDR(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerConstantPool(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerBlockAddress(SDValue Op, SelectionDAG &DAG) const;
|
2012-06-05 01:36:38 +08:00
|
|
|
SDValue LowerGlobalTLSAddress(SDValue Op, SelectionDAG &DAG) const;
|
2010-04-17 23:26:15 +08:00
|
|
|
SDValue LowerGlobalAddress(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerJumpTable(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerSETCC(SDValue Op, SelectionDAG &DAG) const;
|
2011-09-06 21:37:06 +08:00
|
|
|
SDValue LowerINIT_TRAMPOLINE(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerADJUST_TRAMPOLINE(SDValue Op, SelectionDAG &DAG) const;
|
2016-07-07 08:39:27 +08:00
|
|
|
SDValue LowerVASTART(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerVAARG(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerVACOPY(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerSTACKRESTORE(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerGET_DYNAMIC_AREA_OFFSET(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerDYNAMIC_STACKALLOC(SDValue Op, SelectionDAG &DAG) const;
|
Add ISD::EH_DWARF_CFA, simplify @llvm.eh.dwarf.cfa on Mips, fix on PowerPC
LLVM has an @llvm.eh.dwarf.cfa intrinsic, used to lower the GCC-compatible
__builtin_dwarf_cfa() builtin. As pointed out in PR26761, this is currently
broken on PowerPC (and likely on ARM as well). Currently, @llvm.eh.dwarf.cfa is
lowered using:
ADD(FRAMEADDR, FRAME_TO_ARGS_OFFSET)
where FRAME_TO_ARGS_OFFSET defaults to the constant zero. On x86,
FRAME_TO_ARGS_OFFSET is lowered to 2*SlotSize. This setup, however, does not
work for PowerPC. Because of the way that the stack layout works, the canonical
frame address is not exactly (FRAMEADDR + FRAME_TO_ARGS_OFFSET) on PowerPC
(there is a lower save-area offset as well), so it is not just a matter of
implementing FRAME_TO_ARGS_OFFSET for PowerPC (unless we redefine its
semantics -- We can do that, since it is currently used only for
@llvm.eh.dwarf.cfa lowering, but the better to directly lower the CFA construct
itself (since it can be easily represented as a fixed-offset FrameIndex)). Mips
currently does this, but by using a custom lowering for ADD that specifically
recognizes the (FRAMEADDR, FRAME_TO_ARGS_OFFSET) pattern.
This change introduces a ISD::EH_DWARF_CFA node, which by default expands using
the existing logic, but can be directly lowered by the target. Mips is updated
to use this method (which simplifies its implementation, and I suspect makes it
more robust), and updates PowerPC to do the same.
Fixes PR26761.
Differential Revision: https://reviews.llvm.org/D24038
llvm-svn: 280350
2016-09-01 18:28:47 +08:00
|
|
|
SDValue LowerEH_DWARF_CFA(SDValue Op, SelectionDAG &DAG) const;
|
Add CR-bit tracking to the PowerPC backend for i1 values
This change enables tracking i1 values in the PowerPC backend using the
condition register bits. These bits can be treated on PowerPC as separate
registers; individual bit operations (and, or, xor, etc.) are supported.
Tracking booleans in CR bits has several advantages:
- Reduction in register pressure (because we no longer need GPRs to store
boolean values).
- Logical operations on booleans can be handled more efficiently; we used to
have to move all results from comparisons into GPRs, perform promoted
logical operations in GPRs, and then move the result back into condition
register bits to be used by conditional branches. This can be very
inefficient, because the throughput of these CR <-> GPR moves have high
latency and low throughput (especially when other associated instructions
are accounted for).
- On the POWER7 and similar cores, we can increase total throughput by using
the CR bits. CR bit operations have a dedicated functional unit.
Most of this is more-or-less mechanical: Adjustments were needed in the
calling-convention code, support was added for spilling/restoring individual
condition-register bits, and conditional branch instruction definitions taking
specific CR bits were added (plus patterns and code for generating bit-level
operations).
This is enabled by default when running at -O2 and higher. For -O0 and -O1,
where the ability to debug is more important, this feature is disabled by
default. Individual CR bits do not have assigned DWARF register numbers,
and storing values in CR bits makes them invisible to the debugger.
It is critical, however, that we don't move i1 values that have been promoted
to larger values (such as those passed as function arguments) into bit
registers only to quickly turn around and move the values back into GPRs (such
as happens when values are returned by functions). A pair of target-specific
DAG combines are added to remove the trunc/extends in:
trunc(binary-ops(binary-ops(zext(x), zext(y)), ...)
and:
zext(binary-ops(binary-ops(trunc(x), trunc(y)), ...)
In short, we only want to use CR bits where some of the i1 values come from
comparisons or are used by conditional branches or selects. To put it another
way, if we can do the entire i1 computation in GPRs, then we probably should
(on the POWER7, the GPR-operation throughput is higher, and for all cores, the
CR <-> GPR moves are expensive).
POWER7 test-suite performance results (from 10 runs in each configuration):
SingleSource/Benchmarks/Misc/mandel-2: 35% speedup
MultiSource/Benchmarks/Prolangs-C++/city/city: 21% speedup
MultiSource/Benchmarks/MiBench/automotive-susan: 23% speedup
SingleSource/Benchmarks/CoyoteBench/huffbench: 13% speedup
SingleSource/Benchmarks/Misc-C++/Large/sphereflake: 13% speedup
SingleSource/Benchmarks/Misc-C++/mandel-text: 10% speedup
SingleSource/Benchmarks/Misc-C++-EH/spirit: 10% slowdown
MultiSource/Applications/lemon/lemon: 8% slowdown
llvm-svn: 202451
2014-02-28 08:27:01 +08:00
|
|
|
SDValue LowerLOAD(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerSTORE(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerTRUNCATE(SDValue Op, SelectionDAG &DAG) const;
|
2010-04-17 23:26:15 +08:00
|
|
|
SDValue LowerSELECT_CC(SDValue Op, SelectionDAG &DAG) const;
|
2016-06-12 23:39:02 +08:00
|
|
|
SDValue LowerFP_TO_INT(SDValue Op, SelectionDAG &DAG,
|
|
|
|
const SDLoc &dl) const;
|
2013-04-02 01:52:07 +08:00
|
|
|
SDValue LowerINT_TO_FP(SDValue Op, SelectionDAG &DAG) const;
|
2010-04-17 23:26:15 +08:00
|
|
|
SDValue LowerFLT_ROUNDS_(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerSHL_PARTS(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerSRL_PARTS(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerSRA_PARTS(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerBUILD_VECTOR(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerVECTOR_SHUFFLE(SDValue Op, SelectionDAG &DAG) const;
|
2016-09-14 22:19:09 +08:00
|
|
|
SDValue LowerINSERT_VECTOR_ELT(SDValue Op, SelectionDAG &DAG) const;
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
SDValue LowerEXTRACT_VECTOR_ELT(SDValue Op, SelectionDAG &DAG) const;
|
2010-04-17 23:26:15 +08:00
|
|
|
SDValue LowerINTRINSIC_WO_CHAIN(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerSCALAR_TO_VECTOR(SDValue Op, SelectionDAG &DAG) const;
|
2014-03-30 21:22:59 +08:00
|
|
|
SDValue LowerSIGN_EXTEND_INREG(SDValue Op, SelectionDAG &DAG) const;
|
2010-04-17 23:26:15 +08:00
|
|
|
SDValue LowerMUL(SDValue Op, SelectionDAG &DAG) const;
|
Major calling convention code refactoring.
Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.
This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.
This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.
llvm-svn: 78142
2009-08-05 09:29:28 +08:00
|
|
|
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
SDValue LowerVectorLoad(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue LowerVectorStore(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
|
Major calling convention code refactoring.
Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.
This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.
This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.
llvm-svn: 78142
2009-08-05 09:29:28 +08:00
|
|
|
SDValue LowerCallResult(SDValue Chain, SDValue InFlag,
|
2009-09-02 16:44:58 +08:00
|
|
|
CallingConv::ID CallConv, bool isVarArg,
|
Major calling convention code refactoring.
Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.
This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.
This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.
llvm-svn: 78142
2009-08-05 09:29:28 +08:00
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins,
|
2016-06-12 23:39:02 +08:00
|
|
|
const SDLoc &dl, SelectionDAG &DAG,
|
2010-04-17 23:26:15 +08:00
|
|
|
SmallVectorImpl<SDValue> &InVals) const;
|
2016-06-12 23:39:02 +08:00
|
|
|
SDValue FinishCall(CallingConv::ID CallConv, const SDLoc &dl,
|
2016-07-07 09:08:23 +08:00
|
|
|
bool isTailCall, bool isVarArg, bool isPatchPoint,
|
2016-06-12 23:39:02 +08:00
|
|
|
bool hasNest, SelectionDAG &DAG,
|
|
|
|
SmallVector<std::pair<unsigned, SDValue>, 8> &RegsToPass,
|
[PowerPC] Loosen ELFv1 PPC64 func descriptor loads for indirect calls
Function pointers under PPC64 ELFv1 (which is used on PPC64/Linux on the
POWER7, A2 and earlier cores) are really pointers to a function descriptor, a
structure with three pointers: the actual pointer to the code to which to jump,
the pointer to the TOC needed by the callee, and an environment pointer. We
used to chain these loads, and make them opaque to the rest of the optimizer,
so that they'd always occur directly before the call. This is not necessary,
and in fact, highly suboptimal on embedded cores. Once the function pointer is
known, the loads can be performed ahead of time; in fact, they can be hoisted
out of loops.
Now these function descriptors are almost always generated by the linker, and
thus the contents of the descriptors are invariant. As a result, by default,
we'll mark the associated loads as invariant (allowing them to be hoisted out
of loops). I've added a target feature to turn this off, however, just in case
someone needs that option (constructing an on-stack descriptor, casting it to a
function pointer, and then calling it cannot be well-defined C/C++ code, but I
can imagine some JIT-compilation system doing so).
Consider this simple test:
$ cat call.c
typedef void (*fp)();
void bar(fp x) {
for (int i = 0; i < 1600000000; ++i)
x();
}
$ cat main.c
typedef void (*fp)();
void bar(fp x);
void foo() {}
int main() {
bar(foo);
}
On the PPC A2 (the BG/Q supercomputer), marking the function-descriptor loads
as invariant brings the execution time down to ~8 seconds from ~32 seconds with
the loads in the loop.
The difference on the POWER7 is smaller. Compiling with:
gcc -std=c99 -O3 -mcpu=native call.c main.c : ~6 seconds [this is 4.8.2]
clang -O3 -mcpu=native call.c main.c : ~5.3 seconds
clang -O3 -mcpu=native call.c main.c -mno-invariant-function-descriptors : ~4 seconds
(looks like we'd benefit from additional loop unrolling here, as a first
guess, because this is faster with the extra loads)
The -mno-invariant-function-descriptors will be added to Clang shortly.
llvm-svn: 226207
2015-01-16 05:17:34 +08:00
|
|
|
SDValue InFlag, SDValue Chain, SDValue CallSeqStart,
|
2016-06-12 23:39:02 +08:00
|
|
|
SDValue &Callee, int SPDiff, unsigned NumBytes,
|
Major calling convention code refactoring.
Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.
This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.
This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.
llvm-svn: 78142
2009-08-05 09:29:28 +08:00
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins,
|
[PowerPC] Loosen ELFv1 PPC64 func descriptor loads for indirect calls
Function pointers under PPC64 ELFv1 (which is used on PPC64/Linux on the
POWER7, A2 and earlier cores) are really pointers to a function descriptor, a
structure with three pointers: the actual pointer to the code to which to jump,
the pointer to the TOC needed by the callee, and an environment pointer. We
used to chain these loads, and make them opaque to the rest of the optimizer,
so that they'd always occur directly before the call. This is not necessary,
and in fact, highly suboptimal on embedded cores. Once the function pointer is
known, the loads can be performed ahead of time; in fact, they can be hoisted
out of loops.
Now these function descriptors are almost always generated by the linker, and
thus the contents of the descriptors are invariant. As a result, by default,
we'll mark the associated loads as invariant (allowing them to be hoisted out
of loops). I've added a target feature to turn this off, however, just in case
someone needs that option (constructing an on-stack descriptor, casting it to a
function pointer, and then calling it cannot be well-defined C/C++ code, but I
can imagine some JIT-compilation system doing so).
Consider this simple test:
$ cat call.c
typedef void (*fp)();
void bar(fp x) {
for (int i = 0; i < 1600000000; ++i)
x();
}
$ cat main.c
typedef void (*fp)();
void bar(fp x);
void foo() {}
int main() {
bar(foo);
}
On the PPC A2 (the BG/Q supercomputer), marking the function-descriptor loads
as invariant brings the execution time down to ~8 seconds from ~32 seconds with
the loads in the loop.
The difference on the POWER7 is smaller. Compiling with:
gcc -std=c99 -O3 -mcpu=native call.c main.c : ~6 seconds [this is 4.8.2]
clang -O3 -mcpu=native call.c main.c : ~5.3 seconds
clang -O3 -mcpu=native call.c main.c -mno-invariant-function-descriptors : ~4 seconds
(looks like we'd benefit from additional loop unrolling here, as a first
guess, because this is faster with the extra loads)
The -mno-invariant-function-descriptors will be added to Clang shortly.
llvm-svn: 226207
2015-01-16 05:17:34 +08:00
|
|
|
SmallVectorImpl<SDValue> &InVals,
|
|
|
|
ImmutableCallSite *CS) const;
|
Major calling convention code refactoring.
Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.
This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.
This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.
llvm-svn: 78142
2009-08-05 09:29:28 +08:00
|
|
|
|
2014-04-29 15:57:37 +08:00
|
|
|
SDValue
|
2016-06-12 23:39:02 +08:00
|
|
|
LowerFormalArguments(SDValue Chain, CallingConv::ID CallConv, bool isVarArg,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins,
|
|
|
|
const SDLoc &dl, SelectionDAG &DAG,
|
|
|
|
SmallVectorImpl<SDValue> &InVals) const override;
|
Major calling convention code refactoring.
Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.
This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.
This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.
llvm-svn: 78142
2009-08-05 09:29:28 +08:00
|
|
|
|
2014-04-29 15:57:37 +08:00
|
|
|
SDValue
|
2012-05-26 00:35:28 +08:00
|
|
|
LowerCall(TargetLowering::CallLoweringInfo &CLI,
|
2014-04-29 15:57:37 +08:00
|
|
|
SmallVectorImpl<SDValue> &InVals) const override;
|
Major calling convention code refactoring.
Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.
This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.
This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.
llvm-svn: 78142
2009-08-05 09:29:28 +08:00
|
|
|
|
2014-04-29 15:57:37 +08:00
|
|
|
bool
|
2011-10-15 03:51:36 +08:00
|
|
|
CanLowerReturn(CallingConv::ID CallConv, MachineFunction &MF,
|
|
|
|
bool isVarArg,
|
|
|
|
const SmallVectorImpl<ISD::OutputArg> &Outs,
|
2014-04-29 15:57:37 +08:00
|
|
|
LLVMContext &Context) const override;
|
2011-10-15 03:51:36 +08:00
|
|
|
|
2016-06-12 23:39:02 +08:00
|
|
|
SDValue LowerReturn(SDValue Chain, CallingConv::ID CallConv, bool isVarArg,
|
|
|
|
const SmallVectorImpl<ISD::OutputArg> &Outs,
|
|
|
|
const SmallVectorImpl<SDValue> &OutVals,
|
|
|
|
const SDLoc &dl, SelectionDAG &DAG) const override;
|
|
|
|
|
|
|
|
SDValue extendArgForPPC64(ISD::ArgFlagsTy Flags, EVT ObjectVT,
|
|
|
|
SelectionDAG &DAG, SDValue ArgVal,
|
|
|
|
const SDLoc &dl) const;
|
|
|
|
|
|
|
|
SDValue LowerFormalArguments_Darwin(
|
|
|
|
SDValue Chain, CallingConv::ID CallConv, bool isVarArg,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins, const SDLoc &dl,
|
|
|
|
SelectionDAG &DAG, SmallVectorImpl<SDValue> &InVals) const;
|
|
|
|
SDValue LowerFormalArguments_64SVR4(
|
|
|
|
SDValue Chain, CallingConv::ID CallConv, bool isVarArg,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins, const SDLoc &dl,
|
|
|
|
SelectionDAG &DAG, SmallVectorImpl<SDValue> &InVals) const;
|
|
|
|
SDValue LowerFormalArguments_32SVR4(
|
|
|
|
SDValue Chain, CallingConv::ID CallConv, bool isVarArg,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins, const SDLoc &dl,
|
|
|
|
SelectionDAG &DAG, SmallVectorImpl<SDValue> &InVals) const;
|
|
|
|
|
|
|
|
SDValue createMemcpyOutsideCallSeq(SDValue Arg, SDValue PtrOff,
|
|
|
|
SDValue CallSeqStart,
|
|
|
|
ISD::ArgFlagsTy Flags, SelectionDAG &DAG,
|
|
|
|
const SDLoc &dl) const;
|
|
|
|
|
|
|
|
SDValue LowerCall_Darwin(SDValue Chain, SDValue Callee,
|
|
|
|
CallingConv::ID CallConv, bool isVarArg,
|
2016-07-07 09:08:23 +08:00
|
|
|
bool isTailCall, bool isPatchPoint,
|
2016-06-12 23:39:02 +08:00
|
|
|
const SmallVectorImpl<ISD::OutputArg> &Outs,
|
|
|
|
const SmallVectorImpl<SDValue> &OutVals,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins,
|
|
|
|
const SDLoc &dl, SelectionDAG &DAG,
|
|
|
|
SmallVectorImpl<SDValue> &InVals,
|
|
|
|
ImmutableCallSite *CS) const;
|
|
|
|
SDValue LowerCall_64SVR4(SDValue Chain, SDValue Callee,
|
|
|
|
CallingConv::ID CallConv, bool isVarArg,
|
2016-07-07 09:08:23 +08:00
|
|
|
bool isTailCall, bool isPatchPoint,
|
2016-06-12 23:39:02 +08:00
|
|
|
const SmallVectorImpl<ISD::OutputArg> &Outs,
|
|
|
|
const SmallVectorImpl<SDValue> &OutVals,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins,
|
|
|
|
const SDLoc &dl, SelectionDAG &DAG,
|
|
|
|
SmallVectorImpl<SDValue> &InVals,
|
|
|
|
ImmutableCallSite *CS) const;
|
|
|
|
SDValue LowerCall_32SVR4(SDValue Chain, SDValue Callee,
|
|
|
|
CallingConv::ID CallConv, bool isVarArg,
|
2016-07-07 09:08:23 +08:00
|
|
|
bool isTailCall, bool isPatchPoint,
|
2016-06-12 23:39:02 +08:00
|
|
|
const SmallVectorImpl<ISD::OutputArg> &Outs,
|
|
|
|
const SmallVectorImpl<SDValue> &OutVals,
|
|
|
|
const SmallVectorImpl<ISD::InputArg> &Ins,
|
|
|
|
const SDLoc &dl, SelectionDAG &DAG,
|
|
|
|
SmallVectorImpl<SDValue> &InVals,
|
|
|
|
ImmutableCallSite *CS) const;
|
2013-03-22 05:37:52 +08:00
|
|
|
|
|
|
|
SDValue lowerEH_SJLJ_SETJMP(SDValue Op, SelectionDAG &DAG) const;
|
|
|
|
SDValue lowerEH_SJLJ_LONGJMP(SDValue Op, SelectionDAG &DAG) const;
|
2013-04-03 12:01:11 +08:00
|
|
|
|
Add CR-bit tracking to the PowerPC backend for i1 values
This change enables tracking i1 values in the PowerPC backend using the
condition register bits. These bits can be treated on PowerPC as separate
registers; individual bit operations (and, or, xor, etc.) are supported.
Tracking booleans in CR bits has several advantages:
- Reduction in register pressure (because we no longer need GPRs to store
boolean values).
- Logical operations on booleans can be handled more efficiently; we used to
have to move all results from comparisons into GPRs, perform promoted
logical operations in GPRs, and then move the result back into condition
register bits to be used by conditional branches. This can be very
inefficient, because the throughput of these CR <-> GPR moves have high
latency and low throughput (especially when other associated instructions
are accounted for).
- On the POWER7 and similar cores, we can increase total throughput by using
the CR bits. CR bit operations have a dedicated functional unit.
Most of this is more-or-less mechanical: Adjustments were needed in the
calling-convention code, support was added for spilling/restoring individual
condition-register bits, and conditional branch instruction definitions taking
specific CR bits were added (plus patterns and code for generating bit-level
operations).
This is enabled by default when running at -O2 and higher. For -O0 and -O1,
where the ability to debug is more important, this feature is disabled by
default. Individual CR bits do not have assigned DWARF register numbers,
and storing values in CR bits makes them invisible to the debugger.
It is critical, however, that we don't move i1 values that have been promoted
to larger values (such as those passed as function arguments) into bit
registers only to quickly turn around and move the values back into GPRs (such
as happens when values are returned by functions). A pair of target-specific
DAG combines are added to remove the trunc/extends in:
trunc(binary-ops(binary-ops(zext(x), zext(y)), ...)
and:
zext(binary-ops(binary-ops(trunc(x), trunc(y)), ...)
In short, we only want to use CR bits where some of the i1 values come from
comparisons or are used by conditional branches or selects. To put it another
way, if we can do the entire i1 computation in GPRs, then we probably should
(on the POWER7, the GPR-operation throughput is higher, and for all cores, the
CR <-> GPR moves are expensive).
POWER7 test-suite performance results (from 10 runs in each configuration):
SingleSource/Benchmarks/Misc/mandel-2: 35% speedup
MultiSource/Benchmarks/Prolangs-C++/city/city: 21% speedup
MultiSource/Benchmarks/MiBench/automotive-susan: 23% speedup
SingleSource/Benchmarks/CoyoteBench/huffbench: 13% speedup
SingleSource/Benchmarks/Misc-C++/Large/sphereflake: 13% speedup
SingleSource/Benchmarks/Misc-C++/mandel-text: 10% speedup
SingleSource/Benchmarks/Misc-C++-EH/spirit: 10% slowdown
MultiSource/Applications/lemon/lemon: 8% slowdown
llvm-svn: 202451
2014-02-28 08:27:01 +08:00
|
|
|
SDValue DAGCombineExtBoolTrunc(SDNode *N, DAGCombinerInfo &DCI) const;
|
2016-07-05 17:22:29 +08:00
|
|
|
SDValue DAGCombineBuildVector(SDNode *N, DAGCombinerInfo &DCI) const;
|
Add CR-bit tracking to the PowerPC backend for i1 values
This change enables tracking i1 values in the PowerPC backend using the
condition register bits. These bits can be treated on PowerPC as separate
registers; individual bit operations (and, or, xor, etc.) are supported.
Tracking booleans in CR bits has several advantages:
- Reduction in register pressure (because we no longer need GPRs to store
boolean values).
- Logical operations on booleans can be handled more efficiently; we used to
have to move all results from comparisons into GPRs, perform promoted
logical operations in GPRs, and then move the result back into condition
register bits to be used by conditional branches. This can be very
inefficient, because the throughput of these CR <-> GPR moves have high
latency and low throughput (especially when other associated instructions
are accounted for).
- On the POWER7 and similar cores, we can increase total throughput by using
the CR bits. CR bit operations have a dedicated functional unit.
Most of this is more-or-less mechanical: Adjustments were needed in the
calling-convention code, support was added for spilling/restoring individual
condition-register bits, and conditional branch instruction definitions taking
specific CR bits were added (plus patterns and code for generating bit-level
operations).
This is enabled by default when running at -O2 and higher. For -O0 and -O1,
where the ability to debug is more important, this feature is disabled by
default. Individual CR bits do not have assigned DWARF register numbers,
and storing values in CR bits makes them invisible to the debugger.
It is critical, however, that we don't move i1 values that have been promoted
to larger values (such as those passed as function arguments) into bit
registers only to quickly turn around and move the values back into GPRs (such
as happens when values are returned by functions). A pair of target-specific
DAG combines are added to remove the trunc/extends in:
trunc(binary-ops(binary-ops(zext(x), zext(y)), ...)
and:
zext(binary-ops(binary-ops(trunc(x), trunc(y)), ...)
In short, we only want to use CR bits where some of the i1 values come from
comparisons or are used by conditional branches or selects. To put it another
way, if we can do the entire i1 computation in GPRs, then we probably should
(on the POWER7, the GPR-operation throughput is higher, and for all cores, the
CR <-> GPR moves are expensive).
POWER7 test-suite performance results (from 10 runs in each configuration):
SingleSource/Benchmarks/Misc/mandel-2: 35% speedup
MultiSource/Benchmarks/Prolangs-C++/city/city: 21% speedup
MultiSource/Benchmarks/MiBench/automotive-susan: 23% speedup
SingleSource/Benchmarks/CoyoteBench/huffbench: 13% speedup
SingleSource/Benchmarks/Misc-C++/Large/sphereflake: 13% speedup
SingleSource/Benchmarks/Misc-C++/mandel-text: 10% speedup
SingleSource/Benchmarks/Misc-C++-EH/spirit: 10% slowdown
MultiSource/Applications/lemon/lemon: 8% slowdown
llvm-svn: 202451
2014-02-28 08:27:01 +08:00
|
|
|
SDValue DAGCombineTruncBoolExt(SDNode *N, DAGCombinerInfo &DCI) const;
|
2015-01-06 14:01:57 +08:00
|
|
|
SDValue combineFPToIntToFP(SDNode *N, DAGCombinerInfo &DCI) const;
|
2014-09-27 07:01:47 +08:00
|
|
|
|
2014-10-01 04:28:48 +08:00
|
|
|
SDValue getRsqrtEstimate(SDValue Operand, DAGCombinerInfo &DCI,
|
2014-10-25 01:02:16 +08:00
|
|
|
unsigned &RefinementSteps,
|
|
|
|
bool &UseOneConstNR) const override;
|
2014-10-01 04:28:48 +08:00
|
|
|
SDValue getRecipEstimate(SDValue Operand, DAGCombinerInfo &DCI,
|
|
|
|
unsigned &RefinementSteps) const override;
|
2015-07-29 07:05:48 +08:00
|
|
|
unsigned combineRepeatedFPDivisors() const override;
|
2013-08-27 04:11:46 +08:00
|
|
|
|
|
|
|
CCAssignFn *useFastISelCCs(unsigned Flag) const;
|
2005-08-17 01:14:42 +08:00
|
|
|
};
|
2013-06-13 00:39:22 +08:00
|
|
|
|
2013-07-30 08:50:39 +08:00
|
|
|
namespace PPC {
|
|
|
|
FastISel *createFastISel(FunctionLoweringInfo &FuncInfo,
|
|
|
|
const TargetLibraryInfo *LibInfo);
|
|
|
|
}
|
|
|
|
|
2013-06-13 00:39:22 +08:00
|
|
|
bool CC_PPC32_SVR4_Custom_Dummy(unsigned &ValNo, MVT &ValVT, MVT &LocVT,
|
|
|
|
CCValAssign::LocInfo &LocInfo,
|
|
|
|
ISD::ArgFlagsTy &ArgFlags,
|
|
|
|
CCState &State);
|
|
|
|
|
|
|
|
bool CC_PPC32_SVR4_Custom_AlignArgRegs(unsigned &ValNo, MVT &ValVT,
|
|
|
|
MVT &LocVT,
|
|
|
|
CCValAssign::LocInfo &LocInfo,
|
|
|
|
ISD::ArgFlagsTy &ArgFlags,
|
|
|
|
CCState &State);
|
|
|
|
|
2016-08-05 16:47:26 +08:00
|
|
|
bool
|
|
|
|
CC_PPC32_SVR4_Custom_SkipLastArgRegsPPCF128(unsigned &ValNo, MVT &ValVT,
|
|
|
|
MVT &LocVT,
|
|
|
|
CCValAssign::LocInfo &LocInfo,
|
|
|
|
ISD::ArgFlagsTy &ArgFlags,
|
|
|
|
CCState &State);
|
|
|
|
|
2013-06-13 00:39:22 +08:00
|
|
|
bool CC_PPC32_SVR4_Custom_AlignFPArgRegs(unsigned &ValNo, MVT &ValVT,
|
|
|
|
MVT &LocVT,
|
|
|
|
CCValAssign::LocInfo &LocInfo,
|
|
|
|
ISD::ArgFlagsTy &ArgFlags,
|
|
|
|
CCState &State);
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2005-08-17 01:14:42 +08:00
|
|
|
|
|
|
|
#endif // LLVM_TARGET_POWERPC_PPC32ISELLOWERING_H
|