summaryrefslogtreecommitdiff
path: root/lib/CodeGen/CMakeLists.txt
Commit message (Collapse)AuthorAge
* Move GlobalMerge from Transform to CodeGen.Jiangning Liu2014-06-13
| | | | | | | | | | | This patch is to move GlobalMerge pass from Transform/Scalar to CodeGen, because GlobalMerge depends on TargetMachine. In the mean time, the macro INITIALIZE_TM_PASS is also moved to CodeGen/Passes.h. With this fix we can avoid making libScalarOpts depend on libCodeGen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210951 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a new attribute called 'jumptable' that creates jump-instruction tables ↵Tom Roeder2014-06-05
| | | | | | | | | | | | | for functions marked with this attribute. It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables. This also adds backend support for generating the jump-instruction tables on ARM and X86. Note that since the jumptable attribute creates a second function pointer for a function, any function marked with jumptable must also be marked with unnamed_addr. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210280 91177308-0d34-0410-b5e6-96231b3b80d8
* Atomics: promote ARM's IR-based atomics pass to CodeGen.Tim Northover2014-04-17
| | | | | | | | | | | | Still only 32-bit ARM using it at this stage, but the promotion allows direct testing via opt and is a reasonably self-contained patch on the way to switching ARM64. At this point, other targets should be able to make use of it without too much difficulty if they want. (See ARM64 commit coming soon for an example). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206485 91177308-0d34-0410-b5e6-96231b3b80d8
* [CodeGenPrepare] Move CodeGenPrepare into lib/CodeGen.Quentin Colombet2014-02-22
| | | | | | | | | | | | | CodeGenPrepare uses extensively TargetLowering which is part of libLLVMCodeGen. This is a layer violation which would introduce eventually a dependence on CodeGen in ScalarOpts. Move CodeGenPrepare into libLLVMCodeGen to avoid that. Follow-up of <rdar://problem/15519855> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201912 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmap] Liveness Analysis PassJuergen Ributzka2013-12-14
| | | | | | | | | | | | | | | | | | | | This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197317 91177308-0d34-0410-b5e6-96231b3b80d8
* Convert register liveness tracking to work on a sub-register level instead ↵Juergen Ributzka2013-12-14
| | | | | | | | of just register units. Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197315 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Convert liveness tracking to work on a sub-register level instead of ↵Andrew Trick2013-12-13
| | | | | | | | | | just register units." This reverts commit r197253. This was a great change, but Juergen should be the commit author. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197262 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Liveness Analysis Pass"Andrew Trick2013-12-13
| | | | | | | | | | | | | | This reverts commit r197254. This was an accidental merge of Juergen's patch. It will be checked in shortly, but wasn't meant to go in quite yet. Conflicts: include/llvm/CodeGen/StackMaps.h lib/CodeGen/StackMaps.cpp test/CodeGen/X86/stackmap-liveness.ll git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197260 91177308-0d34-0410-b5e6-96231b3b80d8
* Liveness Analysis PassAndrew Trick2013-12-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197254 91177308-0d34-0410-b5e6-96231b3b80d8
* Convert liveness tracking to work on a sub-register level instead of just ↵Andrew Trick2013-12-13
| | | | | | register units. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197253 91177308-0d34-0410-b5e6-96231b3b80d8
* Add support for stack map generation in the X86 backend.Andrew Trick2013-10-31
| | | | | | Originally implemented by Lang Hames. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193811 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the --shrink-wrap option.Rafael Espindola2013-10-31
| | | | | | It had no tests, was unused and was "experimental at best". git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193749 91177308-0d34-0410-b5e6-96231b3b80d8
* Move LiveRegUnits implementation into .cpp. Comment and format.Andrew Trick2013-10-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192621 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the now unused strong phi elimination pass.Rafael Espindola2013-10-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192604 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the old CodePlacementOpt pass.Benjamin Kramer2013-03-29
| | | | | | It was superseded by MachineBlockPlacement and disabled by default since LLVM 3.1. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178349 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach cmake about the new Erlang GC files.Duncan Sands2013-03-25
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177869 91177308-0d34-0410-b5e6-96231b3b80d8
* Split TargetLowering into a CodeGen and a SelectionDAG part.Benjamin Kramer2013-01-11
| | | | | | | | | This fixes some of the cycles between libCodeGen and libSelectionDAG. It's still a complete mess but as long as the edges consist of virtual call it doesn't cause breakage. BasicTTI did static calls and thus broke some build configurations. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172246 91177308-0d34-0410-b5e6-96231b3b80d8
* Switch TargetTransformInfo from an immutable analysis pass that requiresChandler Carruth2013-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a TargetMachine to construct (and thus isn't always available), to an analysis group that supports layered implementations much like AliasAnalysis does. This is a pretty massive change, with a few parts that I was unable to easily separate (sorry), so I'll walk through it. The first step of this conversion was to make TargetTransformInfo an analysis group, and to sink the nonce implementations in ScalarTargetTransformInfo and VectorTargetTranformInfo into a NoTargetTransformInfo pass. This allows other passes to add a hard requirement on TTI, and assume they will always get at least on implementation. The TargetTransformInfo analysis group leverages the delegation chaining trick that AliasAnalysis uses, where the base class for the analysis group delegates to the previous analysis *pass*, allowing all but tho NoFoo analysis passes to only implement the parts of the interfaces they support. It also introduces a new trick where each pass in the group retains a pointer to the top-most pass that has been initialized. This allows passes to implement one API in terms of another API and benefit when some other pass above them in the stack has more precise results for the second API. The second step of this conversion is to create a pass that implements the TargetTransformInfo analysis using the target-independent abstractions in the code generator. This replaces the ScalarTargetTransformImpl and VectorTargetTransformImpl classes in lib/Target with a single pass in lib/CodeGen called BasicTargetTransformInfo. This class actually provides most of the TTI functionality, basing it upon the TargetLowering abstraction and other information in the target independent code generator. The third step of the conversion adds support to all TargetMachines to register custom analysis passes. This allows building those passes with access to TargetLowering or other target-specific classes, and it also allows each target to customize the set of analysis passes desired in the pass manager. The baseline LLVMTargetMachine implements this interface to add the BasicTTI pass to the pass manager, and all of the tools that want to support target-aware TTI passes call this routine on whatever target machine they end up with to add the appropriate passes. The fourth step of the conversion created target-specific TTI analysis passes for the X86 and ARM backends. These passes contain the custom logic that was previously in their extensions of the ScalarTargetTransformInfo and VectorTargetTransformInfo interfaces. I separated them into their own file, as now all of the interface bits are private and they just expose a function to create the pass itself. Then I extended these target machines to set up a custom set of analysis passes, first adding BasicTTI as a fallback, and then adding their customized TTI implementations. The fourth step required logic that was shared between the target independent layer and the specific targets to move to a different interface, as they no longer derive from each other. As a consequence, a helper functions were added to TargetLowering representing the common logic needed both in the target implementation and the codegen implementation of the TTI pass. While technically this is the only change that could have been committed separately, it would have been a nightmare to extract. The final step of the conversion was just to delete all the old boilerplate. This got rid of the ScalarTargetTransformInfo and VectorTargetTransformInfo classes, all of the support in all of the targets for producing instances of them, and all of the support in the tools for manually constructing a pass based around them. Now that TTI is a relatively normal analysis group, two things become straightforward. First, we can sink it into lib/Analysis which is a more natural layer for it to live. Second, clients of this interface can depend on it *always* being available which will simplify their code and behavior. These (and other) simplifications will follow in subsequent commits, this one is clearly big enough. Finally, I'm very aware that much of the comments and documentation needs to be updated. As soon as I had this working, and plausibly well commented, I wanted to get it committed and in front of the build bots. I'll be doing a few passes over documentation later if it sticks. Commits to update DragonEgg and Clang will be made presently. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171681 91177308-0d34-0410-b5e6-96231b3b80d8
* Move the guts of TargetInstrInfoImpl into the TargetInstrInfo class.Jakob Stoklund Olesen2012-11-28
| | | | | | | The *Impl class no longer serves a purpose now that the super-class implementation is in CodeGen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168759 91177308-0d34-0410-b5e6-96231b3b80d8
* Move Target{Instr,Register}Info.cpp into lib/CodeGen.Jakob Stoklund Olesen2012-11-28
| | | | | | | | | | | | | | | | The Target library is not allowed to depend on the large CodeGen library, but the TRI and TII classes provide abstract interfaces that require both caller and callee to link to CodeGen. The implementation files for these classes provide default implementations of some of the hooks. These methods may need to reference CodeGen, so they belong in that library. We already have a number of methods implemented in the TargetInstrInfoImpl sub-class because of that. I will merge that class into the parent next. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168758 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unused MachineLoopRanges analysis.Jakub Staszak2012-11-27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168659 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a MachinePostDominator passTom Stellard2012-09-17
| | | | | | This is used in the AMDIL and R600 backends. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164029 91177308-0d34-0410-b5e6-96231b3b80d8
* TargetSchedModel interface. To be implemented...Andrew Trick2012-09-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163934 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a new optimization pass: Stack Coloring, that merges disjoint static ↵Nadav Rotem2012-09-06
| | | | | | | | | | allocations (allocas). Allocas are known to be disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163299 91177308-0d34-0410-b5e6-96231b3b80d8
* Start scaffolding for a MachineTraceMetrics analysis pass.Jakob Stoklund Olesen2012-07-26
| | | | | | | | | | | | | | | | | | | | | | | | This is still a work in progress. Out-of-order CPUs usually execute instructions from multiple basic blocks simultaneously, so it is necessary to look at longer traces when estimating the performance effects of code transformations. The MachineTraceMetrics analysis will pick a typical trace through a given basic block and provide performance metrics for the trace. Metrics will include: - Instruction count through the trace. - Issue count per functional unit. - Critical path length, and per-instruction 'slack'. These metrics can be used to determine the performance limiting factor when executing the trace, and how it will be affected by a code transformation. Initially, this will be used by the early if-conversion pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160796 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an experimental early if-conversion pass, off by default.Jakob Stoklund Olesen2012-07-04
| | | | | | | | | | | | | This pass performs if-conversion on SSA form machine code by speculatively executing both sides of the branch and using a cmov instruction to select the result. This can help lower the number of branch mispredictions on architectures like x86 that don't have predicable instructions. The current implementation is very aggressive, and causes regressions on mosts tests. It needs good heuristics that have yet to be implemented. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159694 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm/lib: [CMake] Add explicit dependency to intrinsics_gen.NAKAMURA Takumi2012-06-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159112 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the RenderMachineFunction HTML output pass.Jakob Stoklund Olesen2012-06-20
| | | | | | | I don't think anyone has been using this functionality for a while, and it is getting in the way of refactoring now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158876 91177308-0d34-0410-b5e6-96231b3b80d8
* Sketch a LiveRegMatrix analysis pass.Jakob Stoklund Olesen2012-06-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The LiveRegMatrix represents the live range of assigned virtual registers in a Live interval union per register unit. This is not fundamentally different from the interference tracking in RegAllocBase that both RABasic and RAGreedy use. The important differences are: - LiveRegMatrix tracks interference per register unit instead of per physical register. This makes interference checks cheaper and assignments slightly more expensive. For example, the ARM D7 reigster has 24 aliases, so we would check 24 physregs before assigning to one. With unit-based interference, we check 2 units before assigning to 2 units. - LiveRegMatrix caches regmask interference checks. That is currently duplicated functionality in RABasic and RAGreedy. - LiveRegMatrix is a pass which makes it possible to insert target-dependent passes between register allocation and rewriting. Such passes could tweak the register assignments with interference checking support from LiveRegMatrix. Eventually, RABasic and RAGreedy will be switched to LiveRegMatrix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158255 91177308-0d34-0410-b5e6-96231b3b80d8
* cmake: new fileAndrew Trick2012-04-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155460 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix cmakeAndrew Trick2012-03-07
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152210 91177308-0d34-0410-b5e6-96231b3b80d8
* Added the MachineSchedulerPass skeleton.Andrew Trick2012-01-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148105 91177308-0d34-0410-b5e6-96231b3b80d8
* Move RegAllocBase into its own cpp file separate from RABasic.Jakob Stoklund Olesen2012-01-11
| | | | | | No functional change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147972 91177308-0d34-0410-b5e6-96231b3b80d8
* Added a late machine instruction copy propagation pass. This catchesEvan Cheng2012-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | opportunities that only present themselves after late optimizations such as tail duplication .e.g. ## BB#1: movl %eax, %ecx movl %ecx, %eax ret The register allocator also leaves some of them around (due to false dep between copies from phi-elimination, etc.) This required some changes in codegen passes. Post-ra scheduler and the pseudo-instruction expansion passes have been moved after branch folding and tail merging. They were before branch folding before because it did not always update block livein's. That's fixed now. The pass change makes independently since we want to properly schedule instructions after branch folding / tail duplication. rdar://10428165 rdar://10640363 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147716 91177308-0d34-0410-b5e6-96231b3b80d8
* Kill ObjectCodeEmitter and BinaryObject, they were unused and superseded by MC.Benjamin Kramer2012-01-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147618 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the old ELF writer.Rafael Espindola2012-01-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147615 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix up the CMake build for the new files added in r146960, they'reChandler Carruth2011-12-20
| | | | | | likely to stay either way that discussion ends up resolving itself. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146966 91177308-0d34-0410-b5e6-96231b3b80d8
* Move parts of lib/Target that use CodeGen into lib/CodeGen.Nick Lewycky2011-12-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146702 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm/lib/CodeGen: Fix cmake build since r146542.NAKAMURA Takumi2011-12-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146550 91177308-0d34-0410-b5e6-96231b3b80d8
* Kill off the LoopSplitter. It's not being used or maintained.Lang Hames2011-12-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145897 91177308-0d34-0410-b5e6-96231b3b80d8
* CodeGen: fix CMake buildDylan Noblesmith2011-12-01
| | | | | | Missing file from r145629. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145634 91177308-0d34-0410-b5e6-96231b3b80d8
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145420 91177308-0d34-0410-b5e6-96231b3b80d8
* Delete VirtRegRewriter.Jakob Stoklund Olesen2011-11-13
| | | | | | And there was much rejoicing. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144480 91177308-0d34-0410-b5e6-96231b3b80d8
* Delete the linear scan register allocator.Jakob Stoklund Olesen2011-11-12
| | | | | | | | | RegAllocGreedy has been the default for six months now. Deleting RegAllocLinearScan makes it possible to also delete VirtRegRewriter and clean up the spiller code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144475 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement a block placement pass based on the branch probability andChandler Carruth2011-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | block frequency analyses. This differs substantially from the existing block-placement pass in LLVM: 1) It operates on the Machine-IR in the CodeGen layer. This exposes much more (and more precise) information and opportunities. Also, the results are more stable due to fewer transforms ocurring after the pass runs. 2) It uses the generalized probability and frequency analyses. These can model static heuristics, code annotation derived heuristics as well as eventual profile loading. By basing the optimization on the analysis interface it can work from any (or a combination) of these inputs. 3) It uses a more aggressive algorithm, both building chains from tho bottom up to maximize benefit, and using an SCC-based walk to layout chains of blocks in a profitable ordering without O(N^2) iterations which the old pass involves. The pass is currently gated behind a flag, and not enabled by default because it still needs to grow some important features. Most notably, it needs to support loop aligning and careful layout of loop structures much as done by hand currently in CodePlacementOpt. Once it supports these, and has sufficient testing and quality tuning, it should replace both of these passes. Thanks to Nick Lewycky and Richard Smith for help authoring & debugging this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm forgetting for reviewing and answering all my questions. Writing a backend pass is *sooo* much better now than it used to be. =D git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142641 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename SSEDomainFix -> lib/CodeGen/ExecutionDepsFix.Jakob Stoklund Olesen2011-09-28
| | | | | | I'll clean up the source in the next commit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140663 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename LowerSubregs to ExpandPostRAPseudos.Jakob Stoklund Olesen2011-09-25
| | | | | | | | | | | | | | I'll fix the file contents in the next commit. This pass is currently expanding the COPY and SUBREG_TO_REG pseudos. I am going to add a hook so targets can expand more pseudo-instructions after register allocation. Many targets have pseudo-instructions that assist the register allocator. They can be expanded after register allocation, before PEI and PostRA scheduling. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140469 91177308-0d34-0410-b5e6-96231b3b80d8
* Extract live range calculations from SplitKit.Jakob Stoklund Olesen2011-09-13
| | | | | | | | SplitKit will soon need two copies of these data structures, and the algorithms will also be useful when LiveIntervalAnalysis becomes independent of LiveVariables. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139572 91177308-0d34-0410-b5e6-96231b3b80d8
* Provide utility to extract and use lexical scoping information from machine ↵Devang Patel2011-08-10
| | | | | | instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137237 91177308-0d34-0410-b5e6-96231b3b80d8
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified in the same file that the library itself is created. This is more idiomatic for CMake builds, and also allows us to correctly specify dependencies that are missed due to bugs in the GenLibDeps perl script, or change from compiler to compiler. On Linux, this returns CMake to a place where it can relably rebuild several targets of LLVM. I have tried not to change the dependencies from the ones in the current auto-generated file. The only places I've really diverged are in places where I was seeing link failures, and added a dependency. The goal of this patch is not to start changing the dependencies, merely to move them into the correct location, and an explicit form that we can control and change when necessary. This also removes a serialization point in the build because we don't have to scan all the libraries before we begin building various tools. We no longer have a step of the build that regenerates a file inside the source tree. A few other associated cleanups fall out of this. This isn't really finished yet though. After talking to dgregor he urged switching to a single CMake macro to construct libraries with both sources and dependencies in the arguments. Migrating from the two macros to that style will be a follow-up patch. Also, llvm-config is still generated with GenLibDeps.pl, which means it still has slightly buggy dependencies. The internal CMake 'llvm-config-like' macro uses the correct explicitly specified dependencies however. A future patch will switch llvm-config generation (when using CMake) to be based on these deps as well. This may well break Windows. I'm getting a machine set up now to dig into any failures there. If anyone can chime in with problems they see or ideas of how to solve them for Windows, much appreciated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136433 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-31 04:12:09 +0000