aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachinePipeliner.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-08-15Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders1-19/+19
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Partial reverts in: X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned& MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register PPCFastISel.cpp - No Register::operator-=() PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned& MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor Manual fixups in: ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned& HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register. PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned& Depends on D65919 Reviewers: arsenm, bogner, craig.topper, RKSimon Reviewed By: arsenm Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65962 llvm-svn: 369041
2019-08-09[MachinePipeliner] Avoid indeterminate order in FuncUnitSorterJinsong Ji1-1/+1
Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-01Finish moving TargetRegisterInfo::isVirtualRegister() and friends to ↵Daniel Sanders1-8/+8
llvm::Register as started by r367614. NFC llvm-svn: 367633
2019-07-12[MachinePipeliner] Fix order for nodes with Anti dependence in same cycleJinsong Ji1-0/+8
Summary: Problem exposed in PowerPC functional testing. We did not consider Anti dependence for nodes in same cycle, so we may end up generating bad machine code. eg: the reduced test won't verify. *** Bad machine code: Using an undefined physical register *** - function: lame_encode_buffer_interleaved - basic block: %bb.4 (0x4bde4e12928) - instruction: %29:gprc = ADDZE %27:gprc, implicit-def dead $carry, implicit $carry - operand 3: implicit $carry Reviewers: bcahoon, kparzysz, hfinkel Subscribers: MaskRay, wuzish, nemanjai, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64192 llvm-svn: 365859
2019-07-09[MachinePipeliner] Fix Phi refers to Phi in same stage in 1st epilogueJinsong Ji1-1/+1
Summary: This is exposed by functional testing on PowerPC. In some pipelined loops, Phi refer to phi did not get value defined by the Phi, hence getting wrong value later. As the comment mentioned, we should "use the value defined by the Phi, unless we're generating the firstepilog and the Phi refers to a Phi in a different stage.", so Phi refering to same stage Phi should use the value defined by the Phi here. Reviewers: bcahoon, hfinkel Reviewed By: hfinkel Subscribers: MaskRay, wuzish, nemanjai, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64035 llvm-svn: 365428
2019-06-25[MachinePipeliner] Fix risky iterator usage R++, --RJinsong Ji1-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
2019-06-21Simplify std::lower_bound with llvm::{bsearch,lower_bound}. NFCFangrui Song1-9/+6
llvm-svn: 364006
2019-06-18[MachinePipeliner][NFC] Do resource tracking log only when requested.Jinsong Ji1-22/+43
In most cases we don't need to do resource tracking debug, so leave them off by default. llvm-svn: 363733
2019-06-13[MachinePiepliner] Don't check boundary node in checkValidNodeOrderJinsong Ji1-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
2019-06-11[PowerPC] Enable MachinePipeliner for P9 with -ppc-enable-pipelinerJinsong Ji1-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
2019-06-05Allow target to handle STRICT floating-point nodesUlrich Weigand1-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
2019-05-31[MachinePipeliner][NFC] Add some debug log and statisticsJinsong Ji1-12/+71
This is to add some log and statistics for debugging Differential Revision: https://reviews.llvm.org/D62165 llvm-svn: 362233
2019-05-29Inline a variable into debug section to fix unused variable warning.Richard Trieu1-2/+2
llvm-svn: 361927
2019-05-29Inline value into debug statement to avoid unused variable warning.Richard Trieu1-3/+2
llvm-svn: 361924
2019-05-29Support resource tracking with InstrSchedModelJinsong Ji1-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
2019-04-24Add "const" in GetUnderlyingObjects. NFCBjorn Pettersson1-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
2019-04-23Use llvm::stable_sortFangrui Song1-1/+1
While touching the code, simplify if feasible. llvm-svn: 358996
2019-04-19[CodeGen] Add "const" to MachineInstr::mayAliasBjorn Pettersson1-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
2019-04-11[Pipeliner] Fix incorrect loop carried dependence calculationBrendon Cahoon1-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
2019-02-01[CodeGen] Be as conservative about atomic accesses as for volatilePhilip Reames1-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
2019-01-25 [NFC] Test commit : fix typo.Alexey Lapshin1-1/+1
llvm-svn: 352248
2019-01-23[Pipeliner] Add two pragmas to control software pipelining optimizationBrendon Cahoon1-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
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2019-01-14Reapply r345008 "Split MachinePipeliner code into header and cpp files"Adrian Prantl1-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
2019-01-09[NFC] fix trivial typos in commentsHiroshi Inoue1-2/+2
llvm-svn: 350690
2019-01-08Revert "Revert "Revert "Resubmit rL345008 "Split MachinePipeliner code into ↵Adrian Prantl1-5/+595
header and cpp files"""" This reverts commit D56084. llvm-svn: 350654
2019-01-08Revert "Revert "Resubmit rL345008 "Split MachinePipeliner code into header ↵Lama Saba1-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
2019-01-06Revert "Resubmit rL345008 "Split MachinePipeliner code into header and cpp ↵Lama Saba1-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
2019-01-06Resubmit rL345008 "Split MachinePipeliner code into header and cpp files"Lama Saba1-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
2019-01-03Revert "Resubmit rL345008 "Split MachinePipeliner code into header and cpp ↵Stefan Granitz1-5/+595
files"" This reverts commit r350290. llvm-svn: 350345
2019-01-03Resubmit rL345008 "Split MachinePipeliner code into header and cpp files"Lama Saba1-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
2018-11-28[CodeGen][NFC] Make `TII::getMemOpBaseImmOfs` return a base operandFrancis Visoiu Mistrih1-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
2018-10-25[Pipeliner] Ignore Artificial dependences while computing recurrences.Sumanth Gundapaneni1-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
2018-10-25[Pipeliner] Remove the unneeded include header(NFC).Sumanth Gundapaneni1-1/+0
Differential Revision: https://reviews.llvm.org/D53451 llvm-svn: 345318
2018-10-23Revert "[MachinePipeliner] Split MachinePipeliner code into header and cpp ↵Aleksandr Urakov1-7/+598
files" This reverts commit 40760b733d9eef841c897338af5e9d81b12551bf. It seems that the commit is a cuse of the build failure. llvm-svn: 345032
2018-10-23[MachinePipeliner] Split MachinePipeliner code into header and cpp filesLama Saba1-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
2018-10-18[Pipeliner] copyToPhi DAG Mutation to improve scheduling.Sumanth Gundapaneni1-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
2018-10-11[Pipeliner] Use the Index from Topo instead of relying on NodeNum. (NFC)Sumanth Gundapaneni1-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
2018-10-11[Pipeliner] Fix the Schedule DAG topoligical order.Sumanth Gundapaneni1-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
2018-10-10Replace most users of UnknownSize with LocationSize::unknown(); NFCGeorge Burgess IV1-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
2018-09-27llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song1-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
2018-09-19ScheduleDAG: Cleanup dumping code; NFCMatthias Braun1-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
2018-08-27[Pipeliner] Fix incorrect phi values in the epilog and kernelBrendon Cahoon1-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
2018-08-20Consistently use MemoryLocation::UnknownSize to indicate unknown access sizeKrzysztof Parzyszek1-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
2018-08-16[MI] Change the array of `MachineMemOperand` pointers to beChandler Carruth1-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
2018-07-16[CodeGen] Fix inconsistent declaration parameter nameFangrui Song1-2/+2
llvm-svn: 337200
2018-06-20[NFC] fix trivial typos in commentsHiroshi Inoue1-8/+8
llvm-svn: 335096
2018-05-14Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen1-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
2018-04-30IWYU for llvm-config.h in llvm, additions.Nico Weber1-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
2018-04-13[NFC] fix trivial typos in commentsHiroshi Inoue1-1/+1
"the the" -> "the", "we we" -> "we", etc llvm-svn: 330006
generated by cgit v1.1 at 2025-10-08 14:43:06 +0000