| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This type promotion is replacing a Tablegen pattern and it is already
covered by existing tests.
llvm-svn: 204617
|
| |
|
|
|
|
|
|
| |
And vice-versa, as long as the types are the same width.
There are a few R600 tests that will cover this.
llvm-svn: 204616
|
| |
|
|
|
|
| |
Each GPU family now has its own file.
llvm-svn: 204615
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[PPC64LE] ELFv2 ABI updates for the .opd section
The PPC64 Little Endian (PPC64LE) target supports the ELFv2 ABI, and as
such, does not have a ".opd" section. This is keyed off a _CALL_ELF=2
macro check.
The CALL_ELF check is not clearly documented at this time. The basis
for usage in this patch is from the gcc thread here:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01144.html
> Adding comment from Uli:
Looks good to me. I think the old-style JIT doesn't really work
anyway for 64-bit, but at least with this patch LLVM will compile
and link again on a ppc64le host ...
llvm-svn: 204614
|
| |
|
|
|
|
|
|
|
|
| |
Update DataLayout/DescriptionString for ppc64le
Similar LLVM change made in r203664
Testcase included.
llvm-svn: 204613
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These expressions already worked but weren't tested.
Patch by Robert N. M. Watson and David Chisnall (it was originally two patches)
Their work was sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3156
llvm-svn: 204612
|
| |
|
|
|
|
|
|
|
|
| |
Summary:
Patch by David Chisnall
His work was sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3155
llvm-svn: 204611
|
| |
|
|
|
|
| |
buildbots seem to OOM with that many threads
llvm-svn: 204610
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm under the impression that we used to infer the isCommutable flag from the
instruction-associated pattern. Regardless, we don't seem to do this (at least
by default) any more. I've gone through all of our instruction definitions, and
marked as commutative all of those that should be trivial to commute (by
exchanging the first two operands). There has been special code for the RL*
instructions, and that's not changed.
Before this change, we had the following commutative instructions:
RLDIMI
RLDIMIo
RLWIMI
RLWIMI8
RLWIMI8o
RLWIMIo
XSADDDP
XSMULDP
XVADDDP
XVADDSP
XVMULDP
XVMULSP
After:
ADD4
ADD4o
ADD8
ADD8o
ADDC
ADDC8
ADDC8o
ADDCo
ADDE
ADDE8
ADDE8o
ADDEo
AND
AND8
AND8o
ANDo
CRAND
CREQV
CRNAND
CRNOR
CROR
CRXOR
EQV
EQV8
EQV8o
EQVo
FADD
FADDS
FADDSo
FADDo
FMADD
FMADDS
FMADDSo
FMADDo
FMSUB
FMSUBS
FMSUBSo
FMSUBo
FMUL
FMULS
FMULSo
FMULo
FNMADD
FNMADDS
FNMADDSo
FNMADDo
FNMSUB
FNMSUBS
FNMSUBSo
FNMSUBo
MULHD
MULHDU
MULHDUo
MULHDo
MULHW
MULHWU
MULHWUo
MULHWo
MULLD
MULLDo
MULLW
MULLWo
NAND
NAND8
NAND8o
NANDo
NOR
NOR8
NOR8o
NORo
OR
OR8
OR8o
ORo
RLDIMI
RLDIMIo
RLWIMI
RLWIMI8
RLWIMI8o
RLWIMIo
VADDCUW
VADDFP
VADDSBS
VADDSHS
VADDSWS
VADDUBM
VADDUBS
VADDUHM
VADDUHS
VADDUWM
VADDUWS
VAND
VAVGSB
VAVGSH
VAVGSW
VAVGUB
VAVGUH
VAVGUW
VMADDFP
VMAXFP
VMAXSB
VMAXSH
VMAXSW
VMAXUB
VMAXUH
VMAXUW
VMHADDSHS
VMHRADDSHS
VMINFP
VMINSB
VMINSH
VMINSW
VMINUB
VMINUH
VMINUW
VMLADDUHM
VMULESB
VMULESH
VMULEUB
VMULEUH
VMULOSB
VMULOSH
VMULOUB
VMULOUH
VNMSUBFP
VOR
VXOR
XOR
XOR8
XOR8o
XORo
XSADDDP
XSMADDADP
XSMAXDP
XSMINDP
XSMSUBADP
XSMULDP
XSNMADDADP
XSNMSUBADP
XVADDDP
XVADDSP
XVMADDADP
XVMADDASP
XVMAXDP
XVMAXSP
XVMINDP
XVMINSP
XVMSUBADP
XVMSUBASP
XVMULDP
XVMULSP
XVNMADDADP
XVNMADDASP
XVNMSUBADP
XVNMSUBASP
XXLAND
XXLNOR
XXLOR
XXLXOR
This is a by-inspection change, and I'm not sure how to write a reliable test
case. I would like advice on this, however.
llvm-svn: 204609
|
| |
|
|
| |
llvm-svn: 204608
|
| |
|
|
| |
llvm-svn: 204607
|
| |
|
|
|
|
| |
pairs and calculate AHL addend.
llvm-svn: 204606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- If only two registers are passed to a three-register operation, then the
first argument is both source and destination register.
- If a non-register is passed as the last argument, generate the immediate
version of the instruction.
Also mark DADD commutative and add scheduling information (to the generic
scheduler), and implement DSUB.
Patch by David Chisnall
His work was sponsored by: DARPA, AFRL
CC: theraven
Differential Revision: http://llvm-reviews.chandlerc.com/D3148
llvm-svn: 204605
|
| |
|
|
| |
llvm-svn: 204604
|
| |
|
|
|
|
| |
It is already used for Linux and FreeBSD.
llvm-svn: 204603
|
| |
|
|
| |
llvm-svn: 204602
|
| |
|
|
|
|
|
| |
Revision 203667 has already added lldbHostWindows.a
to USEDLIBS. Revision 203785 just ended up adding a redundant entry.
llvm-svn: 204601
|
| |
|
|
| |
llvm-svn: 204600
|
| |
|
|
|
|
| |
lib/CodeGen/CGBuiltin.cpp:3136:12: warning: variable ‘TblPos’ set but not used [-Wunused-but-set-variable]
llvm-svn: 204599
|
| |
|
|
| |
llvm-svn: 204598
|
| |
|
|
|
|
| |
warning C4345: behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized
llvm-svn: 204597
|
| |
|
|
| |
llvm-svn: 204596
|
| |
|
|
| |
llvm-svn: 204595
|
| |
|
|
|
|
| |
There is no need to schedule this extra pass if it will have nothing to do.
llvm-svn: 204594
|
| |
|
|
| |
llvm-svn: 204593
|
| |
|
|
| |
llvm-svn: 204592
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've done some experimentation with this, and it looks like using the
lower-latency (but lower throughput) copy instruction is essentially always the
right thing to do.
My assumption is that, in order to be relatively sure that the higher-latency
copy will increase throughput, we'd want to have it unlikely to be in-flight
with its use. On the P7, the global completion table (GCT) can hold a maximum
of 120 instructions, shared among all active threads (up to 4), giving 30
instructions per thread. So specifically, I'd require at least that many
instructions between the copy and the use before the high-latency variant is
used.
Trying this, however, over the entire test suite resulted in zero cases where
the high-latency form would be preferable. This may be a consequence of the
fact that the scheduler views copies as free, and so they tend to end up close
to their uses. For this experiment I created a function:
unsigned chooseVSXCopy(MachineBasicBlock &MBB,
MachineBasicBlock::iterator I,
unsigned DestReg, unsigned SrcReg,
unsigned StartDist = 1,
unsigned Depth = 3) const;
with an implementation like:
if (!Depth)
return PPC::XXLOR;
const unsigned MaxDist = 30;
unsigned Dist = StartDist;
for (auto J = I, JE = MBB.end(); J != JE && Dist <= MaxDist; ++J) {
if (J->isTransient() && !J->isCopy())
continue;
if (J->isCall() || J->isReturn() || J->readsRegister(DestReg, TRI))
return PPC::XXLOR;
++Dist;
}
// We've exceeded the required distance for the high-latency form, use it.
if (Dist > MaxDist)
return PPC::XVCPSGNDP;
// If this is only an exit block, use the low-latency form.
if (MBB.succ_empty())
return PPC::XXLOR;
// We've reached the end of the block, check the successor blocks (up to some
// depth), and use the high-latency form if that is okay with all successors.
for (auto J = MBB.succ_begin(), JE = MBB.succ_end(); J != JE; ++J) {
if (chooseVSXCopy(**J, (*J)->begin(), DestReg, SrcReg,
Dist, --Depth) == PPC::XXLOR)
return PPC::XXLOR;
}
// All of our successor blocks seem okay with the high-latency variant, so
// we'll use it.
return PPC::XVCPSGNDP;
and then changed the copy opcode selection from:
Opc = PPC::XXLOR;
to:
Opc = chooseVSXCopy(MBB, std::next(I), DestReg, SrcReg);
In conclusion, I'm removing the FIXME from the comment, because I believe that
there is, at least absent other examples, nothing to fix.
llvm-svn: 204591
|
| |
|
|
|
|
| |
Failing due to PR19207.
llvm-svn: 204590
|
| |
|
|
| |
llvm-svn: 204589
|
| |
|
|
|
|
| |
Thanks to Richard Smith for catching this!
llvm-svn: 204588
|
| |
|
|
|
|
|
|
|
| |
Use two check-prefix patterns per FileCheck invocation for these tests,
this cleanly removes redundant CHECK directives.
Thanks to Richard Smith for the idea!
llvm-svn: 204587
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
"special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.
Thanks to Richard Smith for pointing these out!
llvm-svn: 204586
|
| |
|
|
| |
llvm-svn: 204585
|
| |
|
|
| |
llvm-svn: 204584
|
| |
|
|
| |
llvm-svn: 204583
|
| |
|
|
|
|
| |
They pass again with the fix in r204581.
llvm-svn: 204582
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We were already propagating the section in
a = b
With this patch we also propagate it for
a = b + 1
llvm-svn: 204581
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 204580
|
| |
|
|
|
|
|
| |
- create_link doesn't work for nonexistent file.
- remove cannot remove working directory.
llvm-svn: 204579
|
| |
|
|
| |
llvm-svn: 204578
|
| |
|
|
|
|
| |
Proper redeclaration warnings for dllimport are not implemented yet.
llvm-svn: 204577
|
| |
|
|
|
|
|
| |
dllimport implies a definition which means the 'extern' keyword is optional
when declaring imported variables.
llvm-svn: 204576
|
| |
|
|
| |
llvm-svn: 204575
|
| |
|
|
| |
llvm-svn: 204574
|
| |
|
|
| |
llvm-svn: 204573
|
| |
|
|
|
|
| |
'TemplateArgument's.
llvm-svn: 204572
|
| |
|
|
| |
llvm-svn: 204571
|
| |
|
|
|
|
|
| |
namespace, we need to update both the visible names of that namespace and of
its enclosing namespace set.
llvm-svn: 204570
|
| |
|
|
| |
llvm-svn: 204569
|
| |
|
|
|
|
|
| |
the update set rather than the current DeclContext. Add test for the local
extern case too.
llvm-svn: 204568
|