summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* [Remarks] Use the RemarkSetup error in setupOptimizationRemarksFrancis Visoiu Mistrih2019-06-141-2/+2
| | | | | | | Added the errors in r363415 but they were not used in the RemarkStreamer. llvm-svn: 363439
* Reland: [Remarks] Refactor optimization remarks setupFrancis Visoiu Mistrih2019-06-141-0/+35
| | | | | | | | * Add a common function to setup opt-remarks * Rename common options to the same names * Add error types to distinguish between file errors and regex errors llvm-svn: 363415
* Revert "[Remarks] Refactor optimization remarks setup"Francis Visoiu Mistrih2019-06-141-35/+0
| | | | | | | | This reverts commit 6e6e3af55bb97e1a4c97375c15a2b0099120c5a7. This breaks greendragon. llvm-svn: 363343
* [Remarks] Refactor optimization remarks setupFrancis Visoiu Mistrih2019-06-131-0/+35
| | | | | | | | * Add a common function to setup opt-remarks * Rename common options to the same names * Add error types to distinguish between file errors and regex errors llvm-svn: 363328
* Improve reduction intrinsics by overloading result value.Sander de Smalen2019-06-132-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch uses the mechanism from D62995 to strengthen the definitions of the reduction intrinsics by letting the scalar result/accumulator type be overloaded from the vector element type. For example: ; The LLVM LangRef specifies that the scalar result must equal the ; vector element type, but this is not checked/enforced by LLVM. declare i32 @llvm.experimental.vector.reduce.or.i32.v4i32(<4 x i32> %a) This patch changes that into: declare i32 @llvm.experimental.vector.reduce.or.v4i32(<4 x i32> %a) Which has the type-constraint more explicit and causes LLVM to check the result type with the vector element type. Reviewers: RKSimon, arsenm, rnk, greened, aemerson Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D62996 llvm-svn: 363240
* [IntrinsicEmitter] Extend argument overloading with forward references.Sander de Smalen2019-06-132-40/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the mechanism to overload intrinsic arguments by using either backward or forward references to the overloadable arguments. In for example: def int_something : Intrinsic<[LLVMPointerToElt<0>], [llvm_anyvector_ty], []>; LLVMPointerToElt<0> is a forward reference to the overloadable operand of type 'llvm_anyvector_ty' and would allow intrinsics such as: declare i32* @llvm.something.v4i32(<4 x i32>); declare i64* @llvm.something.v2i64(<2 x i64>); where the result pointer type is deduced from the element type of the first argument. If the returned pointer is not a pointer to the element type, LLVM will give an error: Intrinsic has incorrect return type! i64* (<4 x i32>)* @llvm.something.v4i32 Reviewers: RKSimon, arsenm, rnk, greened Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D62995 llvm-svn: 363233
* Change semantics of fadd/fmul vector reductions.Sander de Smalen2019-06-112-3/+44
| | | | | | | | | | | | | | | | | | | | This patch changes how LLVM handles the accumulator/start value in the reduction, by never ignoring it regardless of the presence of fast-math flags on callsites. This change introduces the following new intrinsics to replace the existing ones: llvm.experimental.vector.reduce.fadd -> llvm.experimental.vector.reduce.v2.fadd llvm.experimental.vector.reduce.fmul -> llvm.experimental.vector.reduce.v2.fmul and adds functionality to auto-upgrade existing LLVM IR and bitcode. Reviewers: RKSimon, greened, dmgreen, nikic, simoll, aemerson Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D60261 llvm-svn: 363035
* Revert r361953 "[SVE][IR] Scalable Vector IR Type"Nico Weber2019-06-094-77/+9
| | | | | | | This reverts commit f4fc01f8dd3a5dfd2060d1ad0df6b90e8351ddf7. It caused a 3-4x slowdown when doing thinlto links, PR42210. llvm-svn: 362913
* IR: make getParamByValType Just Work. NFC.Tim Northover2019-06-051-0/+4
| | | | | | | | | | | Most parts of LLVM don't care whether the byval type is derived from an explicit Attribute or from the parameter's pointee type, so it makes sense for the main access function to just return the right value. The very few users who do care (only BitcodeReader so far) can find out how it's specified by accessing the Attribute directly. llvm-svn: 362642
* Introduce Value::stripPointerCastsSameRepresentationJohannes Doerfert2019-06-041-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | This patch allows current users of Value::stripPointerCasts() to force the result of the function to have the same representation as the value it was called on. This is useful in various cases, e.g., (non-)null checks. In this patch only a single call site was adjusted to fix an existing misuse that would cause nonnull where they may be wrong. Uses in attribute deduction and other areas, e.g., D60047, are to be expected. For a discussion on this topic, please see [0]. [0] http://lists.llvm.org/pipermail/llvm-dev/2018-December/128423.html Reviewers: hfinkel, arsenm, reames Subscribers: wdng, hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61607 llvm-svn: 362545
* Silenced a warning "implicit conversion turns string literal into bool" ↵Dmitri Gribenko2019-06-041-2/+3
| | | | | | introduced in r362473 llvm-svn: 362480
* Make SwitchInstProfUpdateWrapper saferYevgeny Rouban2019-06-041-18/+39
| | | | | | | | | | | | | | | | | | | | While prof branch_weights inconsistencies are being fixed patch by patch (pass by pass) we need SwitchInstProfUpdateWrapper to be safe with respect to inconsistent metadata that can come from passes that have not been fixed yet. See the bug found by @nikic in https://reviews.llvm.org/D62126. This patch introduces one more state (called Invalid) to the wrapper class that allows users to work with the underlying SwitchInst ignoring the prof metadata changes. Created a unit test for the SwitchInstProfUpdateWrapper class. Reviewers: davidx, nikic, eraman, reames, chandlerc Reviewed By: davidx Differential Revision: https://reviews.llvm.org/D62656 llvm-svn: 362473
* [ConstantRange] Add sdiv() supportNikita Popov2019-06-031-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | The implementation is conceptually simple: We separate the LHS and RHS into positive and negative components and then also compute the positive and negative components of the result, taking into account that e.g. only pos/pos and neg/neg will give a positive result. However, there's one significant complication: SignedMin / -1 is UB for sdiv, and we can't just ignore it, because the APInt result of SignedMin would break the sign segregation. Instead we drop SignedMin or -1 from the corresponding ranges, taking into account some edge cases with wrapped ranges. Because of the sign segregation, the implementation ends up being nearly fully precise even for wrapped ranges (the remaining imprecision is due to ranges that are both signed and unsigned wrapping and are divided by a trivial divisor like 1). This means that the testing cannot just check the signed envelope as we usually do. Instead we collect all possible results in a bitvector and construct a better sign wrapped range (than the full envelope). Differential Revision: https://reviews.llvm.org/D61238 llvm-svn: 362430
* [Remarks][NFC] Move the serialization to lib/RemarksFrancis Visoiu Mistrih2019-05-302-143/+72
| | | | | | | | | | | | Separate the remark serialization to YAML from the LLVM Diagnostics. This adds a new serialization abstraction: remarks::Serializer. It's completely independent from lib/IR and it provides an easy way to replace YAML by providing a new remarks::Serializer. Differential Revision: https://reviews.llvm.org/D62632 llvm-svn: 362160
* Reapply: IR: add optional type to 'byval' function parametersTim Northover2019-05-304-8/+150
| | | | | | | | | | | | | | | | | When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
* Revert "IR: add optional type to 'byval' function parameters"Tim Northover2019-05-294-143/+7
| | | | | | | The IRLinker doesn't delve into the new byval attribute when mapping types, and this breaks LTO. llvm-svn: 362029
* IR: add optional type to 'byval' function parametersTim Northover2019-05-294-7/+143
| | | | | | | | | | | | | | When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362012
* [SVE][IR] Scalable Vector IR TypeGraham Hunter2019-05-294-9/+77
| | | | | | | | | | | | | | | | | | | * Adds a 'scalable' flag to VectorType * Adds an 'ElementCount' class to VectorType to pass (possibly scalable) vector lengths, with overloaded operators. * Modifies existing helper functions to use ElementCount * Adds support for serializing/deserializing to/from both textual and bitcode IR formats * Extends the verifier to reject global variables of scalable types * Updates documentation See the latest version of the RFC here: http://lists.llvm.org/pipermail/llvm-dev/2018-July/124396.html Reviewers: rengolin, lattner, echristo, chandlerc, hfinkel, rkruppe, samparker, SjoerdMeijer, greened, sebpop Reviewed By: hfinkel, sebpop Differential Revision: https://reviews.llvm.org/D32530 llvm-svn: 361953
* Add IR support, ELF section and user documentation for partitioning feature.Peter Collingbourne2019-05-293-0/+43
| | | | | | | | | | | | The partitioning feature was proposed here: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html This is mostly just documentation. The feature itself will be contributed in subsequent patches. Differential Revision: https://reviews.llvm.org/D60242 llvm-svn: 361923
* IR: Give the TypeAllocator a more generic name and start using it for ↵Peter Collingbourne2019-05-293-18/+13
| | | | | | | | section names as well. NFCI. This prepares us to start using it for partition names. llvm-svn: 361922
* [CodeGen] Add lrint/llrint builtinsAdhemerval Zanella2019-05-281-1/+3
| | | | | | | | | | | | | | | | | This patch add the ISD::LRINT and ISD::LLRINT along with new intrinsics. The changes are straightforward as for other floating-point rounding functions, with just some adjustments required to handle the return value being an interger. The idea is to optimize lrint/llrint generation for AArch64 in a subsequent patch. Current semantic is just route it to libm symbol. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D62017 llvm-svn: 361875
* [ValueTracking][ConstantRange] Distinguish low/high always overflowNikita Popov2019-05-281-9/+9
| | | | | | | | | | | | In order to fold an always overflowing signed saturating add/sub, we need to know in which direction the always overflow occurs. This patch splits up AlwaysOverflows into AlwaysOverflowsLow and AlwaysOverflowsHigh to pass through this information (but it is not used yet). Differential Revision: https://reviews.llvm.org/D62463 llvm-svn: 361858
* [IR] Add SaturatingInst and BinaryOpIntrinsic classesNikita Popov2019-05-281-3/+9
| | | | | | | | | | | | | Based on the suggestion in D62447, this adds a SaturatingInst class that represents the saturating add/sub family of intrinsics. It exposes the same interface as WithOverflowInst, for this reason I have also added a common base class BinaryOpIntrinsic that holds the actual implementation code and will be useful in some places handling both overflowing and saturating math. Differential Revision: https://reviews.llvm.org/D62466 llvm-svn: 361857
* [CVP] Remove unnecessary checks for empty GNWR; NFCNikita Popov2019-05-251-2/+1
| | | | | | | | | | The guaranteed no-wrap region is never empty, it always contains at least zero, so these optimizations don't ever apply. To make this more obviously true, replace the conversative return in makeGNWR with an assertion. llvm-svn: 361698
* [NFC] SwitchInst: Introduce wrapper for prof branch_weights handlingYevgeny Rouban2019-05-241-0/+120
| | | | | | | | | | | | | | | This patch introduces a wrapper class that re-implements several mutator methods of SwitchInst to handle changes of prof branch_weights metadata along with remove/add switch case methods. Subsequent patches will use this wrapper to implement prof branch_weights metadata handling for SwitchInst. Reviewers: davidx, eraman, reames, chandlerc Reviewed By: davidx Differential Revision: https://reviews.llvm.org/D62122 llvm-svn: 361596
* [Intrinsic] Signed Fixed Point Saturation Multiplication IntrinsicLeonard Chan2019-05-211-6/+7
| | | | | | | | | | | | | | Add an intrinsic that takes 2 signed integers with the scale of them provided as the third argument and performs fixed point multiplication on them. The result is saturated and clamped between the largest and smallest representable values of the first 2 operands. 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/D55720 llvm-svn: 361289
* [Intrinsics] Merge lround.i32 and lround.i64 into a single intrinsic with ↵Craig Topper2019-05-201-0/+8
| | | | | | | | | | overloaded result type. Make result type for llvm.llround overloaded instead of fixing to i64 We shouldn't really make assumptions about possible sizes for long and long long. And longer term we should probably support vectorizing these intrinsics. By making the result types not fixed we can support vectors as well. Differential Revision: https://reviews.llvm.org/D62026 llvm-svn: 361169
* [DebugInfoMetadata] Refactor DIExpression::prepend constants (NFC)Petar Jovanovic2019-05-201-5/+6
| | | | | | | | | | | Refactor DIExpression::With* into a flag enum in order to be less error-prone to use (as discussed on D60866). Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D61943 llvm-svn: 361137
* Match types of accumulator and result for ↵Sander de Smalen2019-05-201-4/+2
| | | | | | | | | | | | | | | | | llvm.experimental.vector.reduce.fadd/fmul The scalar start/accumulator value of the fadd- and fmul reduction should match the result type of the reduction, as well as the vector element-type of the input vector. Although this was not explicitly specified in the LangRef, it was taken for granted in code implementing the reductions. The patch also fixes the LangRef by adding this constraint. Reviewed By: aemerson, nikic Differential Revision: https://reviews.llvm.org/D60260 llvm-svn: 361133
* [IR] Disallow llvm.global_ctors and llvm.global_dtors of the 2-field form in ↵Fangrui Song2019-05-152-10/+36
| | | | | | | | | | | | | | | | | | | | textual format The 3-field form was introduced by D3499 in 2014 and the legacy 2-field form was planned to be removed in LLVM 4.0 For the textual format, this patch migrates the existing 2-field form to use the 3-field form and deletes the compatibility code. test/Verifier/global-ctors-2.ll checks we have a friendly error message. For bitcode, lib/IR/AutoUpgrade UpgradeGlobalVariables will upgrade the 2-field form (add i8* null as the third field). Reviewed By: rnk, dexonsmith Differential Revision: https://reviews.llvm.org/D61547 llvm-svn: 360742
* Add constrained fptrunc and fpext intrinsics.Kevin P. Neal2019-05-132-0/+45
| | | | | | | | | | | The new fptrunc and fpext intrinsics are constrained versions of the regular fptrunc and fpext instructions. Reviewed by: Andrew Kaylor, Craig Topper, Cameron McInally, Conner Abbot Approved by: Craig Topper Differential Revision: https://reviews.llvm.org/D55897 llvm-svn: 360581
* [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligibleTeresa Johnson2019-05-102-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We hit undefined references building with ThinLTO when one source file contained explicit instantiations of a template method (weak_odr) but there were also implicit instantiations in another file (linkonce_odr), and the latter was the prevailing copy. In this case the symbol was marked hidden when the prevailing linkonce_odr copy was promoted to weak_odr. It led to unsats when the resulting shared library was linked with other code that contained a reference (expecting to be resolved due to the explicit instantiation). Add a CanAutoHide flag to the GV summary to allow the thin link to identify when all copies are eligible for auto-hiding (because they were all originally linkonce_odr global unnamed addr), and only do the auto-hide in that case. Most of the changes here are due to plumbing the new flag through the bitcode and llvm assembly, and resulting test changes. I augmented the existing auto-hide test to check for this situation. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, dexonsmith, arphaman, dang, llvm-commits, steven_wu, wmi Tags: #llvm Differential Revision: https://reviews.llvm.org/D59709 llvm-svn: 360466
* [llvm] Avoid div by 0 when updating profile weights.Mircea Trofin2019-05-081-0/+9
| | | | | | | | | | | | | | Reviewers: davidxl Reviewed By: davidxl Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61661 llvm-svn: 360223
* [ConstantRange] Simplify makeGNWR implementation; NFCNikita Popov2019-05-071-103/+67
| | | | | | | | Compute results in more direct ways, avoid subset intersect operations. Extract the core code for computing mul nowrap ranges into separate static functions, so they can be reused. llvm-svn: 360189
* Debug Info: Support address space attributes on rvalue references.Adrian Prantl2019-05-071-1/+2
| | | | | | | | | | | | | | | | | | | DWARF5, 2.12 20ff says that Any debugging information entry representing a pointer or reference type [may have a DW_AT_address_class attribute]. The existing code (https://reviews.llvm.org/D29670) seems to take a quite literal interpretation of that wording. I don't see a reason why an rvalue reference isn't a reference type in the spirit of that paragraph. This patch allows rvalue references to also have address spaces. rdar://problem/50511483 Differential Revision: https://reviews.llvm.org/D61625 llvm-svn: 360176
* [DebugInfo] Delete TypedDINodeRefFangrui Song2019-05-073-18/+19
| | | | | | | | | | | | | TypedDINodeRef<T> is a redundant wrapper of Metadata * that is actually a T *. Accordingly, change DI{Node,Scope,Type}Ref uses to DI{Node,Scope,Type} * or their const variants. This allows us to delete many resolve() calls that clutter the code. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D61369 llvm-svn: 360108
* [ConstantRange] Add srem() supportNikita Popov2019-05-061-0/+44
| | | | | | | | | | | | | | | Add support for srem() to ConstantRange so we can use it in LVI. For srem the sign of the result matches the sign of the LHS. For the RHS only the absolute value is important. Apart from that the logic is like urem. Just like for urem this is only an approximate implementation. The tests check a few specific cases and run an exhaustive test for conservative correctness (but not exactness). Differential Revision: https://reviews.llvm.org/D61207 llvm-svn: 360055
* [NFC] BasicBlock: generalize replaceSuccessorsPhiUsesWith(), take Old bbRoman Lebedev2019-05-051-7/+10
| | | | | | | | | | Thus it does not assume that the old basic block is the basic block for which we are looking at successors. Not reviewed, but seems rather trivial, in line with the rest of previous few patches. llvm-svn: 359997
* [NFC] BasicBlock: refactor changePhiUses() out of replacePhiUsesWith(), use itRoman Lebedev2019-05-051-17/+17
| | | | | | | | | | | | | | | | | | | | | Summary: It is a common thing to loop over every `PHINode` in some `BasicBlock` and change old `BasicBlock` incoming block to a new `BasicBlock` incoming block. `replaceSuccessorsPhiUsesWith()` already had code to do that, it just wasn't a function. So outline it into a new function, and use it. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61013 llvm-svn: 359996
* [NFC] PHINode: introduce replaceIncomingBlockWith() function, use itRoman Lebedev2019-05-051-10/+3
| | | | | | | | | | | | | | | | | | | | Summary: There is `PHINode::getBasicBlockIndex()`, `PHINode::setIncomingBlock()` and `PHINode::getNumOperands()`, but no function to replace every specified `BasicBlock*` predecessor with some other specified `BasicBlock*`. Clearly, there are a lot of places that could use that functionality. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61011 llvm-svn: 359995
* [NFC] Instruction: introduce replaceSuccessorWith() function, use itRoman Lebedev2019-05-051-0/+7
| | | | | | | | | | | | | | | | | | | | Summary: There is `Instruction::getNumSuccessors()`, `Instruction::getSuccessor()` and `Instruction::setSuccessor()`, but no function to replace every specified `BasicBlock*` successor with some other specified `BasicBlock*`. I've found one place where it should clearly be used. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61010 llvm-svn: 359994
* [Constants] Simplify type checking switch in ConstantExpr::get.Craig Topper2019-05-051-26/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: Remove duplicate checks that both operands have the same type. This is checked before the switch. Use 'integer' or 'floating-point' instead of 'arithmetic' type. I think this might be a leftover to the days when floating point and integer operations shared the same opcodes. Reviewers: spatel, RKSimon, dblaikie Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61558 llvm-svn: 359985
* Add FNeg IR constant folding supportCameron McInally2019-05-053-4/+53
| | | | llvm-svn: 359982
* [COFF, ARM64] Fix ABI implementation of struct returnsMandeep Singh Grang2019-05-031-0/+4
| | | | | | | | | | | | | | | | | | | Summary: Refer the ABI doc at: https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#return-values Related clang patch: D60349 Reviewers: rnk, efriedma, TomTan, ssijaric Reviewed By: rnk, efriedma Subscribers: mstorsjo, javed.absar, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60348 llvm-svn: 359934
* [DebugInfo] DW_OP_deref_size in PrologEpilogInserter.Markus Lavin2019-04-301-0/+15
| | | | | | | | | | | | | | | | | | | | The PrologEpilogInserter need to insert a DW_OP_deref_size before prepending a memory location expression to an already implicit expression to avoid having the existing expression act on the memory address instead of the value behind it. The reason for using DW_OP_deref_size and not plain DW_OP_deref is that big-endian targets need to read the right size as simply truncating a larger read would yield the wrong result (LSB bytes are not at the lower address). This re-commit fixes issues reported in the first one. Namely deref was inserted under wrong conditions and additionally the deref_size argument was incorrectly encoded. Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 359535
* [X86] Remove duplicate string comparisonSimon Pilgrim2019-04-291-1/+0
| | | | | | Fix typo introduced in rL332824 where we simplified the extact string matches for "avx512.mask.permvar.sf.256" and "avx512.mask.permvar.si.256" to a string startswith test for "avx512.mask.permvar." llvm-svn: 359460
* [ConstantRange] Add makeExactNoWrapRegion()Nikita Popov2019-04-281-4/+10
| | | | | | | | | | | | | | | | | | | | | | | I got confused on the terminology, and the change in D60598 was not correct. I was thinking of "exact" in terms of the result being non-approximate. However, the relevant distinction here is whether the result is * Largest range such that: Forall Y in Other: Forall X in Result: X BinOp Y does not wrap. (makeGuaranteedNoWrapRegion) * Smallest range such that: Forall Y in Other: Forall X not in Result: X BinOp Y wraps. (A hypothetical makeAllowedNoWrapRegion) * Both. (makeExactNoWrapRegion) I'm adding a separate makeExactNoWrapRegion method accepting a single APInt (same as makeExactICmpRegion) and using it in the places where the guarantee is relevant. Differential Revision: https://reviews.llvm.org/D60960 llvm-svn: 359402
* [ConstantRange] Add abs() supportNikita Popov2019-04-261-0/+31
| | | | | | | | | | | | | | Add support for abs() to ConstantRange. This will allow to handle SPF_ABS select flavor in LVI and will also come in handy as a primitive for the srem implementation. The implementation is slightly tricky, because a) abs of signed min is signed min and b) sign-wrapped ranges may have an abs() that is smaller than a full range, so we need to explicitly handle them. Differential Revision: https://reviews.llvm.org/D61084 llvm-svn: 359321
* [ConstantRange] [a, b) udiv a full range is [0, umax(b)).Florian Hahn2019-04-251-2/+0
| | | | | | | | | | Reviewers: nikic, spatel, efriedma Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D60536 llvm-svn: 359180
* Add optional arg to profile count getters to filterXinliang David Li2019-04-241-2/+3
| | | | | | | | synthetic profile count. Differential Revision: http://reviews.llvm.org/D61025 llvm-svn: 359131
OpenPOWER on IntegriCloud