summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachinePipeliner.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MachinePipeliner] Fix risky iterator usage R++, --RJinsong Ji2019-06-251-7/+3
| | | | | | | | | | | | | When we calculate MII, we use two loops, one with iterator R++ to check whether we can reserve the resource, then --R to move back the iterator to do reservation. This is risky, as R++, --R may not point to the same element at all. The can cause wrong MII. Differential Revision: https://reviews.llvm.org/D63536 llvm-svn: 364353
* Simplify std::lower_bound with llvm::{bsearch,lower_bound}. NFCFangrui Song2019-06-211-9/+6
| | | | llvm-svn: 364006
* [MachinePipeliner][NFC] Do resource tracking log only when requested.Jinsong Ji2019-06-181-22/+43
| | | | | | | In most cases we don't need to do resource tracking debug, so leave them off by default. llvm-svn: 363733
* [MachinePiepliner] Don't check boundary node in checkValidNodeOrderJinsong Ji2019-06-131-0/+5
| | | | | | | | | | | | | | | | | | | This was exposed by PowerPC target enablement. In ScheduleDAG, if we haven't seen any uses in this scheduling region, we will create a dependence edge to ExitSU to model the live-out latency. This is required for vreg defs with no in-region use, and prefetches with no vreg def. When we build NodeOrder in Scheduler, we ignore these boundary nodes. However, when we check Succs in checkValidNodeOrder, we did not skip them, so we still assume all the nodes have been sorted and in order in Indices array. So when we call lower_bound() for ExitSU, it will return Indices.end(), causing memory issues in following Node access. Differential Revision: https://reviews.llvm.org/D63282 llvm-svn: 363329
* [PowerPC] Enable MachinePipeliner for P9 with -ppc-enable-pipelinerJinsong Ji2019-06-111-4/+12
| | | | | | | | | Implement necessary target hooks to enable MachinePipeliner for P9 only. The pass is off by default, can be enabled with -ppc-enable-pipeliner for P9. Differential Revision: https://reviews.llvm.org/D62164 llvm-svn: 363085
* Allow target to handle STRICT floating-point nodesUlrich Weigand2019-06-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ISD::STRICT_ nodes used to implement the constrained floating-point intrinsics are currently never passed to the target back-end, which makes it impossible to handle them correctly (e.g. mark instructions are depending on a floating-point status and control register, or mark instructions as possibly trapping). This patch allows the target to use setOperationAction to switch the action on ISD::STRICT_ nodes to Legal. If this is done, the SelectionDAG common code will stop converting the STRICT nodes to regular floating-point nodes, but instead pass the STRICT nodes to the target using normal SelectionDAG matching rules. To avoid having the back-end duplicate all the floating-point instruction patterns to handle both strict and non-strict variants, we make the MI codegen explicitly aware of the floating-point exceptions by introducing two new concepts: - A new MCID flag "mayRaiseFPException" that the target should set on any instruction that possibly can raise FP exception according to the architecture definition. - A new MI flag FPExcept that CodeGen/SelectionDAG will set on any MI instruction resulting from expansion of any constrained FP intrinsic. Any MI instruction that is *both* marked as mayRaiseFPException *and* FPExcept then needs to be considered as raising exceptions by MI-level codegen (e.g. scheduling). Setting those two new flags is straightforward. The mayRaiseFPException flag is simply set via TableGen by marking all relevant instruction patterns in the .td files. The FPExcept flag is set in SDNodeFlags when creating the STRICT_ nodes in the SelectionDAG, and gets inherited in the MachineSDNode nodes created from it during instruction selection. The flag is then transfered to an MIFlag when creating the MI from the MachineSDNode. This is handled just like fast-math flags like no-nans are handled today. This patch includes both common code changes required to implement the new features, and the SystemZ implementation. Reviewed By: andrew.w.kaylor Differential Revision: https://reviews.llvm.org/D55506 llvm-svn: 362663
* [MachinePipeliner][NFC] Add some debug log and statisticsJinsong Ji2019-05-311-12/+71
| | | | | | | | This is to add some log and statistics for debugging Differential Revision: https://reviews.llvm.org/D62165 llvm-svn: 362233
* Inline a variable into debug section to fix unused variable warning.Richard Trieu2019-05-291-2/+2
| | | | llvm-svn: 361927
* Inline value into debug statement to avoid unused variable warning.Richard Trieu2019-05-291-3/+2
| | | | llvm-svn: 361924
* Support resource tracking with InstrSchedModelJinsong Ji2019-05-291-32/+209
| | | | | | | | | | | | The current design use DFA to do resource tracking in SMS, and DFA only support InstrItins, and also has scaling limitation. This patch extend SMS to allow Subtarget to use ProcResource in InstrSchedModel instead. Differential Revision: https://reviews.llvm.org/D62163 llvm-svn: 361919
* Add "const" in GetUnderlyingObjects. NFCBjorn Pettersson2019-04-241-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Both the input Value pointer and the returned Value pointers in GetUnderlyingObjects are now declared as const. It turned out that all current (in-tree) uses of GetUnderlyingObjects were trivial to update, being satisfied with have those Value pointers declared as const. Actually, in the past several of the users had to use const_cast, just because of ValueTracking not providing a version of GetUnderlyingObjects with "const" Value pointers. With this patch we get rid of those const casts. Reviewers: hfinkel, materi, jkorous Reviewed By: jkorous Subscribers: dexonsmith, jkorous, jholewinski, sdardis, eraman, hiraditya, jrtc27, atanasyan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61038 llvm-svn: 359072
* Use llvm::stable_sortFangrui Song2019-04-231-1/+1
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* [CodeGen] Add "const" to MachineInstr::mayAliasBjorn Pettersson2019-04-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The basic idea here is to make it possible to use MachineInstr::mayAlias also when the MachineInstr is const (or the "Other" MachineInstr is const). The addition of const in MachineInstr::mayAlias then rippled down to the need for adding const in several other places, such as TargetTransformInfo::getMemOperandWithOffset. Reviewers: hfinkel Reviewed By: hfinkel Subscribers: hfinkel, MatzeB, arsenm, jvesely, nhaehnle, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60856 llvm-svn: 358744
* [Pipeliner] Fix incorrect loop carried dependence calculationBrendon Cahoon2019-04-111-5/+7
| | | | | | | | | | | | The isLoopCarriedDep function does not correctly compute loop carried dependences when the array index offset is negative or the stride is smallar than the access size. Patch by Denis Antrushin. Differential Revision: https://reviews.llvm.org/D60135 llvm-svn: 358233
* [CodeGen] Be as conservative about atomic accesses as for volatilePhilip Reames2019-02-011-1/+3
| | | | | | | | | | | | | | Background: At the moment, we record the AtomicOrdering of an access in the MMO, but also mark any atomic access as volatile in SelectionDAG. I'm working towards separating that. See https://reviews.llvm.org/D57601 for context. Update all usages of isVolatile in lib/CodeGen to preserve behaviour once atomic MMOs stop being also volatile. This is NFC in it's current form, but is essential for correctness once we make that final change. It useful to keep in mind that AtomicSDNode is not a parent of LoadSDNode, StoreSDNode, or LSBaseSDNode. As a result, any call to isVolatile on one of those static types doesn't need a companion isAtomic check. We should probably adjust that class hierarchy long term, but for now, that seperation is useful. I'm deliberately being conservative about handling. I want the change to stop adding volatile to be NFC itself, and then will work through places where we can be less conservative for atomics one by one in separate changes w/tests. Differential Revision: https://reviews.llvm.org/D57596 llvm-svn: 352937
* [NFC] Test commit : fix typo.Alexey Lapshin2019-01-251-1/+1
| | | | llvm-svn: 352248
* [Pipeliner] Add two pragmas to control software pipelining optimizationBrendon Cahoon2019-01-231-7/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #pragma clang loop pipeline(disable) Disable SWP optimization for the next loop. “disable” is the only possible value. #pragma clang loop pipeline_initiation_interval(number) Set value of initiation interval for SWP optimization to specified number value for the next loop. Number is the positive value greater than 0. These pragmas could be used for debugging or reducing compile time purposes. It is possible to disable SWP for concrete loops to save compilation time or to find bugs by not doing SWP to certain loops. It is possible to set value of initiation interval to concrete number to save compilation time by not doing extra pipeliner passes or to check created schedule for specific initiation interval. That is llvm part of the fix Clang part of fix: https://reviews.llvm.org/D55710 Patch by Alexey Lapshin! Differential Revision: https://reviews.llvm.org/D56403 llvm-svn: 351923
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Reapply r345008 "Split MachinePipeliner code into header and cpp files"Adrian Prantl2019-01-141-595/+18
| | | | | | | | | | | | | | Split MachinePipeliner code into header and cpp files to allow inheritance from SwingSchedulerDAG. This reapplies https://reviews.llvm.org/D56084 after moving the implementation of the dump functions into the .cpp files. This fixes a linker error when building with Clang modules enables and local submodule visibility disabled. Original patch by Lama Saba <lama.saba@intel.com>! llvm-svn: 351077
* [NFC] fix trivial typos in commentsHiroshi Inoue2019-01-091-2/+2
| | | | llvm-svn: 350690
* Revert "Revert "Revert "Resubmit rL345008 "Split MachinePipeliner code into ↵Adrian Prantl2019-01-081-5/+595
| | | | | | | | header and cpp files"""" This reverts commit D56084. llvm-svn: 350654
* Revert "Revert "Resubmit rL345008 "Split MachinePipeliner code into header ↵Lama Saba2019-01-081-595/+5
| | | | | | | | | | and cpp files""" This reverts commit rL350497 reported remaining issues seem to be unrelated to modules or this change. more info: https://reviews.llvm.org/D56084 llvm-svn: 350621
* Revert "Resubmit rL345008 "Split MachinePipeliner code into header and cpp ↵Lama Saba2019-01-061-5/+595
| | | | | | | | | files"" This reverts commit rL350493 issues related to modules still appear in http://green.lab.llvm.org/green/job/lldb-cmake llvm-svn: 350497
* Resubmit rL345008 "Split MachinePipeliner code into header and cpp files"Lama Saba2019-01-061-595/+5
| | | | | | | | | Resubmitted in rL345290 and reverted in rL350345 due to failures in http://green.lab.llvm.org/green/job/lldb-cmake/ Resubmitting after a workaround to lldb-cmake failure was committed in rL350346, more info in https://reviews.llvm.org/D56084 llvm-svn: 350493
* Revert "Resubmit rL345008 "Split MachinePipeliner code into header and cpp ↵Stefan Granitz2019-01-031-5/+595
| | | | | | | | files"" This reverts commit r350290. llvm-svn: 350345
* Resubmit rL345008 "Split MachinePipeliner code into header and cpp files"Lama Saba2019-01-031-595/+5
| | | | | | | | | The commit caused unclear failures in http://green.lab.llvm.org/green//job/lldb-cmake/ will revert if the error reappears Differential Revision: https://reviews.llvm.org/D56084 llvm-svn: 350290
* [CodeGen][NFC] Make `TII::getMemOpBaseImmOfs` return a base operandFrancis Visoiu Mistrih2018-11-281-11/+17
| | | | | | | | | | | | | | | | | | Currently, instructions doing memory accesses through a base operand that is not a register can not be analyzed using `TII::getMemOpBaseRegImmOfs`. This means that functions such as `TII::shouldClusterMemOps` will bail out on instructions using an FI as a base instead of a register. The goal of this patch is to refactor all this to return a base operand instead of a base register. Then in a separate patch, I will add FI support to the mem op clustering in the MachineScheduler. Differential Revision: https://reviews.llvm.org/D54846 llvm-svn: 347746
* [Pipeliner] Ignore Artificial dependences while computing recurrences.Sumanth Gundapaneni2018-10-251-3/+3
| | | | | | | | | | The artificial dependencies are not real dependencies. In some cases, they form circuits with bigger MII. However, they are used to schedule instructions better. Differential Revision: https://reviews.llvm.org/D53450 llvm-svn: 345319
* [Pipeliner] Remove the unneeded include header(NFC).Sumanth Gundapaneni2018-10-251-1/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D53451 llvm-svn: 345318
* Revert "[MachinePipeliner] Split MachinePipeliner code into header and cpp ↵Aleksandr Urakov2018-10-231-7/+598
| | | | | | | | | files" This reverts commit 40760b733d9eef841c897338af5e9d81b12551bf. It seems that the commit is a cuse of the build failure. llvm-svn: 345032
* [MachinePipeliner] Split MachinePipeliner code into header and cpp filesLama Saba2018-10-231-598/+7
| | | | | | | | Split MachinePipeliner code into header and cpp files to allow inheritance from SwingSchedulerDAG Differential Revision: https://reviews.llvm.org/D53477 llvm-svn: 345008
* [Pipeliner] copyToPhi DAG Mutation to improve scheduling.Sumanth Gundapaneni2018-10-181-1/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | In a loop, create artificial dependences between the source of a COPY/REG_SEQUENCE to the use in next iteration. Eg: SRC ----Data Dep--> COPY COPY ---Anti Dep--> PHI (implies, to be used in next iteration) PHI ----Data Dep--> USE This patches creates USE ----Artificial Dep---> SRC This will effectively schedule the COPY late to eliminate additional copies. Before this patch, the schedule can be SRC, COPY, USE : The COPY is used in next iteration and it needs to be preserved. After this patch, the schedule can be USE, SRC, COPY : The COPY is used in next iteration and the live interval is reduced. Differential Revision: https://reviews.llvm.org/D53303 llvm-svn: 344748
* [Pipeliner] Use the Index from Topo instead of relying on NodeNum. (NFC)Sumanth Gundapaneni2018-10-111-4/+14
| | | | | | | | | | In future, if we may add any new DAG mutations other than artificial dependencies, the NodeNum may not be valid. Instead the index from topological schedule DAG can be used as long as we update it with the DAG change. Differential Revision: https://reviews.llvm.org/D53104 llvm-svn: 344283
* [Pipeliner] Fix the Schedule DAG topoligical order.Sumanth Gundapaneni2018-10-111-0/+1
| | | | | | | | | This patch updates the DAG change to reflect in the topological ordering of the nodes. Differential Revision: https://reviews.llvm.org/D53105 llvm-svn: 344282
* Replace most users of UnknownSize with LocationSize::unknown(); NFCGeorge Burgess IV2018-10-101-2/+2
| | | | | | | | | | | | Moving away from UnknownSize is part of the effort to migrate us to LocationSizes (e.g. the cleanup promised in D44748). This doesn't entirely remove all of the uses of UnknownSize; some uses require tweaks to assume that UnknownSize isn't just some kind of int. This patch is intended to just be a trivial replacement for all places where LocationSize::unknown() will Just Work. llvm-svn: 344186
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-3/+2
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* ScheduleDAG: Cleanup dumping code; NFCMatthias Braun2018-09-191-6/+3
| | | | | | | | | | | | - Instead of having both `SUnit::dump(ScheduleDAG*)` and `ScheduleDAG::dumpNode(ScheduleDAG*)`, just keep the latter around. - Add `ScheduleDAG::dump()` and avoid code duplication in several places. Implement it for different ScheduleDAG variants. - Add `ScheduleDAG::dumpNodeName()` in favor of the `SUnit::print()` functions. They were only ever used for debug dumping and putting the function into ScheduleDAG is consistent with the `dumpNode()` change. llvm-svn: 342520
* [Pipeliner] Fix incorrect phi values in the epilog and kernelBrendon Cahoon2018-08-271-29/+32
| | | | | | | | | | | | | | | | | | | The code that generates the loop definition operand for phis in the epilog and kernel is incorrect in some cases. In the kernel, when a phi refers to another phi, the code that updates PhiOp2 needs to include the stage difference between the two phis. In the epilog, the check for using the loop definition instead of the phi definition uses the StageDiffAdj value (the difference between the phi stage and the loop definition stage), but the adjustment is not needed to determine if the current stage contains an iteration with the loop definition. Differential Revision: https://reviews.llvm.org/D51167 llvm-svn: 340782
* Consistently use MemoryLocation::UnknownSize to indicate unknown access sizeKrzysztof Parzyszek2018-08-201-2/+2
| | | | | | | | | | | | 1. Change the software pipeliner to use unknown size instead of dropping memory operands. It used to do it before, but MachineInstr::mayAlias did not handle it correctly. 2. Recognize UnknownSize in MachineInstr::mayAlias. 3. Print and parse UnknownSize in MIR. Differential Revision: https://reviews.llvm.org/D50339 llvm-svn: 340208
* [MI] Change the array of `MachineMemOperand` pointers to beChandler Carruth2018-08-161-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a generically extensible collection of extra info attached to a `MachineInstr`. The primary change here is cleaning up the APIs used for setting and manipulating the `MachineMemOperand` pointer arrays so chat we can change how they are allocated. Then we introduce an extra info object that using the trailing object pattern to attach some number of MMOs but also other extra info. The design of this is specifically so that this extra info has a fixed necessary cost (the header tracking what extra info is included) and everything else can be tail allocated. This pattern works especially well with a `BumpPtrAllocator` which we use here. I've also added the basic scaffolding for putting interesting pointers into this, namely pre- and post-instruction symbols. These aren't used anywhere yet, they're just there to ensure I've actually gotten the data structure types correct. I'll flesh out support for these in a subsequent patch (MIR dumping, parsing, the works). Finally, I've included an optimization where we store any single pointer inline in the `MachineInstr` to avoid the allocation overhead. This is expected to be the overwhelmingly most common case and so should avoid any memory usage growth due to slightly less clever / dense allocation when dealing with >1 MMO. This did require several ergonomic improvements to the `PointerSumType` to reasonably support the various usage models. This also has a side effect of freeing up 8 bits within the `MachineInstr` which could be repurposed for something else. The suggested direction here came largely from Hal Finkel. I hope it was worth it. ;] It does hopefully clear a path for subsequent extensions w/o nearly as much leg work. Lots of thanks to Reid and Justin for careful reviews and ideas about how to do all of this. Differential Revision: https://reviews.llvm.org/D50701 llvm-svn: 339940
* [CodeGen] Fix inconsistent declaration parameter nameFangrui Song2018-07-161-2/+2
| | | | llvm-svn: 337200
* [NFC] fix trivial typos in commentsHiroshi Inoue2018-06-201-8/+8
| | | | llvm-svn: 335096
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-39/+41
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* [NFC] fix trivial typos in commentsHiroshi Inoue2018-04-131-1/+1
| | | | | | "the the" -> "the", "we we" -> "we", etc llvm-svn: 330006
* [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] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-061-3/+4
| | | | | | | | | | | | | | | | | | | | | | 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
* [Pipeliner] Several node-ordering fixesKrzysztof Parzyszek2018-03-261-18/+16
| | | | | | | | | | | | | | | | | | | | | | First, we change the heuristic that is used to ignore the recurrent node-sets in the node ordering. In certain cases it's not important to focus on the recurrent node-sets. Instead, the algorithm begins by considering all the instructions in the node ordering step. Second, a minor change to the bottom up traversal, which needs to consider loop carried dependences (modeled as anti dependences). Previously, these instructions were skipped, which caused problems because the instruction ends up having both predecessors and sucessors in the schedule. Third, consider anti-dependences as a tie breaker when choosing between instructions in the node ordering. We want to make sure that the source of the anti-dependence does not end up with both predecesssors and sucessors in the final node ordering. Patch by Brendon Cahoon. llvm-svn: 328554
* [Pipeliner] Check for affine expression in isLoopCarriedOrderKrzysztof Parzyszek2018-03-261-1/+13
| | | | | | | | | | | | | | | | | The pipeliner must add a loop carried dependence between two memory operations if the base register is not an affine (linear) exression. The current implementation doesn't check how the base register is defined, which allows non-affine expressions, and then the pipeliner does not add a loop carried dependence when one is needed. This patch adds code to isLoopCarriedOrder that checks if the base register of the memory operations is defined by a phi, and the loop definition for the phi is a constant increment value. This is a very simple check for a linear expression. Patch by Brendon Cahoon. llvm-svn: 328550
* [Pipeliner] Add missing loop carried dependencesKrzysztof Parzyszek2018-03-261-14/+23
| | | | | | | | | | | | | | | | | | | | | | The pipeliner is not adding a dependence edge for a loop carried dependence, and ends up scheduling a load from iteration n prior to an aliased store in iteration n-1. The code that adds the loop carried dependences in the pipeliner doesn't check if the memory objects for loads and stores are "identified" (i.e., distinct) objects. If they are not, then the code that adds the dependences needs to be conservative. The objects can be used to check dependences only when they are distinct objects. The code that checks for loop carried dependences has been updated to classify loads and stores that are not identified as "unknown" values. A store with an "unknown" value can potentially create a loop carried dependence with any pending load. Patch by Brendon Cahoon. llvm-svn: 328547
OpenPOWER on IntegriCloud