summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [LLVM-C] Deprecate the LLVMValueRef-returning metadata creation functionsRobert Widmann2019-04-241-0/+10
| | | | | | | | | | | | | | | | Summary: There is still some value in using these functions while the remaining LLVMValueRef-based accessors are still around, but LLVMMDNodeInContext in particular has some wonky semantics that make it worth replacing outright. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60524 llvm-svn: 359114
* [LLVM-C] Use dyn_cast instead of unwrap in LLVMGetDebugLoc functionswhitequark2019-04-241-15/+21
| | | | | | | | | | | | | | | | | | | | | Summary: The `unwrap<Type>` calls can assert with: ``` Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast ``` so replace them with `dyn_cast`. Reviewers: whitequark, abdulras, hiraditya, compnerd Reviewed By: whitequark Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60473 llvm-svn: 359093
* [Remarks] Add string deduplication using a string tableFrancis Visoiu Mistrih2019-04-243-13/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add support for uniquing strings in the remark streamer and emitting the string table in the remarks section. * Add parsing support for the string table in the RemarkParser. From this remark: ``` --- !Missed Pass: inline Name: NoDefinition DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 7, Column: 3 } Function: printArgsNoRet Args: - Callee: printf - String: ' will not be inlined into ' - Caller: printArgsNoRet DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 6, Column: 0 } - String: ' because its definition is unavailable' ... ``` to: ``` --- !Missed Pass: 0 Name: 1 DebugLoc: { File: 3, Line: 7, Column: 3 } Function: 2 Args: - Callee: 4 - String: 5 - Caller: 2 DebugLoc: { File: 3, Line: 6, Column: 0 } - String: 6 ... ``` And the string table in the .remarks/__remarks section containing: ``` inline\0NoDefinition\0printArgsNoRet\0 test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c\0printf\0 will not be inlined into \0 because its definition is unavailable\0 ``` This is mostly supposed to be used for testing purposes, but it gives us a 2x reduction in the remark size, and is an incremental change for the updates to the remarks file format. Differential Revision: https://reviews.llvm.org/D60227 llvm-svn: 359050
* [ConstantRange] Add urem supportNikita Popov2019-04-231-0/+15
| | | | | | | | | | | | | Add urem support to ConstantRange, so we can handle in in LVI. This is an approximate implementation that tries to capture the most useful conditions: If the LHS is always strictly smaller than the RHS, then the urem is a no-op and the result is the same as the LHS range. Otherwise the lower bound is zero and the upper bound is min(LHSMax, RHSMax - 1). Differential Revision: https://reviews.llvm.org/D60952 llvm-svn: 359019
* Use llvm::stable_sortFangrui Song2019-04-232-7/+2
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* [PGO/SamplePGO][NFC] Move the function updateProfWeight from InstructionWei Mi2019-04-222-43/+44
| | | | | | | | | | | | | | | | | | | | | | to CallInst. The issue was raised here: https://reviews.llvm.org/D60903#1472783 The function Instruction::updateProfWeight is only used for CallInst in profile update. From the current interface, it is very easy to think that the function can also be used for branch instruction. However, Branch instruction does't need the scaling the function provides for branch_weights and VP (value profile), in addition, scaling may introduce inaccuracy for branch probablity. The patch moves the function updateProfWeight from Instruction class to CallInst to remove the confusion. The patch also changes the scaling of branch_weights from a loop to a block because we know that ProfileData for branch_weights of CallInst will only have two operands at most. Differential Revision: https://reviews.llvm.org/D60911 llvm-svn: 358900
* [LLVM-C] Add accessors to the default floating-point metadata nodeRobert Widmann2019-04-221-0/+12
| | | | | | | | | | | | | | | | Summary: Add a getter and setter pair for floating-point accuracy metadata. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60527 llvm-svn: 358883
* Revert "[ConstantRange] Rename make{Guaranteed -> Exact}NoWrapRegion() NFC"Nikita Popov2019-04-221-7/+8
| | | | | | | | | | This reverts commit 7bf4d7c07f2fac862ef34c82ad0fef6513452445. After thinking about this more, this isn't right, the range is not exact in the same sense as makeExactICmpRegion(). This needs a separate function. llvm-svn: 358876
* [ConstantRange] Rename make{Guaranteed -> Exact}NoWrapRegion() NFCNikita Popov2019-04-221-8/+7
| | | | | | | | Following D60632 makeGuaranteedNoWrapRegion() always returns an exact nowrap region. Rename the function accordingly. This is in line with the naming of makeExactICmpRegion(). llvm-svn: 358875
* [ConstantRange] Add saturating add/sub methodsNikita Popov2019-04-211-0/+36
| | | | | | | | | | | | | | | | Add support for uadd_sat and friends to ConstantRange, so we can handle uadd.sat and friends in LVI. The implementation is forwarding to the corresponding APInt methods with appropriate bounds. One thing worth pointing out here is that the handling of wrapping ranges is not maximally accurate. A simple example is that adding 0 to a wrapped range will return a full range, rather than the original wrapped range. The tests also only check that the non-wrapping envelope is correct and minimal. Differential Revision: https://reviews.llvm.org/D60946 llvm-svn: 358855
* [ConstantRange] Add getNonEmpty() constructorNikita Popov2019-04-211-57/+17
| | | | | | | | | | | | | | ConstantRanges have an annoying special case: If upper and lower are the same, it can be either an empty or a full set. When constructing constant ranges nearly always a full set is intended, but this still requires an explicit check in many places. This revision adds a getNonEmpty() constructor that disambiguates this case: If upper and lower are the same, a full set is created. Differential Revision: https://reviews.llvm.org/D60947 llvm-svn: 358854
* ftime-trace: Trace the name of the currently active pass as well.Nico Weber2019-04-201-6/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D60782 llvm-svn: 358834
* [LLVM-C] Add DIFile Field AccesssorsRobert Widmann2019-04-171-0/+25
| | | | | | | | | | | | | | | | | | | Summary: Add accessors for the file, directory, source file name (curiously, an `Optional` value?), of a DIFile. This is intended to replace the LLVMValueRef-based accessors used in D52239 Reviewers: whitequark, jberdine, deadalnix Reviewed By: whitequark, jberdine Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60489 llvm-svn: 358577
OpenPOWER on IntegriCloud