summaryrefslogtreecommitdiffstats
path: root/llvm/include
Commit message (Collapse)AuthorAgeFilesLines
* Fix broken C++ mode commentMatt Arsenault2019-07-011-1/+1
| | | | llvm-svn: 364858
* [GlobalISel]: Allow backends to custom legalize IntrinsicsAditya Nandakumar2019-07-011-0/+5
| | | | | | | | | https://reviews.llvm.org/D31359 Add a hook "legalizeInstrinsic" to allow backends to override this and custom lower/legalize intrinsics. llvm-svn: 364821
* GlobalISel: Implement lower for min/maxMatt Arsenault2019-07-011-0/+1
| | | | llvm-svn: 364816
* AMDGPU/GFX10: implement ds_ordered_count changesNicolai Haehnle2019-07-011-0/+1
| | | | | | | | | | | | | | | | | | | Summary: ds_ordered_count can now simultaneously operate on up to 4 dwords in a single instruction, which are taken from (and returned to) lanes 0..3 of a single VGPR. Change-Id: I19b6e7b0732b617c10a779a7f9c0303eec7dd276 Reviewers: mareko, arsenm, rampitec Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63716 llvm-svn: 364815
* AMDGPU/GlobalISel: RegBankSelect for DS ordered add/swapMatt Arsenault2019-07-011-0/+1
| | | | llvm-svn: 364811
* GlobalISel: Add GINodeEquiv for min/maxMatt Arsenault2019-07-011-0/+4
| | | | llvm-svn: 364759
* GlobalISel: Add DAG compat for G_FCANONICALIZEMatt Arsenault2019-07-011-0/+1
| | | | llvm-svn: 364758
* [DebugInfo] Avoid adding too much indirection to pointer-valued variablesJeremy Morse2019-07-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch addresses PR41675, where a stack-pointer variable is dereferenced too many times by its location expression, presenting a value on the stack as the pointer to the stack. The difference between a stack *pointer* DBG_VALUE and one that refers to a value on the stack, is currently the indirect flag. However the DWARF backend will also try to guess whether something is a memory location or not, based on whether there is any computation in the location expression. By simply prepending the stack offset to existing expressions, we can accidentally convert a register location into a memory location, which introduces a suprise (and unintended) dereference. The solution is to add DW_OP_stack_value whenever we add a DIExpression computation to a stack *pointer*. It's an implicit location computed on the expression stack, thus needs to be flagged as a stack_value. For the edge case where the offset is zero and the location could be a register location, DIExpression::prepend will still generate opcodes, and thus DW_OP_stack_value must still be added. Differential Revision: https://reviews.llvm.org/D63429 llvm-svn: 364736
* Cleanup: llvm::bsearch -> llvm::partition_point after r364719Fangrui Song2019-06-302-8/+8
| | | | llvm-svn: 364720
* [ADT] Implement llvm::bsearch() with std::partition_point()Fangrui Song2019-06-302-37/+7
| | | | | | | | | | | | | | | | | | | Summary: Delete the begin-end form because the standard std::partition_point can be easily used as a replacement. The ranges-style llvm::bsearch will be renamed to llvm::partition_point in the next clean-up patch. The name "bsearch" doesn't meet people's expectation because in C: > If two or more members compare equal, which member is returned is unspecified. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D63718 llvm-svn: 364719
* [IR][Patternmatch] Add m_SpecificInt_ULT() predicateRoman Lebedev2019-06-291-0/+14
| | | | | | | | | | | | | | | | | | | | Summary: Match an integer or vector with every element unsigned less than the Threshold. For vectors, this includes constants with undefined elements. FIXME: is it worth generalizing this to simply take ICmpInst::Predicate? Reviewers: craig.topper, spatel, nikic Reviewed By: spatel Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63811 llvm-svn: 364711
* [demangle] Support for C++2a char8_tErik Pilkington2019-06-281-0/+4
| | | | llvm-svn: 364677
* [DebugInfo] Fix setStartAddress after r364637Fangrui Song2019-06-281-1/+1
| | | | llvm-svn: 364638
* [DebugInfo] Simplify GSYM::AddressRange and GSYM::AddressRangesFangrui Song2019-06-282-51/+21
| | | | | | | | | | Delete unnecessary getters of AddressRange. Simplify AddressRange::size(): Start <= End check should be checked in an upper layer. Delete isContiguousWith() that doesn't make sense. Simplify AddressRanges::insert. Delete commented code. Fix it when more than 1 ranges are to be deleted. Delete trailing newline. llvm-svn: 364637
* [DebugInfo] GSYM cleanups after D63104/r364427Fangrui Song2019-06-286-26/+19
| | | | llvm-svn: 364634
* [HardwareLoops] Loop counter guard intrinsicSam Parker2019-06-282-0/+9
| | | | | | | | | Introduce llvm.test.set.loop.iterations which sets the loop counter and also produces an i1 after testing that the count is not zero. Differential Revision: https://reviews.llvm.org/D63809 llvm-svn: 364628
* [Support] Add fs::getUmask() function and change fs::setPermissionsAlex Brachet2019-06-281-1/+12
| | | | | | | | | | | | | | | | Summary: This patch changes fs::setPermissions to optionally set permissions while respecting the umask. It also adds the function fs::getUmask() which returns the current umask. Reviewers: jhenderson, rupprecht, aprantl, lhames Reviewed By: jhenderson, rupprecht Subscribers: sanaanajjar231288, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63583 llvm-svn: 364621
* GlobalISel: Use RegisterMatt Arsenault2019-06-282-12/+13
| | | | llvm-svn: 364618
* GlobalISel: Convert rest of MachineIRBuilder to using RegisterMatt Arsenault2019-06-281-47/+47
| | | | llvm-svn: 364615
* [GlobalISel][IRTranslator] Fix some PHI bugs related to jump tables when ↵Amara Emerson2019-06-271-2/+2
| | | | | | | | | | | | optimizations are used. The new switch lowering code that tries to generate jump tables and range checks were tested at -O0 on arm64, but on -O3 the generic switch lowering code goes to town on trying to generate optimized lowerings, e.g. multiple jump tables, range checks etc. This exposed bugs in the way PHI nodes are handled because the CFG looks even stranger after all of this is done. llvm-svn: 364613
* [InlineCost] make InlineCost assignableFedor Sergeev2019-06-271-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: Current InlineCost is not assignable because of const members Cost and Threshold. I dont see practical benefits from having them const (access to these members is private and internal interactions are rather simple). On other hand that makes it hard to use as a member in some other data structure where assignability is necessary. I'm going to use InlineCost in a downstream inliner that maintains a complex queue of candidate call-sites and thus keeping and recalculating InlineCost is necessary. This patch just removes 'const' from both members, making InlineCost assignable. Reviewers: eraman, greened, chandlerc, yrouban, apilipenko Reviewed By: apilipenko Tags: #llvm Differential Revision: https://reviews.llvm.org/D63823 llvm-svn: 364612
* [CodeGen] [SelectionDAG] More efficient code for X % C == 0 (UREM case) (try 3)Roman Lebedev2019-06-271-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I'm submitting a new revision since i don't understand how to reclaim/reopen/take over the existing one, D50222. There is no such action in "Add Action" menu... This implements an optimization described in Hacker's Delight 10-17: when `C` is constant, the result of `X % C == 0` can be computed more cheaply without actually calculating the remainder. The motivation is discussed here: https://bugs.llvm.org/show_bug.cgi?id=35479. This is a recommit, the original commit rL364563 was reverted in rL364568 because test-suite detected miscompile - the new comparison constant 'Q' was being computed incorrectly (we divided by `D0` instead of `D`). Original patch D50222 by @hermord (Dmytro Shynkevych) Notes: - In principle, it's possible to also handle the `X % C1 == C2` case, as discussed on bugzilla. This seems to require an extra branch on overflow, so I refrained from implementing this for now. - An explicit check for when the `REM` can be reduced to just its LHS is included: the `X % C` == 0 optimization breaks `test1` in `test/CodeGen/X86/jump_sign.ll` otherwise. I hadn't managed to find a better way to not generate worse output in this case. - The `test/CodeGen/X86/jump_sign.ll` regresses, and is being fixed by a followup patch D63390. Reviewers: RKSimon, craig.topper, spatel, hermord, xbolva00 Reviewed By: RKSimon, xbolva00 Subscribers: dexonsmith, kristina, xbolva00, javed.absar, llvm-commits, hermord Tags: #llvm Differential Revision: https://reviews.llvm.org/D63391 llvm-svn: 364600
* Convert line endings to LF.Alexandre Ganea2019-06-271-3/+3
| | | | llvm-svn: 364590
* Revert "[CodeGen] [SelectionDAG] More efficient code for X % C == 0 (UREM ↵Roman Lebedev2019-06-271-6/+0
| | | | | | | | | | | | | | | | | | case) (try 2)" *Appears* to break test-suite on http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/23790 FAIL: burg.execution_time FAIL: spiff.execution_time FAIL: employ.execution_time FAIL: llu.execution_time FAIL: gramschmidt.execution_time FAIL: fdtd-apml.execution_time This reverts commit r364563. llvm-svn: 364568
* [CodeGen] [SelectionDAG] More efficient code for X % C == 0 (UREM case) (try 2)Roman Lebedev2019-06-271-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I'm submitting a new revision since i don't understand how to reclaim/reopen/take over the existing one, D50222. There is no such action in "Add Action" menu... Original patch D50222 by @hermord (Dmytro Shynkevych) This implements an optimization described in Hacker's Delight 10-17: when `C` is constant, the result of `X % C == 0` can be computed more cheaply without actually calculating the remainder. The motivation is discussed here: https://bugs.llvm.org/show_bug.cgi?id=35479. Original patch author: @hermord (Dmytro Shynkevych)! Notes: - In principle, it's possible to also handle the `X % C1 == C2` case, as discussed on bugzilla. This seems to require an extra branch on overflow, so I refrained from implementing this for now. - An explicit check for when the `REM` can be reduced to just its LHS is included: the `X % C` == 0 optimization breaks `test1` in `test/CodeGen/X86/jump_sign.ll` otherwise. I hadn't managed to find a better way to not generate worse output in this case. - The `test/CodeGen/X86/jump_sign.ll` regresses, and is being fixed by a followup patch D63390. Reviewers: RKSimon, craig.topper, spatel, hermord, xbolva00 Reviewed By: RKSimon, xbolva00 Subscribers: xbolva00, javed.absar, llvm-commits, hermord Tags: #llvm Differential Revision: https://reviews.llvm.org/D63391 llvm-svn: 364563
* [Attr] Add "willreturn" function attributeJohannes Doerfert2019-06-272-1/+5
| | | | | | | | | | | | | | | | | | | | | | This patch introduces a new function attribute, willreturn, to indicate that a call of this function will either exhibit undefined behavior or comes back and continues execution at a point in the existing call stack that includes the current invocation. This attribute guarantees that the function does not have any endless loops, endless recursion, or terminating functions like abort or exit. Patch by Hideto Ueno (@uenoku) Reviewers: jdoerfert Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62801 llvm-svn: 364555
* Revert r363658 "[SVE][IR] Scalable Vector IR Type with pr42210 fix"Hans Wennborg2019-06-274-117/+11
| | | | | | | | | | | | | | | | | | | | | | | | We saw a 70% ThinLTO link time increase in Chromium for Android, see crbug.com/978817. Sounds like more of PR42210. > Recommit of D32530 with a few small changes: > - Stopped recursively walking through aggregates in > the verifier, so that we don't impose too much > overhead on large modules under LTO (see PR42210). > - Changed tests to match; the errors are slightly > different since they only report the array or > struct that actually contains a scalable vector, > rather than all aggregates which contain one in > a nested member. > - Corrected an older comment > > Reviewers: thakis, rengolin, sdesmalen > > Reviewed By: sdesmalen > > Differential Revision: https://reviews.llvm.org/D63321 llvm-svn: 364543
* [DWARF] Handle the DW_OP_entry_value operandDjordje Todorovic2019-06-272-3/+14
| | | | | | | | | | | | | | | Add the IR and the AsmPrinter parts for handling of the DW_OP_entry_values DWARF operation. ([11/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D60866 llvm-svn: 364542
* [Backend] Keep call site info valid through the backendDjordje Todorovic2019-06-271-0/+6
| | | | | | | | | | | | | | | | | | | | Handle call instruction replacements and deletions in order to preserve valid state of the call site info of the MachineFunction. NOTE: If the call site info is enabled for a new target, the assertion from the MachineFunction::DeleteMachineInstr() should help to locate places where the updateCallSiteInfo() should be called in order to preserve valid state of the call site info. ([10/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D61062 llvm-svn: 364536
* [Attributor] Deducing existing nounwind attribute.Stefan Stipanovic2019-06-271-0/+17
| | | | | | | | | | | | Adding nounwind deduction in new attributor framework. Reviewers: jdoerfert, uenoku Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D63379 llvm-svn: 364521
* [yaml2obj] - Allow overriding e_shentsize, e_shoff, e_shnum and e_shstrndx ↵George Rimar2019-06-271-0/+5
| | | | | | | | | | | | fields in the YAML. This allows setting different values for e_shentsize, e_shoff, e_shnum and e_shstrndx fields and is useful for producing broken inputs for various test cases. Differential revision: https://reviews.llvm.org/D63771 llvm-svn: 364517
* [ISEL][X86] Tracking of registers that forward call argumentsDjordje Todorovic2019-06-271-0/+15
| | | | | | | | | | | | | | | | | While lowering calls, collect info about registers that forward arguments into following function frame. We store such info into the MachineFunction of the call. This is used very late when dumping DWARF info about call site parameters. ([9/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D60715 llvm-svn: 364516
* [GlobalISel] Remove [un]packRegs from IRTranslatorDiana Picus2019-06-271-8/+0
| | | | | | | | | | | Remove the last use of packRegs from IRTranslator and delete pack/unpackRegs. This introduces a fallback to DAGISel for intrinsics with aggregate arguments, since we don't have a testcase for them so it's hard to tell how we'd want to handle them. Discussed in https://reviews.llvm.org/D63551 llvm-svn: 364514
* [GlobalISel] Accept multiple vregs for lowerCall's argsDiana Picus2019-06-271-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | Change the interface of CallLowering::lowerCall to accept several virtual registers for each argument, instead of just one. This is a follow-up to D46018. CallLowering::lowerReturn was similarly refactored in D49660 and lowerFormalArguments in D63549. With this change, we no longer pack the virtual registers generated for aggregates into one big lump before delegating to the target. Therefore, the target can decide itself whether it wants to handle them as separate pieces or use one big register. ARM and AArch64 have been updated to use the passed in virtual registers directly, which means we no longer need to generate so many merge/extract instructions. NFCI for AMDGPU, Mips and X86. Differential Revision: https://reviews.llvm.org/D63551 llvm-svn: 364512
* [GlobalISel] Accept multiple vregs for lowerCall's resultDiana Picus2019-06-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Change the interface of CallLowering::lowerCall to accept several virtual registers for the call result, instead of just one. This is a follow-up to D46018. CallLowering::lowerReturn was similarly refactored in D49660 and lowerFormalArguments in D63549. With this change, we no longer pack the virtual registers generated for aggregates into one big lump before delegating to the target. Therefore, the target can decide itself whether it wants to handle them as separate pieces or use one big register. ARM and AArch64 have been updated to use the passed in virtual registers directly, which means we no longer need to generate so many merge/extract instructions. NFCI for AMDGPU, Mips and X86. Differential Revision: https://reviews.llvm.org/D63550 llvm-svn: 364511
* [GlobalISel] Accept multiple vregs in lowerFormalArgsDiana Picus2019-06-271-8/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the interface of CallLowering::lowerFormalArguments to accept several virtual registers for each formal argument, instead of just one. This is a follow-up to D46018. CallLowering::lowerReturn was similarly refactored in D49660. lowerCall will be refactored in the same way in follow-up patches. With this change, we forward the virtual registers generated for aggregates to CallLowering. Therefore, the target can decide itself whether it wants to handle them as separate pieces or use one big register. We also copy the pack/unpackRegs helpers to CallLowering to facilitate this. ARM and AArch64 have been updated to use the passed in virtual registers directly, which means we no longer need to generate so many merge/extract instructions. AArch64 seems to have had a bug when lowering e.g. [1 x i8*], which was put into a s64 instead of a p0. Added a test-case which illustrates the problem more clearly (it crashes without this patch) and fixed the existing test-case to expect p0. AMDGPU has been updated to unpack into the virtual registers for kernels. I think the other code paths fall back for aggregates, so this should be NFC. Mips doesn't support aggregates yet, so it's also NFC. x86 seems to have code for dealing with aggregates, but I couldn't find the tests for it, so I just added a fallback to DAGISel if we get more than one virtual register for an argument. Differential Revision: https://reviews.llvm.org/D63549 llvm-svn: 364510
* [GlobalISel] Allow multiple VRegs in ArgInfo. NFCDiana Picus2019-06-271-5/+8
| | | | | | | | | | | Allow CallLowering::ArgInfo to contain more than one virtual register. This is useful when passes split aggregates into several virtual registers, but need to also provide information about the original type to the call lowering. Used in follow-up patches. Differential Revision: https://reviews.llvm.org/D63548 llvm-svn: 364509
* [MachineFunction] Base support for call site info trackingDjordje Todorovic2019-06-272-0/+94
| | | | | | | | | | | | | | Add an attribute into the MachineFunction that tracks call site info. ([8/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D61061 llvm-svn: 364506
* Fix GCC 4 build after r364464Hans Wennborg2019-06-271-1/+1
| | | | | | | | | | | | | | | | | | It was failing with: In file included from /b/s/w/ir/cache/builder/src/third_party/llvm/llvm/lib/Bitcode/Reader/BitstreamReader.cpp:9:0: /b/s/w/ir/cache/builder/src/third_party/llvm/llvm/include/llvm/Bitcode/BitstreamReader.h: In member function 'llvm::Expected<long unsigned int> llvm::SimpleBitstreamCursor::ReadVBR64(unsigned int)': /b/s/w/ir/cache/builder/src/third_party/llvm/llvm/include/llvm/Bitcode/BitstreamReader.h:262:14: error: could not convert 'MaybeRead' from 'llvm::Expected<unsigned int>' to 'llvm::Expected<long unsigned int>' return MaybeRead; ^ /b/s/w/ir/cache/builder/src/third_party/llvm/llvm/include/llvm/Bitcode/BitstreamReader.h:279:16: error: could not convert 'MaybeRead' from 'llvm::Expected<unsigned int>' to 'llvm::Expected<long unsigned int>' return MaybeRead; ^ llvm-svn: 364504
* BitStream reader: propagate errorsJF Bastien2019-06-262-52/+107
| | | | | | | | | | | | | | | | | | | | | | The bitstream reader handles errors poorly. This has two effects: * Bugs in file handling (especially modules) manifest as an "unexpected end of file" crash * Users of clang as a library end up aborting because the code unconditionally calls `report_fatal_error` The bitstream reader should be more resilient and return Expected / Error as soon as an error is encountered, not way late like it does now. This patch starts doing so and adopting the error handling where I think it makes sense. There's plenty more to do: this patch propagates errors to be minimally useful, and follow-ups will propagate them further and improve diagnostics. https://bugs.llvm.org/show_bug.cgi?id=42311 <rdar://problem/33159405> Differential Revision: https://reviews.llvm.org/D63518 llvm-svn: 364464
* Fix some undefined behavior (excessive shift of signed value) in r364253 ↵David Blaikie2019-06-261-1/+1
| | | | | | detected by ubsan llvm-svn: 364461
* Fix Wdocumentation warnings. NFCI.Simon Pilgrim2019-06-261-1/+3
| | | | llvm-svn: 364459
* Make AddLastArg() variadic and use it more. No behavior change.Nico Weber2019-06-261-4/+6
| | | | llvm-svn: 364453
* Allow matching extend-from-memory with strict FP nodesUlrich Weigand2019-06-261-0/+13
| | | | | | | | | | | | | | | | | | | | | This implements a small enhancement to https://reviews.llvm.org/D55506 Specifically, while we were able to match strict FP nodes for floating-point extend operations with a register as source, this did not work for operations with memory as source. That is because from regular operations, this is represented as a combined "extload" node (which is a variant of a load SD node); but there is no equivalent using a strict FP operation. However, it turns out that even in the absence of an extload node, we can still just match the operations explicitly, e.g. (strict_fpextend (f32 (load node:$ptr)) This patch implements that method to match the LDEB/LXEB/LXDB SystemZ instructions even when the extend uses a strict-FP node. llvm-svn: 364450
* Add GSYM utility files along with unit tests.Greg Clayton2019-06-266-0/+478
| | | | | | | | | | | | | | | | | | | | | | | | The full GSYM patch started with: https://reviews.llvm.org/D53379 In that patch we wanted to split up getting GSYM into the LLVM code base so we are not committing too much code at once. This is a first in a series of patches where I only add the foundation classes along with complete unit tests. They provide the foundation for encoding and decoding a GSYM file. File entries are defined in llvm::gsym::FileEntry. This class splits the file up into a directory and filename represented by uniqued string table offsets. This allows all files that are referred to in a GSYM file to be encoded as 1 based indexes into a global file table in the GSYM file. Function information in stored in llvm::gsym::FunctionInfo. This object represents a contiguous address range that has a name and range with an optional line table and inline call stack information. Line table entries are defined in llvm::gsym::LineEntry. They store only address, file and line information to keep the line tables simple and allows the information to be efficiently encoded in a subsequent patch. Inline information is defined in llvm::gsym::InlineInfo. These structs store the name of the inline function, along with one or more address ranges, and the file and line that called this function. They also contain any child inline information. There are also utility classes for address ranges in llvm::gsym::AddressRange, and string table support in llvm::gsym::StringTable which are simple classes. The unit tests test all the APIs on these simple classes so they will be ready for the next patches where we will create GSYM files and parse GSYM files. Differential Revision: https://reviews.llvm.org/D63104 llvm-svn: 364427
* [X86] X86DAGToDAGISel::matchBitExtract(): pattern b: truncation awarenessRoman Lebedev2019-06-261-0/+5
| | | | | | | | | | | | | | | | | | Summary: (Not so) boringly identical to pattern a (D62786) Not yet sure how do deal with the last pattern c. Reviewers: RKSimon, craig.topper, spatel Reviewed By: RKSimon Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62793 llvm-svn: 364418
* Revert "r364412 [ExpandMemCmp][MergeICmps] Move passes out of CodeGen into ↵Clement Courbet2019-06-263-7/+3
| | | | | | | | | | | | | | opt pipeline." Breaks sanitizers: libFuzzer :: cxxstring.test libFuzzer :: memcmp.test libFuzzer :: recommended-dictionary.test libFuzzer :: strcmp.test libFuzzer :: value-profile-mem.test libFuzzer :: value-profile-strcmp.test llvm-svn: 364416
* [HardwareLoops] NFC - move loop with irreducible control flow checking logic ↵Chen Zheng2019-06-261-2/+2
| | | | | | to HarewareLoopInfo. llvm-svn: 364415
* [ExpandMemCmp][MergeICmps] Move passes out of CodeGen into opt pipeline.Clement Courbet2019-06-263-3/+7
| | | | | | | | | This allows later passes (in particular InstCombine) to optimize more cases. One that's important to us is `memcmp(p, q, constant) < 0` and memcmp(p, q, constant) > 0. llvm-svn: 364412
* [IR/DIVar] Add the flag for params that have unmodified valueDjordje Todorovic2019-06-262-0/+6
| | | | | | | | | | | | | | | | Introduce the debug info flag that indicates that a parameter has unchanged value throughout a function. This info will be used to emit the expressions with DW_OP_entry_value. ([4/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D58034 llvm-svn: 364406
OpenPOWER on IntegriCloud