summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* [Pipeliner] Use std::stable_sort when ordering NodeSetsKrzysztof Parzyszek2018-04-121-1/+1
| | | | | | | | | | | There are cases when individual NodeSets can be equal with respect to the ordering criteria. Since they are stored in an ordered container, use stable_sort to preserve the relative order of equal NodeSets. This should remove non-determinism discovered by shuffling done in llvm::sort with expensive checks enabled. llvm-svn: 329915
* [CodeGen] Allow printing MachineMemOperands with less context in SDAGDumperFrancis Visoiu Mistrih2018-04-121-8/+21
| | | | | | | | | Don't assume SelectionDAG is non-null as the targets can use it with a null pointer. Differential Revision: https://reviews.llvm.org/D44611 llvm-svn: 329908
* [MachineScheduler] NFC refactoringJonas Paulsson2018-04-121-21/+25
| | | | | | | | | | | | | | | | This patch makes tryCandidate() virtual and some utility functions like tryLess(), tryGreater(), ... externally available (used to be static). This makes it possible for a target to derive a new MachineSchedStrategy from GenericScheduler and reuse most parts. It was necessary to wrap functions with the same names in AMDGPU/SIMachineScheduler in a local namespace. Review: Andy Trick, Florian Hahn https://reviews.llvm.org/D43329 llvm-svn: 329884
* [LegalizeTypes] Remove unnecessary type action check on the type of operand ↵Craig Topper2018-04-121-11/+5
| | | | | | | | 0 when promoting shift result type. NFC Operand 0 should have the same type of the result. So if the result type needs to be promoted, operand 0 needs to be promoted unconditionally. llvm-svn: 329883
* [NFC] fix trivial typos in documents and commentsHiroshi Inoue2018-04-121-1/+1
| | | | | | "is is" -> "is", "if if" -> "if", "or or" -> "or" llvm-svn: 329878
* CodeGen: Don't try to canonicalize Unix-style paths in CodeView debug info.Peter Collingbourne2018-04-111-0/+10
| | | | | | | | | Most importantly, we should not replace slashes with backslashes because that would invalidate the path. Differential Revision: https://reviews.llvm.org/D45473 llvm-svn: 329838
* [FastISel] Disable local value sinking by defaultReid Kleckner2018-04-111-1/+8
| | | | | | | | | | | | | | | | | | This is causing compilation timeouts on code with long sequences of local values and calls (i.e. foo(1); foo(2); foo(3); ...). It turns out that code coverage instrumentation is a great way to create sequences like this, which how our users ran into the issue in practice. Intel has a tool that detects these kinds of non-linear compile time issues, and Andy Kaylor reported it as PR37010. The current sinking code scans the whole basic block once per local value sink, which happens before emitting each call. In theory, local values should only be introduced to be used by instructions between the current flush point and the last flush point, so we should only need to scan those instructions. llvm-svn: 329822
* [MachO] Emit Weak ReadOnlyWithRel to ConstDataSectionSteven Wu2018-04-101-0/+2
| | | | | | | | | | | | | | | | | Summary: Darwin dynamic linker can handle weak symbols in ConstDataSection. ReadonReadOnlyWithRel symbols should be emitted in ConstDataSection instead of normal DataSection. rdar://problem/39298457 Reviewers: dexonsmith, kledzik Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45472 llvm-svn: 329752
* [CodeGen] Fix printing bundles in MIR outputKrzysztof Parzyszek2018-04-102-4/+7
| | | | | | | | | | | | | | | | Delay printing the newline until after the opening bracket was printed, e.g. BUNDLE implicit-def $r1, implicit-def $r21, implicit $r1 { renamable $r1 = S2_asr_i_r renamable $r1, 1 renamable $r21 = A2_tfrsi 0 } instead of BUNDLE implicit-def $r1, implicit-def $r21, implicit $r1 { renamable $r1 = S2_asr_i_r renamable $r1, 1 renamable $r21 = A2_tfrsi 0 } llvm-svn: 329719
* [CodeGen/Dwarf] Rename the "sizetype" synthetic type and add it to the ↵Pavel Labath2018-04-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | accelerator table Summary: This type is created on-demand and used as the base type for array ranges. Since it is "special", its construction did not go through the createTypeDIE function and so it was never inserted into the accelerator table, although it clearly belongs there. I add an explicit addAccelType call to insert it into the table. During review, we also decided to rename the type to something more unique to avoid confusion in case the user has own "sizetype" type. The new name for the type size __ARRAY_SIZE_TYPE__. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45445 llvm-svn: 329705
* [x86] Introduce a pass to begin more systematically fixing PR36028 and ↵Chandler Carruth2018-04-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | similar issues. The key idea is to lower COPY nodes populating EFLAGS by scanning the uses of EFLAGS and introducing dedicated code to preserve the necessary state in a GPR. In the vast majority of cases, these uses are cmovCC and jCC instructions. For such cases, we can very easily save and restore the necessary information by simply inserting a setCC into a GPR where the original flags are live, and then testing that GPR directly to feed the cmov or conditional branch. However, things are a bit more tricky if arithmetic is using the flags. This patch handles the vast majority of cases that seem to come up in practice: adc, adcx, adox, rcl, and rcr; all without taking advantage of partially preserved EFLAGS as LLVM doesn't currently model that at all. There are a large number of operations that techinaclly observe EFLAGS currently but shouldn't in this case -- they typically are using DF. Currently, they will not be handled by this approach. However, I have never seen this issue come up in practice. It is already pretty rare to have these patterns come up in practical code with LLVM. I had to resort to writing MIR tests to cover most of the logic in this pass already. I suspect even with its current amount of coverage of arithmetic users of EFLAGS it will be a significant improvement over the current use of pushf/popf. It will also produce substantially faster code in most of the common patterns. This patch also removes all of the old lowering for EFLAGS copies, and the hack that forced us to use a frame pointer when EFLAGS copies were found anywhere in a function so that the dynamic stack adjustment wasn't a problem. None of this is needed as we now lower all of these copies directly in MI and without require stack adjustments. Lots of thanks to Reid who came up with several aspects of this approach, and Craig who helped me work out a couple of things tripping me up while working on this. Differential Revision: https://reviews.llvm.org/D45146 llvm-svn: 329657
* [globalisel][legalizerinfo] Add support for the Lower action in ↵Daniel Sanders2018-04-092-0/+8
| | | | | | | | | | | | | | | getActionDefinitionsBuilder() and use it in AArch64. Lower is slightly odd. It often doesn't change the type but the lowerings do use the new type to decide what code to create. Treat it like a mutation but provide convenience functions that re-use the existing type. Re-uses the existing tests: test/CodeGen/AArch64/GlobalISel/legalize-rem.mir test/CodeGen/AArch64/GlobalISel//legalize-mul.mir test/CodeGen/AArch64/GlobalISel//legalize-cmpxchg-with-success.mir llvm-svn: 329623
* Fix printing of stack id in MachineFrameInfoMatt Arsenault2018-04-091-1/+1
| | | | | | | uint8_t is printed as a char, so it needs to be casted to do the right thing. llvm-svn: 329622
* [Debuginfo][COFF] Minimal serialization support for precompiled types recordsAlexandre Ganea2018-04-092-2/+3
| | | | | | | | | | | | | This change adds support for the LF_PRECOMP and LF_ENDPRECOMP records required to read/write Microsoft precompiled types .objs. See https://en.wikipedia.org/wiki/Precompiled_header#Microsoft_Visual_C_and_C++ This also adds handling for the .debug$P section, which is actually a .debug$T section in disguise, found only in precompiled .objs. Differential Revision: https://reviews.llvm.org/D45283 llvm-svn: 329613
* Fix type mismatch between MachineMemOperand constructor and accessors. NFCDaniel Sanders2018-04-091-1/+1
| | | | | | | | This allows MachineMemOperand::getSize()'s result to be fed directly into MachineMemOperand::MachineMemOperand() without a narrowing type conversion warning. llvm-svn: 329602
* [GISel] Refactor MachineIRBuilder to allow transformations whileAditya Nandakumar2018-04-091-257/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | building. https://reviews.llvm.org/D45067 This change attempts to do two things: 1) It separates out the state that is stored in the MachineIRBuilder(InsertionPt, MF, MRI, InsertFunction etc) into a separate object called MachineIRBuilderState. 2) Add the ability to constant fold operations while building instructions (optionally). MachineIRBuilder is now refactored into a MachineIRBuilderBase which contains lots of non foldable build methods and their implementation. Instructions which can be constant folded/transformed are now in a class called FoldableInstructionBuilder which uses CRTP to use the implementation of the derived class for buildBinaryOps. Additionally buildInstr in the derived class can be used to implement other kinds of transformations. Also because of separation of state, given a MachineIRBuilder in an API, if one wishes to use another MachineIRBuilder, a new one can be constructed from the state locally. For eg, void doFoo(MachineIRBuilder &B) { MyCustomBuilder CustomB(B.getState()); // Use CustomB for building. } reviewed by : aemerson llvm-svn: 329596
* Support generic expansion of ordered vector reduction (PR36732)Simon Pilgrim2018-04-091-6/+9
| | | | | | | | | | Without the fast math flags, the llvm.experimental.vector.reduce.fadd/fmul intrinsic expansions must be expanded in order. This patch scalarizes the reduction, applying the accumulator at the start of the sequence: ((((Acc + Scl[0]) + Scl[1]) + Scl[2]) + ) ... + Scl[NumElts-1] Differential Revision: https://reviews.llvm.org/D45366 llvm-svn: 329585
* [MachineLICM] Re-enable hoisting of constant storesZaara Syeda2018-04-091-2/+9
| | | | | | | | | | | | This patch fixes an issue exposed on the SystemZ build bots when committing https://reviews.llvm.org/rL327856. The hoisting was temporarily disabled with an option. This patch now re-enables hoisting and checks that we only hoist a store instruction when all its operands are either constant caller preserved registers or immediates. Differential Revision: https://reviews.llvm.org/D45286 llvm-svn: 329577
* [CodeGen/AccelTable] Don't emit zero-CU name indexesPavel Labath2018-04-092-0/+6
| | | | | | | | | | | | | | | | | Summary: If an input DICompileUnit is completely empty (e.g., the result of running "clang -g" on an empty file), we don't bother emitting an empty DWARF CU. When we do that, we must make sure we don't also emit a DWARF v5 name index, as DWARF specifies that each index must reference at least one compilation unit. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45435 llvm-svn: 329575
* [CodeGen/AccelTable]: Don't emit accelerator entries for functions with no namesPavel Labath2018-04-091-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were emitting accelerator entries for functions with no name, which is contrary to the DWARF v5 spec: "All other (i.e., *not* DW_TAG_namespace) debugging information entries without a DW_AT_name attribute are excluded." Besides that, a name table entry with an empty string as a key is fairly useless. We can sometimes end up with functions which have a DW_AT_linkage_name but no DW_AT_name. One such example is the global-constructor-initialization functions, which C++ compilers synthesize for each compilation unit with global constructors. A very strict reading of the DWARF v5 spec would suggest that we should not even emit the accelerator entry for the linkage name in this case, but I don't think we should go that far. I found this when running the dwarf verifier over llvm codebase compiled with DWARF v5 accelerator tables. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: vleschuk, clayborg, echristo, probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D45367 llvm-svn: 329552
* [DAGCombine] Improve ReduceLoad for SRLSam Parker2018-04-091-4/+34
| | | | | | | | | | | | | Recommitting r329283, third time lucky... If the SRL node is only used by an AND, we may be able to set the ExtVT to the width of the mask, making the AND redundant. To support this, another check has been added in isLegalNarrowLoad which queries whether the load is valid. Differential Revision: https://reviews.llvm.org/D41350 llvm-svn: 329551
* Remove MachineLoopInfo dependency from AsmPrinter.Michael Zolotukhin2018-04-091-7/+24
| | | | | | | | | | | | | | | | | | | Summary: Currently MachineLoopInfo is used in only two places: 1) for computing IsBasicBlockInsideInnermostLoop field of MCCodePaddingContext, and it is never used. 2) in emitBasicBlockLoopComments, which is called only if `isVerbose()` is true. Despite that, we currently have a dependency on MachineLoopInfo, which makes pass manager to compute it and MachineDominator Tree. This patch removes the use (1) and makes the use (2) lazy, thus avoiding some redundant recomputations. Reviewers: opaparo, gadi.haber, rafael, craig.topper, zvi Subscribers: rengolin, javed.absar, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D44812 llvm-svn: 329542
* [TargetSchedule] shrink interface for init(); NFCISanjay Patel2018-04-087-13/+11
| | | | | | | | | | The TargetSchedModel is always initialized using the TargetSubtargetInfo's MCSchedModel and TargetInstrInfo, so we don't need to extract those and pass 3 parameters to init(). Differential Revision: https://reviews.llvm.org/D44789 llvm-svn: 329540
* DAGCombiner: Combine SDIV with non-splat vector pow2 divisorZvi Rackover2018-04-081-28/+64
| | | | | | | | | | | | | | | | Summary: Extend existing SDIV combine for pow2 constant divider to handle non-splat vectors of pow2 constants. Reviewers: RKSimon, craig.topper, spatel, hfinkel, efriedma Reviewed By: RKSimon Subscribers: magabari, llvm-commits Differential Revision: https://reviews.llvm.org/D42479 llvm-svn: 329525
* [DAGCombiner] Fold (zext (and/or/xor (shl/shr (load x), cst), cst))Guozhi Wei2018-04-071-0/+78
| | | | | | | | | | | | | | In our real world application, we found the following optimization is missed in DAGCombiner (zext (and/or/xor (shl/shr (load x), cst), cst)) -> (and/or/xor (shl/shr (zextload x), (zext cst)), (zext cst)) If the user of original zext is an add, it may enable further lea optimization on x86. This patch add a new function CombineZExtLogicopShiftLoad to do this optimization. Differential Revision: https://reviews.llvm.org/D44402 llvm-svn: 329516
* [DAGCombiner] Add a combine to turn a build vector of zero extends of ↵Craig Topper2018-04-071-0/+52
| | | | | | extract vector elts into a vector zero extend and possibly an extract subvector. llvm-svn: 329509
* Reapply ARM: Do not spill CSR to stack on entry to noreturn functionsTim Northover2018-04-071-0/+20
| | | | | | | | | | | | | | | | | | Should fix UBSan bot by also checking there's no "uwtable" attribute before skipping. Otherwise the unwind table will be useless since its moves expect CSRs to actually be preserved. A noreturn nounwind function can be expected to never return in any way, and by never returning it will also never have to restore any callee-saved registers for its caller. This makes it possible to skip spills of those registers during function entry, saving some stack space and time in the process. This is rather useful for embedded targets with limited stack space. Should fix PR9970. Patch mostly by myeisha (pmb). llvm-svn: 329494
* Revert "ARM: Do not spill CSR to stack on entry to noreturn functions"Vitaly Buka2018-04-071-18/+0
| | | | | | | | Breaks ubsan test TestCases/Misc/missing_return.cpp on ARM This reverts commit r329287 llvm-svn: 329486
* [StackProtector] Ignore certain intrinsics when calculating sspstrong heuristic.Matt Davis2018-04-061-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The 'strong' StackProtector heuristic takes into consideration call instructions. Certain intrinsics, such as lifetime.start, can cause the StackProtector to protect functions that do not need to be protected. Specifically, a volatile variable, (not optimized away), but belonging to a stack allocation will encourage a llvm.lifetime.start to be inserted during compilation. Because that intrinsic is a 'call' the strong StackProtector will see that the alloca'd variable is being passed to a call instruction, and insert a stack protector. In this case the intrinsic isn't really lowered to a call. This can cause unnecessary stack checking, at the cost of additional (wasted) CPU cycles. In the future we should rely on TargetTransformInfo::isLoweredToCall, but as of now that routine considers all intrinsics as not being lowerable. That needs to be corrected, and such a change is on my list of things to get moving on. As a side note, the updated stack-protector-dbginfo.ll test always seems to pass. I never see the dbg.declare/dbg.value reaching the StackProtector::HasAddressTaken, but I don't see any code excluding dbg intrinsic calls either, so I think it's the safest thing to do. Reviewers: void, timshen Reviewed By: timshen Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45331 llvm-svn: 329450
* [CodeGen] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-0620-76/+79
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: bogner, rnk, MatzeB, RKSimon Reviewed By: rnk Subscribers: JDevlieghere, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D45133 llvm-svn: 329435
* [MIR] Add support for MachineFrameInfo::LocalFrameSizeFrancis Visoiu Mistrih2018-04-062-0/+2
| | | | | | | | | | MFI.LocalFrameSize was not serialized. It is usually set from LocalStackSlotAllocation, so if that pass doesn't run it is impossible do deduce it from the stack objects. Until now, this information was lost. llvm-svn: 329382
* ARM: Do not spill CSR to stack on entry to noreturn functionsTim Northover2018-04-051-0/+18
| | | | | | | | | | | | | | A noreturn nounwind function can be expected to never return in any way, and by never returning it will also never have to restore any callee-saved registers for its caller. This makes it possible to skip spills of those registers during function entry, saving some stack space and time in the process. This is rather useful for embedded targets with limited stack space. Should fix PR9970. Patch by myeisha (pmb). llvm-svn: 329287
* [DAGCombine] Revert r329160Sam Parker2018-04-051-26/+0
| | | | | | Again, broke the big endian stage 2 builders. llvm-svn: 329283
* [MIR-Canon] Fixing warnings in Non-assert builds.Puyan Lotfi2018-04-051-2/+2
| | | | llvm-svn: 329258
* [MIR-Canon] Improving performance by switching to named vregs.Puyan Lotfi2018-04-051-62/+61
| | | | | | No more skipping thounsands of vregs. Much faster running time. llvm-svn: 329246
* [MIR-Canon] Adding support for multi-def -> user distance reduction.Puyan Lotfi2018-04-051-0/+17
| | | | llvm-svn: 329243
* [MachineOutliner] Add `useMachineOutliner` target hookJessica Paquette2018-04-041-1/+9
| | | | | | | | | | | | | The MachineOutliner has a bunch of target hooks that will call llvm_unreachable if the target doesn't implement them. Therefore, if you enable the outliner on such a target, it'll just crash. It'd be much better if it'd just *not* run the outliner at all in this case. This commit adds a hook to TargetInstrInfo that returns false by default. Targets that implement the hook make it return true. The outliner checks the return value of this hook to decide whether or not to continue. llvm-svn: 329220
* Fix build breakage from r329201Pavel Labath2018-04-042-5/+5
| | | | | | | | | Some compilers do not like having an enum type and a variable with the same name (AccelTableKind). I rename the variable to TheAccelTableKind. Suggestions for a better name welcome. llvm-svn: 329202
* Re-commit r329179 after fixing build&test issuesPavel Labath2018-04-043-25/+332
| | | | | | | | | | | - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
* Revert r329179 (and follow-up unsuccessful fix attempts 329184, 329186); it ↵Nico Weber2018-04-043-332/+25
| | | | | | doesn't build. llvm-svn: 329190
* Attempt to fix bots more after r329179.Nico Weber2018-04-041-1/+1
| | | | llvm-svn: 329186
* Attempt to fix bots after r329179.Nico Weber2018-04-041-2/+2
| | | | llvm-svn: 329184
* [CodeGen] Generate DWARF v5 Accelerator TablesPavel Labath2018-04-043-25/+332
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a DwarfAccelTableEmitter class, which generates an accelerator table, as specified in DWARF v5 standard. At the moment it only generates a DIE offset column and (if we are indexing more than one compile unit) a CU column. Indexing type units is not currently supported, as we don't even have the ability to generate DWARF v5-compatible compile units. The implementation is not data-source agnostic like the one generating apple tables. This was not necessary as we currently only have one user of this code, and without a second user it was not obvious to me how to best abstract this. (The difference between these tables and the apple ones is that they need a lot more metadata about the debug info they are indexing). The generation is triggered by the --accel-tables argument, which supersedes the --dwarf-accel-tables arg -- the latter was a simple on-off switch, but not we can choose between two kinds of accelerator tables we can generate. This is tested by parsing the generated tables with llvm-dwarfdump and the DWARFVerifier, and I've also checked that GNU readelf is able to make sense of the tables. Differential Revision: https://reviews.llvm.org/D43286 llvm-svn: 329179
* [DAGCombine] Improve ReduceLoadWidth for SRLSam Parker2018-04-041-0/+26
| | | | | | | | | | | | | | | | | | Recommitting rL321259. Previosuly this caused an issue with PPCBE but I didn't receieve a reproducer and didn't have the time to follow up. If the issue appears again, please provide a reproducer so I can fix it. Original commit message: If the SRL node is only used by an AND, we may be able to set the ExtVT to the width of the mask, making the AND redundant. To support this, another check has been added in isLegalNarrowLoad which queries whether the load is valid. Differential Revision: https://reviews.llvm.org/D41350 llvm-svn: 329160
* [MachineOutliner][NFC] Make outlined functions have internal linkageJessica Paquette2018-04-031-1/+1
| | | | | | | | | | | | The linkage type on outlined functions was private before. This meant that if you set a breakpoint in an outlined function, the debugger wouldn't be able to give a sane name to the outlined function. This commit changes the linkage type to internal and updates any tests that relied on the prefixes on the names of outlined functions. llvm-svn: 329116
* [CodeGen]Add NoVRegs property on PostRASink and ShrinkWrapJun Bum Lim2018-04-032-0/+10
| | | | | | | | | | | | | | | | | Summary: This change declare that PostRAMachineSinking and ShrinkWrap require NoVRegs property, so now the MachineFunctionPass can enforce this check. These passes are disabled in NVPTX & WebAssembly. Reviewers: dschuff, jlebar, tra, jgravelle-google, MatzeB, sebpop, thegameg, mcrosier Reviewed By: dschuff, thegameg Subscribers: jholewinski, jfb, sbc100, aheejin, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D45183 llvm-svn: 329095
* Adding optional Name parameter to createVirtualRegister and ↵Puyan Lotfi2018-04-031-4/+5
| | | | | | createGenericVirtualRegister. llvm-svn: 329076
* Align stubs for external and common global variables to pointer size.Rafael Espindola2018-04-021-0/+1
| | | | | | | | | This patch fixes PR36885: clang++ generates unaligned stub symbol holding a pointer. Patch by Rahul Chaudhry! llvm-svn: 329030
* [dsymutil] Upstream emitting of papertrail warnings.Jonas Devlieghere2018-04-021-0/+1
| | | | | | | | | | When running dsymutil as part of your build system, it can be desirable for warnings to be part of the end product, rather than just being emitted to the output stream. This patch upstreams that functionality. Differential revision: https://reviews.llvm.org/D44639 llvm-svn: 328965
* [DAGCombine] (float)((int) f) --> ftrunc (PR36617)Sanjay Patel2018-03-311-0/+18
| | | | | | | | | | fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 328921
OpenPOWER on IntegriCloud