summaryrefslogtreecommitdiffstats
path: root/llvm/include
Commit message (Collapse)AuthorAgeFilesLines
* [DebugInfo][NFCI] Split salvageDebugInfo into helper functionsJeremy Morse2019-02-051-0/+12
| | | | | | | | | | | | | | | Some use cases are appearing where salvaging is needed that does not correspond to an instruction being deleted -- for example an instruction being sunk, or a Value not being available in a block being isel'd. Enable more fine grained control over how salavging occurs by splitting the logic into helper functions, separating things that are specific to working on DbgVariableIntrinsics from those specific to interpreting IR and building DIExpressions. Differential Revision: https://reviews.llvm.org/D57696 llvm-svn: 353156
* [CGP] Add support for sinking operands to their users, if they are free.Florian Hahn2019-02-051-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch improves code generation for some AArch64 ACLE intrinsics. It adds support to CGP to duplicate and sink operands to their user, if they can be folded into a target instruction, like zexts and sub into usubl. It adds a TargetLowering hook shouldSinkOperands, which looks at the operands of instructions to see if sinking is profitable. I decided to add a new target hook, as for the sinking to be profitable, at least on AArch64, we have to look at multiple operands of an instruction, instead of looking at the users of a zext for example. The sinking is done in CGP, because it works around an instruction selection limitation. If instruction selection is not limited to a single basic block, this patch should not be needed any longer. Alternatively this could be done in the LoopSink pass, which tries to undo LICM for instructions in blocks that are not executed frequently. Note that we do not force the operands to sink to have a single user, because we duplicate them before sinking. Therefore this is only desirable if they really can be done for free. Additionally we could consider the impact on live ranges later on. This should fix https://bugs.llvm.org/show_bug.cgi?id=40025. As for performance, we have internal code that uses intrinsics and can be speed up by 10% by this change. Reviewers: SjoerdMeijer, t.p.northover, samparker, efriedma, RKSimon, spatel Reviewed By: samparker Differential Revision: https://reviews.llvm.org/D57377 llvm-svn: 353152
* GlobalISel: Consolidate load/store legalizationMatt Arsenault2019-02-051-1/+1
| | | | | | | | | | The fewerElementsVectors implementation for load/stores handles the scalar reduction case just as well, so drop the redundant code in narrowScalar. This also introduces support for narrowing irregular size breakdowns for scalars. llvm-svn: 353125
* GlobalISel: Implement narrowScalar for selectMatt Arsenault2019-02-051-0/+2
| | | | | | | | | | Don't handle vector conditions. I think this can be merged in the future with fewerElementsVectorSelect, although this becomes slightly tricky with a vector condition. llvm-svn: 353122
* GlobalISel: Combine g_extract with g_merge_valuesMatt Arsenault2019-02-041-9/+91
| | | | | | | | | | | | | | Try to use the underlying source registers. This enables legalization in more cases where some irregular operations are widened and others narrowed. This seems to make the test_combines_2 AArch64 test worse, since the MERGE_VALUES has multiple uses. Since this should be required for legalization, a hasOneUse check is probably inappropriate (or maybe should only be used if the merge is legal?). llvm-svn: 353121
* [ADT] Refactor the Windows query functions (NFC)Evandro Menezes2019-02-041-15/+14
| | | | | | Increase reuse in the query functions for Windows. llvm-svn: 353117
* [CodeGen][ARC][SystemZ][WebAssembly] Use MachineInstr::isInlineAsm in more ↵Craig Topper2019-02-041-1/+1
| | | | | | | | | | places instead of just comparing opcode. NFCI I'm looking at adding a second INLINEASM opcode for better modeling asm-goto as a terminator. Using the existing predicate will reduce teh number of places that will need to use the new opcode. llvm-svn: 353095
* [NewPM][MSan] Add Options HandlingPhilip Pfaffe2019-02-041-10/+13
| | | | | | | | | | | | | | Summary: This patch enables passing options to msan via the passes pipeline, e.e., -passes=msan<recover;kernel;track-origins=4>. Reviewers: chandlerc, fedor.sergeev, leonardchan Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57640 llvm-svn: 353090
* [DEBUGINFO] Reposting r352642: Handle restore instructions in LiveDebugValuesWolfgang Pieb2019-02-041-0/+13
| | | | | | | | | | | | | | | | | The LiveDebugValues pass recognizes spills but not restores, which can cause large gaps in location information for some variables, depending on control flow. This patch make LiveDebugValues recognize restores and generate appropriate DBG_VALUE instructions. This patch was posted previously with r352642 and reverted in r352666 due to buildbot errors. A missing return statement was the cause for the failures. Reviewers: aprantl, NicolaPrica Differential Revision: https://reviews.llvm.org/D57271 llvm-svn: 353089
* GlobalISel: Allow constructing SrcOp/DstOp from MachineOperandMatt Arsenault2019-02-041-0/+2
| | | | llvm-svn: 353080
* GlobalISel: Fix parameter name in documentationMatt Arsenault2019-02-041-1/+1
| | | | llvm-svn: 353078
* GlobalISel: Fix CSE handling of buildConstantMatt Arsenault2019-02-041-0/+6
| | | | | | | | | | | | | | | | This fixes two problems with CSE done in buildConstant. First, this would hit an assert when used with a vector result type. Solve this by allowing CSE on the vector elements, but not on the result vector for now. Second, this was also performing the CSE based on the input ConstantInt pointer. The underlying buildConstant could potentially convert the constant depending on the result type, giving in a different ConstantInt*. Stop allowing the APInt and ConstantInt forms from automatically casting to the result type to avoid any similar problems in the future. llvm-svn: 353077
* [WebAssembly] clang-tidy (NFC)Heejin Ahn2019-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes clang-tidy warnings on wasm-only files. The list of checks used is: `-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming,modernize-*` (LLVM's default .clang-tidy list is the same except it does not have `modernize-*`. But I've seen in multiple CLs in LLVM the modernize style was recommended and code was fixed based on the style, so I added it as well.) The common fixes are: - Variable names start with an uppercase letter - Function names start with a lowercase letter - Use `auto` when you use casts so the type is evident - Use inline initialization for class member variables - Use `= default` for empty constructors / destructors - Use `using` in place of `typedef` Reviewers: sbc100, tlively, aardappel Subscribers: dschuff, sunfish, jgravelle-google, yurydelendik, kripken, MatzeB, mgorny, rupprecht, llvm-commits Differential Revision: https://reviews.llvm.org/D57500 llvm-svn: 353075
* Revert "[GlobalISel] Introduce a generic floating point floor opcode, G_FFLOOR"Jessica Paquette2019-02-043-11/+0
| | | | | | | | | This reverts commit b05ecba6d687fcb3078509220c67458bf1d77a2e. Apparently adding floor breaks AMDGPU somehow, so I have to back this out while I look into it. llvm-svn: 353065
* [WebAssembly] Rename relocations from R_WEBASSEMBLY_ to R_WASM_Sam Clegg2019-02-042-22/+22
| | | | | | | | | | | | | | | | See https://github.com/WebAssembly/tool-conventions/pull/95. This is less typing and IMHO more readable, and it also fits with our naming around the binary format which tends to use the short name. e.g. include/llvm/BinaryFormat/Wasm.h tools/llvm-objdump/WasmDump.cpp etc.. Differential Revision: https://reviews.llvm.org/D57611 llvm-svn: 353062
* [WebAssembly] Remove redundant namespaces qualifiers. NFC.Sam Clegg2019-02-041-5/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D57610 llvm-svn: 353060
* [Intrinsic] Unsigned Fixed Point Multiplication IntrinsicLeonard Chan2019-02-044-3/+10
| | | | | | | | | | | | | Add an intrinsic that takes 2 unsigned integers with the scale of them provided as the third argument and performs fixed point multiplication on them. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Differential Revision: https://reviews.llvm.org/D55625 llvm-svn: 353059
* [GlobalISel] Introduce a generic floating point floor opcode, G_FFLOORJessica Paquette2019-02-043-0/+11
| | | | | | | | | This introduces a generic opcode for floating point floor, working towards selecting @llvm.floor. Differential Revision: https://reviews.llvm.org/D57484 llvm-svn: 353057
* [AsmPrinter] Remove hidden flag -print-schedule.Andrea Di Biagio2019-02-046-26/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes hidden codegen flag -print-schedule effectively reverting the logic originally committed as r300311 (https://llvm.org/viewvc/llvm-project?view=revision&revision=300311). Flag -print-schedule was originally introduced by r300311 to address PR32216 (https://bugs.llvm.org/show_bug.cgi?id=32216). That bug was about adding "Better testing of schedule model instruction latencies/throughputs". These days, we can use llvm-mca to test scheduling models. So there is no longer a need for flag -print-schedule in LLVM. The main use case for PR32216 is now addressed by llvm-mca. Flag -print-schedule is mainly used for debugging purposes, and it is only actually used by x86 specific tests. We already have extensive (latency and throughput) tests under "test/tools/llvm-mca" for X86 processor models. That means, most (if not all) existing -print-schedule tests for X86 are redundant. When flag -print-schedule was first added to LLVM, several files had to be modified; a few APIs gained new arguments (see for example method MCAsmStreamer::EmitInstruction), and MCSubtargetInfo/TargetSubtargetInfo gained a couple of getSchedInfoStr() methods. Method getSchedInfoStr() had to originally work for both MCInst and MachineInstr. The original implmentation of getSchedInfoStr() introduced a subtle layering violation (reported as PR37160 and then fixed/worked-around by r330615). In retrospect, that new API could have been designed more optimally. We can always query MCSchedModel to get the latency and throughput. More importantly, the "sched-info" string should not have been generated by the subtarget. Note, r317782 fixed an issue where "print-schedule" didn't work very well in the presence of inline assembly. That commit is also reverted by this change. Differential Revision: https://reviews.llvm.org/D57244 llvm-svn: 353043
* [SelectionDAG] Add a BaseIndexOffset::print() method for debugging.Clement Courbet2019-02-041-0/+3
| | | | llvm-svn: 353028
* [PatternMatch] add special-case uaddo matching for increment-by-one (2nd try)Sanjay Patel2019-02-031-0/+14
| | | | | | | | | | | | | | | | | | | | | | | This is the most important uaddo problem mentioned in PR31754: https://bugs.llvm.org/show_bug.cgi?id=31754 ...but that was overcome in x86 codegen with D57637. That patch also corrects the inc vs. add regressions seen with the previous attempt at this. Still, we want to make this matcher complete, so we can potentially canonicalize the pattern even if it's an 'add 1' operation. Pattern matching, however, shouldn't assume that we have canonicalized IR, so we match 4 commuted variants of uaddo. There's also a test with a crazy type to show that the existing CGP transform based on this matcher is not limited by target legality checks. I'm not sure if the Hexagon diff means the test is no longer testing what it intended to test, but that should be solvable in a follow-up. Differential Revision: https://reviews.llvm.org/D57516 llvm-svn: 352998
* [DA][NewPM] Handle transitive dependencies in the new-pm version of DAPhilip Pfaffe2019-02-031-0/+4
| | | | | | | | | | | | | | | | Summary: The analysis result of DA caches pointers to AA, SCEV, and LI, but it never checks for their invalidation. Fix that. Reviewers: chandlerc, dmgreen, bogner Reviewed By: dmgreen Subscribers: hiraditya, bollu, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D56381 llvm-svn: 352986
* GlobalISel: Implement widenScalar for G_UNMERGE_VALUESMatt Arsenault2019-02-031-0/+4
| | | | | | | | | For the scalar case only. Also move the similar G_MERGE_VALUES handling to a separate function and cleanup to make them look more similar. llvm-svn: 352979
* GlobalISel: Legalization for inttoptr/ptrtointMatt Arsenault2019-02-021-0/+2
| | | | llvm-svn: 352973
* [SDAG] Add SDNode/SDValue getConstantOperandAPInt helper. NFCI.Simon Pilgrim2019-02-021-0/+12
| | | | | | | | We already have the getConstantOperandVal helper which returns a uint64_t, but along comes the fuzzer and inserts a i128 -1 constant or something and the whole thing asserts....... I've updated a few obvious cases, and tried to make use of the const reference where possible, but there's more to do. A number of existing oss-fuzz tickets should be fixed if we start using APInt and perform value clamping where necessary. llvm-svn: 352961
* [WebAssembly] Add codegen support for the import_field attributeDan Gohman2019-02-011-4/+18
| | | | | | | | | This adds the LLVM side of https://reviews.llvm.org/D57602 -- the import_field attribute. See that patch for details. Differential Revision: https://reviews.llvm.org/D57603 llvm-svn: 352931
* [COFF, ARM64] Fix localaddress to handle stack realignment and variable size ↵Mandeep Singh Grang2019-02-012-4/+11
| | | | | | | | | | | | | | | | objects Summary: This fixes using the correct stack registers for SEH when stack realignment is needed or when variable size objects are present. Reviewers: rnk, efriedma, ssijaric, TomTan Reviewed By: rnk, efriedma Subscribers: javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D57183 llvm-svn: 352923
* [opaque pointer types] Pass function type for CallBase::setCalledFunction.James Y Knight2019-02-012-5/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D57174 llvm-svn: 352914
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-011-1/+1
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* Fix a bug in the definition of isUnordered on MachineMemOperandPhilip Reames2019-02-011-7/+7
| | | | | | | | | | Background: At the moment, we record the AtomicOrdering of an access in the MMO, but also mark any atomic access as volatile in SelectionDAG. GlobalISEL keeps the two separate, but currently doesn't know how to lower an atomic G_LOAD at all. See https://reviews.llvm.org/D57601 for context. The definition used for unordered was only checking volatility, not atomicity. As noted above, all atomic MMOs are currently also volatile, so this is a latent bug only. Copy the definition used in IR, after auditing the two (2) uses of the function to be sure the desired semantics are the same. Differential Revision: https://reviews.llvm.org/D57593 llvm-svn: 352898
* [SDAG] improve variable names; NFCSanjay Patel2019-02-011-3/+3
| | | | | | | | The version of FoldConstantArithmetic() that takes arbitrary nodes was confusingly naming those nodes as constants when they might not be; also "Cst" reads like "Cast". llvm-svn: 352884
* Provide reason messages for unviable inliningYevgeny Rouban2019-02-011-1/+1
| | | | | | | | | | | | | InlineCost's isInlineViable() is changed to return InlineResult instead of bool. This provides messages for failure reasons and allows to get more specific messages for cases where callsites are not viable for inlining. Reviewed By: xbolva00, anemet Differential Revision: https://reviews.llvm.org/D57089 llvm-svn: 352849
* [SelectionDAG] Support promotion of the FPOWI integer operandAlex Bradbury2019-02-011-1/+3
| | | | | | | | | | | | | | For targets where i32 is not a legal type (e.g. 64-bit RISC-V), LegalizeIntegerTypes must promote the integer operand of ISD::FPOWI. As this is a signed value, this should be sign-extended. This patch enables all tests in test/CodeGen/RISCVfloat-intrinsics.ll for RV64, as prior to this patch that file couldn't be compiled for RV64 due to an assertion when performing codegen for fpowi. Differential Revision: https://reviews.llvm.org/D54574 llvm-svn: 352832
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-017-62/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Fixed hasLinkerPrivateGlobalPrefix treating StringRef as C String.Wouter van Oortmerssen2019-01-311-1/+1
| | | | | | | | | | Reviewers: jgravelle-google, sbc100 Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D57545 llvm-svn: 352810
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-317-114/+62
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* Fix compilation error with GCC after r352791.James Y Knight2019-01-311-1/+1
| | | | llvm-svn: 352795
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-317-62/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* [MemorySSA] Extend removeMemoryAccess API to optimize MemoryPhis.Alina Sbirlea2019-01-311-3/+3
| | | | | | | | | | | | | | | | Summary: EarlyCSE needs to optimize MemoryPhis after an access is removed and has special handling for it. This should be handled by MemorySSA instead. The default remains that MemoryPhis are *not* optimized after an access is removed. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D57199 llvm-svn: 352787
* [ELF] Return the section name when calling getSymbolName on a section symbol.Matt Davis2019-01-311-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, llvm-nm would report symbols for .debug and .note sections as: '?' with an empty section name: ``` 00000000 ? 00000000 ? ... ``` With this patch the output more closely resembles GNU nm: ``` 00000000 N .debug_abbrev 00000000 n .note.GNU-stack ... ``` This patch calls `getSectionName` for sections that belong to symbols of type `ELF::STT_SECTION`, which returns the name of the section from the section string table. Reviewers: Bigcheese, davide, jhenderson Reviewed By: davide, jhenderson Subscribers: rupprecht, jhenderson, llvm-commits Differential Revision: https://reviews.llvm.org/D57105 llvm-svn: 352785
* GlobalISel: Fix handling of vectors of pointers in clamp{Min,Max}NumElementsMatt Arsenault2019-01-311-5/+3
| | | | | | This avoids hitting the assert added in r352636 in a future commit. llvm-svn: 352777
* [ADT] Fix a typo in isOSVersionLT that breaks the Micro version checkBob Wilson2019-01-311-1/+1
| | | | | | | | The original commit of this function (r129800 in 2011) had a typo where part of the "Micro" version check was actually comparing against the "Minor" version number. llvm-svn: 352776
* [CallSite removal] Remove CallSite uses from InstCombine.Craig Topper2019-01-311-0/+20
| | | | | | | | | | | | Reviewers: chandlerc Reviewed By: chandlerc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D57494 llvm-svn: 352771
* Recommit "[ThinLTO] Rename COMDATs for COFF when promoting/renaming COMDAT ↵Teresa Johnson2019-01-311-0/+5
| | | | | | | | leader" Recommit of r352763 with fix for use after free. llvm-svn: 352770
* revert r352766: [PatternMatch] add special-case uaddo matching for ↵Sanjay Patel2019-01-311-14/+0
| | | | | | | | increment-by-one Missed some regression test updates when testing this. llvm-svn: 352769
* Revert "[ThinLTO] Rename COMDATs for COFF when promoting/renaming COMDAT leader"Teresa Johnson2019-01-311-5/+0
| | | | | | | | | | | | This reverts commit r352763. Causing a couple bot failures, root cause pointed to by sanitizer bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/28909/steps/annotate/logs/stdio Use after free. I understand the issue but will revert and test with fix before recommitting. llvm-svn: 352768
* [PatternMatch] add special-case uaddo matching for increment-by-oneSanjay Patel2019-01-311-0/+14
| | | | | | | | | | | | | | | | | This is the most important uaddo problem mentioned in PR31754: https://bugs.llvm.org/show_bug.cgi?id=31754 We were failing to match the canonicalized pattern when it's an 'add 1' operation. Pattern matching, however, shouldn't assume that we have canonicalized IR, so we match 4 commuted variants of uaddo. There's also a test with a crazy type to show that the existing CGP transform based on this matcher is not limited by target legality checks, but that's a different problem. Differential Revision: https://reviews.llvm.org/D57516 llvm-svn: 352766
* [ThinLTO] Rename COMDATs for COFF when promoting/renaming COMDAT leaderTeresa Johnson2019-01-311-0/+5
| | | | | | | | | | | | | | | | | | Summary: COFF requires that COMDAT name match that of the leader. When we promote and rename an internal leader in ThinLTO due to an import, ensure we subsequently rename the associated COMDAT. Similar to D31963 which did this during ThinLTO module splitting. Fixes PR40414. Reviewers: pcc, inglorion Subscribers: mehdi_amini, dexonsmith, dmajor, llvm-commits Differential Revision: https://reviews.llvm.org/D57395 llvm-svn: 352763
* Default lowering for experimental.widenable.conditionMax Kazantsev2019-01-313-0/+34
| | | | | | | | | | | Introduces a pass that provides default lowering strategy for the `experimental.widenable.condition` intrinsic, replacing all its uses with `i1 true`. Differential Revision: https://reviews.llvm.org/D56096 Reviewed By: reames llvm-svn: 352739
* [SelectionDAG] Codesize: don't expand SHIFT to SHIFT_PARTSSjoerd Meijer2019-01-311-0/+7
| | | | | | | | | | | | | | | | And instead just generate a libcall. My motivating example on ARM was a simple: shl i64 %A, %B for which the code bloat is quite significant. For other targets that also accept __int128/i128 such as AArch64 and X86, it is also beneficial for these cases to generate a libcall when optimising for minsize. On these 64-bit targets, the 64-bits shifts are of course unaffected because the SHIFT/SHIFT_PARTS lowering operation action is not set to custom/expand. Differential Revision: https://reviews.llvm.org/D57386 llvm-svn: 352736
OpenPOWER on IntegriCloud