|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1 |
|
| #
01548868 |
| 27-Jul-2022 |
Umesh Kalappa <[email protected]> |
[PowerPC] Change long to int64_t (which is always 64 bit or 8 bytes )
We can't guarantee the long always 64 bits like WINDOWS or LLP64 data model (rare but we should consider).
So use int64_t from
[PowerPC] Change long to int64_t (which is always 64 bit or 8 bytes )
We can't guarantee the long always 64 bits like WINDOWS or LLP64 data model (rare but we should consider).
So use int64_t from inttypes.h and safe in this case.
Fixes https://github.com/llvm/llvm-project/issues/55911 .
(cherry picked from commit f38ea84a9f32058f3c2813b6f29b840c59de118c)
show more ...
|
|
Revision tags: llvmorg-16-init, llvmorg-14.0.6 |
|
| #
7a47ee51 |
| 21-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Don't use Optional::getValue (NFC)
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
| #
d6b07348 |
| 19-Jan-2022 |
Jim Lin <[email protected]> |
[NFC] Use Register instead of unsigned
|
| #
10d3bf95 |
| 17-Jan-2022 |
Sean Fertile <[email protected]> |
[PowerPC][AIX] Fallback to DAG-ISEL if global has toc-data attribute.
FAST-ISEL should fall back to DAG-ISEL when a global variable has the toc-data attribute. A number of the checks were duplicated
[PowerPC][AIX] Fallback to DAG-ISEL if global has toc-data attribute.
FAST-ISEL should fall back to DAG-ISEL when a global variable has the toc-data attribute. A number of the checks were duplicated in the lit test becuase of 1) Slightly different output between -O0 and -O2 due to FAST-ISEL vs DAG-ISEL codegen. 2) In preperation of a peephole optimization that will run when optimizations are enabled.
Differential Revision: https://reviews.llvm.org/D115373
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc2 |
|
| #
2c46ca96 |
| 30-Nov-2021 |
Chen Zheng <[email protected]> |
[PowerPC] fast isel can lower intrinsics call on AIX.
Reviewed By: qiucf
Differential Revision: https://reviews.llvm.org/D114778
|
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3 |
|
| #
042a6564 |
| 07-Sep-2021 |
Jinsong Ji <[email protected]> |
[PowerPC] Guard XSRSP in P8 for FastISel
This is exposed by enabling FastIsel on 64bit AIX. We are generating XSRSP regardless of the arch, which may be wrong when -mcpu=pwr7.
The fix is to guard t
[PowerPC] Guard XSRSP in P8 for FastISel
This is exposed by enabling FastIsel on 64bit AIX. We are generating XSRSP regardless of the arch, which may be wrong when -mcpu=pwr7.
The fix is to guard the generation in P8 only.
Reviewed By: qiucf
Differential Revision: https://reviews.llvm.org/D109365
show more ...
|
| #
d0f9553e |
| 03-Sep-2021 |
Qiu Chaofan <[email protected]> |
[PowerPC] Enable fast-isel on AIX 64 subtarget
This patch basically enables fast-isel for AIX 64-bit subtarget (previously enabled only for ELF 64). The initial motivation is to introduce branch fol
[PowerPC] Enable fast-isel on AIX 64 subtarget
This patch basically enables fast-isel for AIX 64-bit subtarget (previously enabled only for ELF 64). The initial motivation is to introduce branch folding to AIX generated code for correct debug behavior. I also saw some compiling time improvement in a few LLVM test-suite benchmarks. (toast, dbms, cjpeg, burg, etc.)
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D98844
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3 |
|
| #
59d90fe8 |
| 19-Jun-2021 |
Fangrui Song <[email protected]> |
Simplify some typedef struct
|
|
Revision tags: llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
| #
66506582 |
| 09-Mar-2021 |
Nikita Popov <[email protected]> |
[FastISel] Remove kill tracking
This is a followup to D98145: As far as I know, tracking of kill flags in FastISel is just a compile-time optimization. However, I'm not actually seeing any compile-t
[FastISel] Remove kill tracking
This is a followup to D98145: As far as I know, tracking of kill flags in FastISel is just a compile-time optimization. However, I'm not actually seeing any compile-time regression when removing the tracking. This probably used to be more important in the past, before FastRA was switched to allocate instructions in reverse order, which means that it discovers kills as a matter of course.
As such, the kill tracking doesn't really seem to serve a purpose anymore, and just adds additional complexity and potential for errors. This patch removes it entirely. The primary changes are dropping the hasTrivialKill() method and removing the kill arguments from the emitFast methods. The rest is mechanical fixup.
Differential Revision: https://reviews.llvm.org/D98294
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
| #
4bdab548 |
| 06-Jan-2021 |
Kit Barton <[email protected]> |
[PPC] Remove old PPCSubTarget variable.
The PPCSubTarget variable has been replaced with the Subtarget variable. This removes the remaining instances of PPCSubTarget as they are no longer necessary.
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
d14e5180 |
| 03-Nov-2020 |
Qiu Chaofan <[email protected]> |
[PowerPC] Skip IEEE 128-bit FP type in FastISel
Vector types, quadword integers and f128 currently cannot be handled in FastISel. We did not skip f128 type in lowering arguments, which causes a cras
[PowerPC] Skip IEEE 128-bit FP type in FastISel
Vector types, quadword integers and f128 currently cannot be handled in FastISel. We did not skip f128 type in lowering arguments, which causes a crash. This patch will fix it.
Reviewed By: steven.zhang
Differential Revision: https://reviews.llvm.org/D90206
show more ...
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
| #
075a92de |
| 24-Aug-2020 |
Nemanja Ivanovic <[email protected]> |
[PowerPC] Do not use FISel for calls and TOC-based accesses with PC-Rel
PC-Relative addressing introduces a fair bit of complexity for correctly eliminating TOC accesses. FastISel does not include a
[PowerPC] Do not use FISel for calls and TOC-based accesses with PC-Rel
PC-Relative addressing introduces a fair bit of complexity for correctly eliminating TOC accesses. FastISel does not include any of that handling so we miscompile code with -mcpu=pwr10 -O0 if it includes an external call that FastISel does not handle followed by any of the following:
Floating point constant materialization Materialization of a GlobalValue Call that FastISel does handle
This patch switches to SDISel for any of the above.
Differential revision: https://reviews.llvm.org/D86343
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3 |
|
| #
28de229b |
| 01-Jul-2020 |
Guillaume Chatelet <[email protected]> |
[Alignment][NFC] Migrate MachineFrameInfo::CreateStackObject to Align
This patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm
[Alignment][NFC] Migrate MachineFrameInfo::CreateStackObject to Align
This patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Differential Revision: https://reviews.llvm.org/D82894
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc2 |
|
| #
5ca75130 |
| 09-Jun-2020 |
Kit Barton <[email protected]> |
[PPC][NFC] Add Subtarget and replace all uses of PPCSubTarget with Subtarget.
Summary: In preparation for GlobalISel, PPCSubTarget needs to be renamed to Subtarget as there places in GlobalISel that
[PPC][NFC] Add Subtarget and replace all uses of PPCSubTarget with Subtarget.
Summary: In preparation for GlobalISel, PPCSubTarget needs to be renamed to Subtarget as there places in GlobalISel that assume the presence of the variable Subtarget. This patch introduces the variable Subtarget, and replaces all existing uses of PPCSubTarget with Subtarget. A subsequent patch will remove the definiton of PPCSubTarget, once any downstream users have the opportunity to rename any uses they have.
Reviewers: hfinkel, nemanjai, jhibbits, #powerpc, echristo, lkail
Reviewed By: #powerpc, echristo, lkail
Subscribers: echristo, lkail, wuzish, nemanjai, hiraditya, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81623
show more ...
|
| #
1778564f |
| 05-Jun-2020 |
Guillaume Chatelet <[email protected]> |
[Alignment][NFC] Migrate the rest of backends
Summary: This is a followup on D81196
Reviewers: courbet
Subscribers: arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, sbc
[Alignment][NFC] Migrate the rest of backends
Summary: This is a followup on D81196
Reviewers: courbet
Subscribers: arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81278
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc1 |
|
| #
ce4ebc14 |
| 14-May-2020 |
Sean Fertile <[email protected]> |
[PowerPC] Remove support for SplitCSR.
SplitCSR was only suppored for functions with CXX_FAST_TLS calling convention. Clang only emits that calling convention for Darwin which is no longer supported
[PowerPC] Remove support for SplitCSR.
SplitCSR was only suppored for functions with CXX_FAST_TLS calling convention. Clang only emits that calling convention for Darwin which is no longer supported by the PowerPC backend. Another IR producer could use the calling convention, but considering the calling convention is meant to be an optimization and the codegen for SplitCSR can be attrocious on Power (see the modifed lit test) it is best to remove it and codegen CXX_FAST_TLS same as the C calling convention.
Differential Revision: https://reviews.llvm.org/D79018
show more ...
|
| #
8c72b027 |
| 12-May-2020 |
Craig Topper <[email protected]> |
[CodeGen] Use Align in MachineConstantPool.
|
| #
c9d5c195 |
| 31-Mar-2020 |
Guillaume Chatelet <[email protected]> |
[Alignment][NFC] Transitionning more getMachineMemOperand call sites
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pip
[Alignment][NFC] Transitionning more getMachineMemOperand call sites
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: arsenm, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, jrtc27, atanasyan, Jim, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77121
show more ...
|
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
e065e5f1 |
| 20-Sep-2019 |
Jinsong Ji <[email protected]> |
[NFC][PowerPC] Refactor classifyGlobalReference
We always(and only) check the NLP flag after calling classifyGlobalReference to see whether it is accessed indirectly.
Refactor to code to use isGVIn
[NFC][PowerPC] Refactor classifyGlobalReference
We always(and only) check the NLP flag after calling classifyGlobalReference to see whether it is accessed indirectly.
Refactor to code to use isGVIndirectSym instead.
llvm-svn: 372417
show more ...
|
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5 |
|
| #
36e04d14 |
| 12-Sep-2019 |
Craig Topper <[email protected]> |
[PowerPC] Remove the SPE4RC register class and instead add f32 to the GPRC register class.
Summary: Since the SPE4RC register class contains an identical set of registers and an identical spill size
[PowerPC] Remove the SPE4RC register class and instead add f32 to the GPRC register class.
Summary: Since the SPE4RC register class contains an identical set of registers and an identical spill size to the GPRC class its slightly confusing the tablegen emitter. It's preventing the GPRC_and_GPRC_NOR0 synthesized register class from inheriting VTs and AltOrders from GPRC or GPRC_NOR0. This is because SPE4C is found first in the super register class list when inheriting these properties and it doesn't set the VTs or AltOrders the same way as GPRC or GPRC_NOR0.
This patch replaces all uses of GPE4RC with GPRC and allows GPRC and GPRC_NOR0 to contain f32.
The test changes here are because the AltOrders are being inherited to GPRC_NOR0 now.
Found while trying to determine if getCommonSubClass needs to take a VT argument. It was originally added to support fp128 on x86-64, I've changed some things about that so that it might be needed anymore. But a PowerPC test crashed without it and I think its due to this subclass issue.
Reviewers: jhibbits, nemanjai, kbarton, hfinkel
Subscribers: wuzish, nemanjai, mehdi_amini, hiraditya, kbarton, MaskRay, dexonsmith, jsji, shchenz, steven.zhang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67513
llvm-svn: 371779
show more ...
|
|
Revision tags: llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3 |
|
| #
5f85a7b1 |
| 22-Aug-2019 |
Sean Fertile <[email protected]> |
[PowerPC] Add combined ELF ABI and 32/64 bit queries to the subtarget. [NFC]
A lot of places in the code combine checks for both ABI (SVR4/Darwin/AIX) and addressing mode (64-bit vs 32-bit). In an a
[PowerPC] Add combined ELF ABI and 32/64 bit queries to the subtarget. [NFC]
A lot of places in the code combine checks for both ABI (SVR4/Darwin/AIX) and addressing mode (64-bit vs 32-bit). In an attempt to make some of the code more readable I've added a couple functions that combine checking for the ELF abi and 64-bit/32-bit code at once. As we add more AIX support I intend to add similar functions for the AIX ABI.
Differential Revision: https://reviews.llvm.org/D65814
llvm-svn: 369658
show more ...
|
| #
0c476111 |
| 15-Aug-2019 |
Daniel Sanders <[email protected]> |
Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVM
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Re
Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVM
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible).
Partial reverts in: X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned& MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register PPCFastISel.cpp - No Register::operator-=() PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned& MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor
Manual fixups in: ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned& HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register. PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned&
Depends on D65919
Reviewers: arsenm, bogner, craig.topper, RKSimon
Reviewed By: arsenm
Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65962
llvm-svn: 369041
show more ...
|
|
Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1 |
|
| #
8dd563ef |
| 22-Jul-2019 |
Jason Liu <[email protected]> |
[NFC][PowerPC]Change ADDIStocHA to ADDIStocHA8 to follow 64-bit naming convention
Summary:
Since we are planning to add ADDIStocHA for 32bit in later patch, we decided to change 64bit one first to
[NFC][PowerPC]Change ADDIStocHA to ADDIStocHA8 to follow 64-bit naming convention
Summary:
Since we are planning to add ADDIStocHA for 32bit in later patch, we decided to change 64bit one first to follow naming convention with 8 behind opcode.
Patch by: Xiangling_L
Differential Revision: https://reviews.llvm.org/D64814
llvm-svn: 366731
show more ...
|
|
Revision tags: llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2 |
|
| #
60ec2481 |
| 06-Jun-2019 |
Jason Liu <[email protected]> |
[AIX] Implement function descriptor on SDAG
Summary: (1) Function descriptor on AIX On AIX, a called routine may have 2 distinct symbols associated with it: * A function descriptor (Name) * A func
[AIX] Implement function descriptor on SDAG
Summary: (1) Function descriptor on AIX On AIX, a called routine may have 2 distinct symbols associated with it: * A function descriptor (Name) * A function entry point (.Name)
The descriptor structure on AIX is the same as those in the ELF V1 ABI: * The address of the entry point of the function. * The TOC base address for the function. * The environment pointer.
The descriptor symbol uses the same name as the source level function in C. The function entry point is analogous to the symbol we would generate for a function in a non-descriptor-based ABI, except that it is renamed by prepending a ".".
Which symbol gets referenced depends on the context: * Taking the address of the function references the descriptor symbol. * Calling the function references the entry point symbol.
(2) Speaking of implementation on AIX, for direct function call target, we create proper MCSymbol SDNode(e.g . ".foo") while constructing SDAG to replace original TargetGlobalAddress SDNode. Then down the path, we can take advantage of this MCSymbol.
Patch by: Xiangling_L
Reviewed by: sfertile, hubert.reinterpretcast, jasonliu, syzaara
Differential Revision: https://reviews.llvm.org/D62532
llvm-svn: 362735
show more ...
|
|
Revision tags: llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3 |
|
| #
4faa4090 |
| 25-Feb-2019 |
Kang Zhang <[email protected]> |
[PowerPC] [PowerPC] Enhance the fast selection of fptoi & fptrunc instruction and clean up related asserts
Summary: Fast selection of llvm fptoi & fptrunc instructions is not handled well about VSX
[PowerPC] [PowerPC] Enhance the fast selection of fptoi & fptrunc instruction and clean up related asserts
Summary: Fast selection of llvm fptoi & fptrunc instructions is not handled well about VSX instruction support. We'd use VSX float convert integer instruction instead of non-vsx float convert integer instruction if the operand register class is VSSRC or VSFRC because i32 and i64 are mapped to VSSRC and VSFRC correspondingly if VSX feature is openeded. For float trunc instruction, we do this silimar work like float convert integer instruction to try to use VSX instruction.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D58430
llvm-svn: 354762
show more ...
|