summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAge
* Fix the header comment of the new pass manager stuff to not claim to beChandler Carruth2013-11-14
| | | | | | the legacy stuff. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194689 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64 neon] support poly64 and relevant intrinsic functions.Kevin Qin2013-11-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194659 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement aarch64 neon instruction class SIMD misc.Kevin Qin2013-11-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194656 91177308-0d34-0410-b5e6-96231b3b80d8
* Add dyn_cast<> support to YAML I/O's IO classNick Kledzik2013-11-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194655 91177308-0d34-0410-b5e6-96231b3b80d8
* Added BlockFrequencyInfo::view for displaying the block frequency ↵Michael Gottesman2013-11-14
| | | | | | | | | | propagation graph via graphviz. This is useful for debugging issues in the BlockFrequency implementation since one can easily visualize where probability mass and other errors occur in the propagation. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194654 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement AArch64 NEON instruction set AdvSIMD (table).Jiangning Liu2013-11-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194648 91177308-0d34-0410-b5e6-96231b3b80d8
* Add simple support for tags in YAML I/ONick Kledzik2013-11-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194644 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-cov: Slightly improved error checking.Yuchen Wu2013-11-14
| | | | | | | | - readInt() should check all 4 bytes can be read, not just 1. - In the event of false data in the gcno file, it was possible to index into a non-existent index of SmallVector, causing assertion error. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194639 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-cov: Removed StringMap holding GCOVLines.Yuchen Wu2013-11-14
| | | | | | | | | | | | | | | | | According to the hazy gcov documentation, it appeared to be technically possible for lines within a block to belong to different source files. However, upon further investigation, gcov does not actually support multiple source files for a single block. This change removes a level of separation between blocks and lines by replacing the StringMap of GCOVLines with a SmallVector of ints representing line numbers. This also means that the GCOVLines class is no longer needed. This paves the way for supporting the "-a" option, which will output block information. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194637 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-cov: Replaced asserts with proper error handling.Yuchen Wu2013-11-14
| | | | | | | | | | | | | | Unified the interface for read functions. They all return a boolean indicating if the read from file succeeded. Functions that previously returned the read value now store it into a variable that is passed in by reference instead. Callers will need to check the return value to detect if an error occurred. Also added a new test which ensures that no assertions occur when file contains invalid data. llvm-cov should return with error code 1 upon failure. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194635 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64] Add support for legacy AArch32 NEON scalar shift by immediateChad Rosier2013-11-13
| | | | | | | | instructions. This patch does not include the shift right and accumulate instructions. A number of non-overloaded intrinsics have been remove in favor of their overloaded counterparts. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194598 91177308-0d34-0410-b5e6-96231b3b80d8
* Make sure LLVMLoadLibraryPermanently gets an extern "C" symbol.Benjamin Kramer2013-11-13
| | | | | | | Otherwise it's impossible to use it. Also don't include C++ headers in a C header. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194581 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove AllowQuotesInName and friends from MCAsmInfo.Rafael Espindola2013-11-13
| | | | | | | | | | | Accepting quotes is a property of an assembler, not of an object file. For example, ELF can support any names for sections and symbols, but the gnu assembler only accepts quotes in some contexts and llvm-mc in a few more. LLVM should not produce different symbols based on a guess about which assembler will be reading the code it is printing. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194575 91177308-0d34-0410-b5e6-96231b3b80d8
* SampleProfileLoader pass. Initial setup.Diego Novillo2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new scalar pass that reads a file with samples generated by 'perf' during runtime. The samples read from the profile are incorporated and emmited as IR metadata reflecting that profile. The profile file is assumed to have been generated by an external profile source. The profile information is converted into IR metadata, which is later used by the analysis routines to estimate block frequencies, edge weights and other related data. External profile information files have no fixed format, each profiler is free to define its own. This includes both the on-disk representation of the profile and the kind of profile information stored in the file. A common kind of profile is based on sampling (e.g., perf), which essentially counts how many times each line of the program has been executed during the run. The SampleProfileLoader pass is organized as a scalar transformation. On startup, it reads the file given in -sample-profile-file to determine what kind of profile it contains. This file is assumed to contain profile information for the whole application. The profile data in the file is read and incorporated into the internal state of the corresponding profiler. To facilitate testing, I've organized the profilers to support two file formats: text and native. The native format is whatever on-disk representation the profiler wants to support, I think this will mostly be bitcode files, but it could be anything the profiler wants to support. To do this, every profiler must implement the SampleProfile::loadNative() function. The text format is mostly meant for debugging. Records are separated by newlines, but each profiler is free to interpret records as it sees fit. Profilers must implement the SampleProfile::loadText() function. Finally, the pass will call SampleProfile::emitAnnotations() for each function in the current translation unit. This function needs to translate the loaded profile into IR metadata, which the analyzer will later be able to use. This patch implements the first steps towards the above design. I've implemented a sample-based flat profiler. The format of the profile is fairly simplistic. Each sampled function contains a list of relative line locations (from the start of the function) together with a count representing how many samples were collected at that line during execution. I generate this profile using perf and a separate converter tool. Currently, I have only implemented a text format for these profiles. I am interested in initial feedback to the whole approach before I send the other parts of the implementation for review. This patch implements: - The SampleProfileLoader pass. - The base ExternalProfile class with the core interface. - A SampleProfile sub-class using the above interface. The profiler generates branch weight metadata on every branch instructions that matches the profiles. - A text loader class to assist the implementation of SampleProfile::loadText(). - Basic unit tests for the pass. Additionally, the patch uses profile information to compute branch weights based on instruction samples. This patch converts instruction samples into branch weights. It does a fairly simplistic conversion: Given a multi-way branch instruction, it calculates the weight of each branch based on the maximum sample count gathered from each target basic block. Note that this assignment of branch weights is somewhat lossy and can be misleading. If a basic block has more than one incoming branch, all the incoming branches will get the same weight. In reality, it may be that only one of them is the most heavily taken branch. I will adjust this assignment in subsequent patches. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194566 91177308-0d34-0410-b5e6-96231b3b80d8
* Add another (perhaps better) video for Sean's talk. (Thanks Marshall!)Chandler Carruth2013-11-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194549 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a null pointer dereference when copying a null polymorphic pointer.Chandler Carruth2013-11-13
| | | | | | | | This bug only bit the C++98 build bots because all of the actual uses really do move. ;] But not *quite* ready to do the whole C++11 switch yet, so clean it up. Also add a unit test that catches this immediately. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194548 91177308-0d34-0410-b5e6-96231b3b80d8
* Give folks a reference to some material on the fundamental designChandler Carruth2013-11-13
| | | | | | | pattern in use here. Addresses review feedback from Sean (thanks!) and others. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194541 91177308-0d34-0410-b5e6-96231b3b80d8
* Introduce an AnalysisManager which is like a pass manager but with a lotChandler Carruth2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | more smarts in it. This is where most of the interesting logic that used to live in the implicit-scheduling-hackery of the old pass manager will live. Like the previous commits, note that this is a very early prototype! I expect substantial changes before this is ready to use. The core of the design is the following: - We have an AnalysisManager which can be used across a series of passes over a module. - The code setting up a pass pipeline registers the analyses available with the manager. - Individual transform passes can check than an analysis manager provides the analyses they require in order to fail-fast. - There is *no* implicit registration or scheduling. - Analysis passes are different from other passes: they produce an analysis result that is cached and made available via the analysis manager. - Cached results are invalidated automatically by the pass managers. - When a transform pass requests an analysis result, either the analysis is run to produce the result or a cached result is provided. There are a few aspects of this design that I *know* will change in subsequent commits: - Currently there is no "preservation" system, that needs to be added. - All of the analysis management should move up to the analysis library. - The analysis management needs to support at least SCC passes. Maybe loop passes. Living in the analysis library will facilitate this. - Need support for analyses which are *both* module and function passes. - Need support for pro-actively running module analyses to have cached results within a function pass manager. - Need a clear design for "immutable" passes. - Need support for requesting cached results when available and not re-running the pass even if that would be necessary. - Need more thorough testing of all of this infrastructure. There are other aspects that I view as open questions I'm hoping to resolve as I iterate a bit on the infrastructure, and especially as I start writing actual passes against this. - Should we have separate management layers for function, module, and SCC analyses? I think "yes", but I'm not yet ready to switch the code. Adding SCC support will likely resolve this definitively. - How should the 'require' functionality work? Should *that* be the only way to request results to ensure that passes always require things? - How should preservation work? - Probably some other things I'm forgetting. =] Look forward to more patches in shorter order now that this is in place. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194538 91177308-0d34-0410-b5e6-96231b3b80d8
* Removing llvm::huge_vald and llvm::huge_vall because they are not currently ↵Aaron Ballman2013-11-13
| | | | | | used, and HUGE_VALD does not appear to be supported everywhere anyways. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194535 91177308-0d34-0410-b5e6-96231b3b80d8
* Replacing HUGE_VALF with llvm::huge_valf in order to work around a warning ↵Aaron Ballman2013-11-13
| | | | | | | | triggered in MSVC 12. Patch reviewed by Reid Kleckner and Jim Grosbach. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194533 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove always true flag.Rafael Espindola2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194530 91177308-0d34-0410-b5e6-96231b3b80d8
* delinearization of arraysSebastian Pop2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194527 91177308-0d34-0410-b5e6-96231b3b80d8
* remove virtual methods in SCEVApplyRewriter and SCEVParameterRewriterSebastian Pop2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194526 91177308-0d34-0410-b5e6-96231b3b80d8
* Protect user-supplied runtime library functions in LTOJustin Bogner2013-11-12
| | | | | | | | | | | | | | Add user-supplied C runtime and compiler-rt library functions to llvm.compiler.used to protect them from premature optimization by passes like -globalopt and -ipsccp. Calls to (seemingly unused) runtime library functions can be added by -instcombine and instruction lowering. Patch by Duncan Exon Smith, thanks! Fixes <rdar://problem/14740087> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194514 91177308-0d34-0410-b5e6-96231b3b80d8
* Export intrinsics:__builtin_arm_{dmb,dsb} to frontendWeiming Zhao2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194505 91177308-0d34-0410-b5e6-96231b3b80d8
* GraphViz CFGPrinter: wrap long lines.Andrew Trick2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194496 91177308-0d34-0410-b5e6-96231b3b80d8
* whitespaceAndrew Trick2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194495 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Remove unused variable."Rafael Espindola2013-11-12
| | | | | | | | | This reverts commit r194485. The variable is unused in some macro instantiations, but not others. We should probably fix clang to not warn on this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194486 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unused variable.Rafael Espindola2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194485 91177308-0d34-0410-b5e6-96231b3b80d8
* Change data structure to memorize computed result in ScalarEvolutionWan Xiaofei2013-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace std::map with SmallVector to memorize the cached result since SCEV usually belongs to little Loop/BB Linear scan on SmallVector is faster than std::map. Code reviewer : Andrew Trick. Test result : Pass Unit Test & LLVM Test Suite 401.bzip2 0.425721 0.419981 101.37% 403.gcc 24.53855 24.2667 101.12% 429.mcf 0.060847 0.059944 101.51% 433.milc 0.646009 0.636119 101.55% 444.namd 1.383928 1.370614 100.97% 445.gobmk 5.836575 5.800225 100.63% 450.soplex 1.911257 1.895963 100.81% 456.hmmer 1.039565 1.032534 100.68% 458.sjeng 0.897401 0.885567 101.34% 464.h264ref 3.645908 3.577991 101.90% 470.lbm 0.049456 0.048398 102.19% 471.omnetpp 5.638575 5.60435 100.61% bitmnp01 0.045738 0.045291 100.99% cjpegv2data 0.304359 0.302833 100.50% idctrn01 0.046433 0.045763 101.46% quake2 4.534416 4.4952 100.87% quake 2.688566 2.659208 101.10% xcsoar 12.42545 12.30385 100.99% linpack 0.038739 0.03803 101.86% matrix01 0.053564 0.0528 101.45% nbench 0.402867 0.395803 101.78% tblook01 0.021265 0.021015 101.19% ttsprk01 0.066384 0.065566 101.25% git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194459 91177308-0d34-0410-b5e6-96231b3b80d8
* CalcSpillWeights: allow overidding the spill weight normalizing functionArnaud A. de Grandmaison2013-11-11
| | | | | | | | This will enable the PBQP register allocator to provide its own normalizing function. No functionnal change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194417 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64] The shift right/left and insert immediate builtins expect 3Chad Rosier2013-11-11
| | | | | | source operands, a vector, an element to insert, and a shift amount. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194406 91177308-0d34-0410-b5e6-96231b3b80d8
* CalcSpillWeights: give a better describing name to calculateSpillWeightsArnaud A. de Grandmaison2013-11-11
| | | | | | | | Besides, this relates it more obviously to the VirtRegAuxInfo::calculateSpillWeightAndHint. No functionnal change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194404 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64] Add support for NEON scalar floating-point convert to fixed-point ↵Chad Rosier2013-11-11
| | | | | | instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194394 91177308-0d34-0410-b5e6-96231b3b80d8
* [llvm-c] Remove dead typedefPeter Zotov2013-11-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194379 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't universally enable initialiser lists on GCC. Thanks for catching this ↵Pete Cooper2013-11-11
| | | | | | Chandler git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194365 91177308-0d34-0410-b5e6-96231b3b80d8
* Add LLVM_HAS_INITIALIZER_LISTS for upcoming C++11 support. Use it in ArrayRefPete Cooper2013-11-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194362 91177308-0d34-0410-b5e6-96231b3b80d8
* CalculateSpillWeights does not need to be a passArnaud A. de Grandmaison2013-11-10
| | | | | | | | | | Based on discussions with Lang Hames and Jakob Stoklund Olesen at the hacker's lab, and in the light of upcoming work on the PBQP register allocator, it was though that CalcSpillWeights does not need to be a pass. This change will enable to customize / tune the spill weight computation depending on the allocator. Update the documentation style while there. No functionnal change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194356 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Start sketching out the new module and function pass manager.Chandler Carruth2013-11-09
| | | | | | | | | | | | | | | | | | This is still just a skeleton. I'm trying to pull together the experimentation I've done into committable chunks, and this is the first coherent one. Others will follow in hopefully short order that move this more toward a useful initial implementation. I still expect the design to continue evolving in small ways as I work through the different requirements and features needed here though. Keep in mind, all of this is off by default. Currently, this mostly exercises the use of a polymorphic smart pointer and templates to hide the polymorphism for the pass manager from the pass implementation. The next step will be more significant, adding the first framework of analysis support. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194325 91177308-0d34-0410-b5e6-96231b3b80d8
* Move the old pass manager infrastructure into a legacy namespace andChandler Carruth2013-11-09
| | | | | | | | | | | | | | | | | | | give the files a legacy prefix in the right directory. Use forwarding headers in the old locations to paper over the name change for most clients during the transitional period. No functionality changed here! This is just clearing some space to reduce renaming churn later on with a new system. Even when the new stuff starts to go in, it is going to be hidden behind a flag and off-by-default as it is still WIP and under development. This patch is specifically designed so that very little out-of-tree code has to change. I'm going to work as hard as I can to keep that the case. Only direct forward declarations of the PassManager class are impacted by this change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194324 91177308-0d34-0410-b5e6-96231b3b80d8
* This exposes the new calling conventions (WebKit_JS and AnyReg) via the C ↵Filip Pizlo2013-11-09
| | | | | | API by adding them to the enumeration in Core.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194323 91177308-0d34-0410-b5e6-96231b3b80d8
* Switch to allow implicit construction. In many cases, we're wrappingChandler Carruth2013-11-09
| | | | | | a derived type and this makes it *much* easier to write this code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194321 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a polymorphic_ptr<T> smart pointer data type. It's a somewhat sillyChandler Carruth2013-11-09
| | | | | | | | | | | | unique ownership smart pointer which is *deep* copyable by assuming it can call a T::clone() method to allocate a copy of the owned data. This is mostly useful with containers or other collections of uniquely owned data in C++98 where they *might* copy. With C++11 we can likely remove this in favor of move-only types and containers wrapped around those types. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194315 91177308-0d34-0410-b5e6-96231b3b80d8
* include/llvm/CodeGen/PBQP: Update @param(s) in comments. [-Wdocumentation]NAKAMURA Takumi2013-11-09
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194314 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix whitespace.NAKAMURA Takumi2013-11-09
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194313 91177308-0d34-0410-b5e6-96231b3b80d8
* Re-apply r194300 with fixes for warnings.Lang Hames2013-11-09
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194311 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r194300 which broke the build.Nick Lewycky2013-11-09
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194308 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmap] Materialize the jump address within the patchpoint noop slide.Juergen Ributzka2013-11-09
| | | | | | | | | | | | | | | This patch moves the jump address materialization inside the noop slide. This enables patching of the materialization itself or its complete removal. This patch also adds the ability to define scratch registers that can be used safely by the code called from the patchpoint intrinsic. At least one scratch register is required, because that one is used for the materialization of the jump address. This patch depends on D2009. Differential Revision: http://llvm-reviews.chandlerc.com/D2074 Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194306 91177308-0d34-0410-b5e6-96231b3b80d8
* Rewrite the PBQP graph data structure.Lang Hames2013-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new graph structure replaces the node and edge linked lists with vectors. Free lists (well, free vectors) are used for fast insertion/deletion. The ultimate aim is to make PBQP graphs cheap to clone. The motivation is that the PBQP solver destructively consumes input graphs while computing a solution, forcing the graph to be fully reconstructed for each round of PBQP. This imposes a high cost on large functions, which often require several rounds of solving/spilling to find a final register allocation. If we can cheaply clone the PBQP graph and incrementally update it between rounds then hopefully we can reduce this cost. Further, once we begin pooling matrix/vector values (future work), we can cache some PBQP solver metadata and share it between cloned graphs, allowing the PBQP solver to re-use some of the computation done in earlier rounds. For now this is just a data structure update. The allocator and solver still use the graph the same way as before, fully reconstructing it between each round. I expect no material change from this update, although it may change the iteration order of the nodes, causing ties in the solver to break in different directions, and this could perturb the generated allocations (hopefully in a completely benign way). Thanks very much to Arnaud Allard de Grandmaison for encouraging me to get back to work on this, and for a lot of discussion and many useful PBQP test cases. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194300 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.Juergen Ributzka2013-11-08
| | | | | | | | | | | | | | The idea of the AnyReg Calling Convention is to provide the call arguments in registers, but not to force them to be placed in a paticular order into a specified set of registers. Instead it is up tp the register allocator to assign any register as it sees fit. The same applies to the return value (if applicable). Differential Revision: http://llvm-reviews.chandlerc.com/D2009 Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194293 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-29 01:56:03 +0000