From 097a140d792de8b2bbe59ad827d39eabf9b4280a Mon Sep 17 00:00:00 2001 From: patrick Date: Wed, 28 Apr 2021 12:27:20 +0000 Subject: [PATCH] Import LLVM 11.1.0 release including clang, lld and lldb. --- gnu/llvm/llvm/.clang-tidy | 2 + gnu/llvm/llvm/.gitattributes | 19 + gnu/llvm/llvm/.gitignore | 83 + gnu/llvm/llvm/CMakeLists.txt | 187 +- gnu/llvm/llvm/CODE_OWNERS.TXT | 16 +- gnu/llvm/llvm/README.txt | 1 - gnu/llvm/llvm/bindings/go/llvm/dibuilder.go | 8 + gnu/llvm/llvm/bindings/go/llvm/ir.go | 32 +- gnu/llvm/llvm/bindings/go/llvm/string.go | 6 +- .../bindings/go/llvm/transforms_pmbuilder.go | 5 + gnu/llvm/llvm/cmake/config-ix.cmake | 10 +- gnu/llvm/llvm/cmake/config.guess | 41 + gnu/llvm/llvm/cmake/modules/AddLLVM.cmake | 341 +- .../llvm/cmake/modules/AddSphinxTarget.cmake | 8 +- gnu/llvm/llvm/cmake/modules/CMakeLists.txt | 18 + gnu/llvm/llvm/cmake/modules/CheckAtomic.cmake | 43 +- .../llvm/cmake/modules/CrossCompile.cmake | 14 +- gnu/llvm/llvm/cmake/modules/FindGRPC.cmake | 83 + gnu/llvm/llvm/cmake/modules/FindZ3.cmake | 2 +- .../llvm/cmake/modules/GetHostTriple.cmake | 10 +- .../cmake/modules/HandleLLVMOptions.cmake | 156 +- gnu/llvm/llvm/cmake/modules/LLVM-Config.cmake | 7 - .../llvm/cmake/modules/LLVMConfig.cmake.in | 14 +- .../modules/LLVMExternalProjectUtils.cmake | 40 +- .../cmake/modules/LLVMProcessSources.cmake | 8 +- gnu/llvm/llvm/cmake/modules/TableGen.cmake | 30 +- .../cmake/modules/TensorFlowCompile.cmake | 38 + .../llvm/cmake/modules/VersionFromVCS.cmake | 4 +- gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst | 4 +- .../llvm/docs/AMDGPU/AMDGPUAsmGFX1011.rst | 92 + gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst | 4 +- gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst | 4 +- gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst | 4 +- gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst | 4 +- gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst | 4 +- gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst | 12 +- gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst | 74 +- gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_0.rst | 17 + gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_1.rst | 17 + .../llvm/docs/AMDGPU/gfx1011_type_dev.rst | 13 + .../llvm/docs/AMDGPU/gfx1011_vdst32_0.rst | 17 + .../llvm/docs/AMDGPU/gfx1011_vsrc32_0.rst | 17 + .../docs/AMDGPU/gfx908_saddr_flat_global.rst | 2 +- ...DwarfProposalForHeterogeneousDebugging.rst | 3896 ++ gnu/llvm/llvm/docs/AMDGPUUsage.rst | 1701 +- gnu/llvm/llvm/docs/AliasAnalysis.rst | 18 +- gnu/llvm/llvm/docs/Atomics.rst | 2 +- gnu/llvm/llvm/docs/BigEndianNEON.rst | 2 +- gnu/llvm/llvm/docs/BitCodeFormat.rst | 17 + .../llvm/docs/BlockFrequencyTerminology.rst | 2 +- gnu/llvm/llvm/docs/BranchWeightMetadata.rst | 64 +- gnu/llvm/llvm/docs/Bugpoint.rst | 2 +- gnu/llvm/llvm/docs/BuildingADistribution.rst | 1 - gnu/llvm/llvm/docs/CMake.rst | 18 +- gnu/llvm/llvm/docs/CMakePrimer.rst | 2 +- gnu/llvm/llvm/docs/CodeGenerator.rst | 4 +- gnu/llvm/llvm/docs/CodeReview.rst | 237 + gnu/llvm/llvm/docs/CodingStandards.rst | 209 +- gnu/llvm/llvm/docs/CommandGuide/FileCheck.rst | 216 +- gnu/llvm/llvm/docs/CommandGuide/dsymutil.rst | 77 +- gnu/llvm/llvm/docs/CommandGuide/lit.rst | 53 +- gnu/llvm/llvm/docs/CommandGuide/llc.rst | 8 + .../llvm/docs/CommandGuide/llvm-addr2line.rst | 21 +- .../llvm/docs/CommandGuide/llvm-cxxfilt.rst | 13 +- .../llvm/docs/CommandGuide/llvm-dwarfdump.rst | 33 +- .../llvm/docs/CommandGuide/llvm-exegesis.rst | 20 +- .../llvm/docs/CommandGuide/llvm-extract.rst | 30 + gnu/llvm/llvm/docs/CommandGuide/llvm-lipo.rst | 2 +- .../llvm/docs/CommandGuide/llvm-locstats.rst | 18 + gnu/llvm/llvm/docs/CommandGuide/llvm-mca.rst | 10 +- gnu/llvm/llvm/docs/CommandGuide/llvm-nm.rst | 6 +- .../llvm/docs/CommandGuide/llvm-objcopy.rst | 76 +- .../llvm/docs/CommandGuide/llvm-objdump.rst | 26 +- .../llvm/docs/CommandGuide/llvm-profdata.rst | 41 +- .../llvm/docs/CommandGuide/llvm-readelf.rst | 2 +- .../llvm/docs/CommandGuide/llvm-readobj.rst | 2 +- gnu/llvm/llvm/docs/CommandGuide/llvm-size.rst | 2 +- .../llvm/docs/CommandGuide/llvm-strings.rst | 2 +- .../llvm/docs/CommandGuide/llvm-strip.rst | 14 +- .../docs/CommandGuide/llvm-symbolizer.rst | 124 +- .../docs/CommandGuide/locstats-compare.png | Bin 0 -> 58210 bytes gnu/llvm/llvm/docs/CommandGuide/tblgen.rst | 2 +- gnu/llvm/llvm/docs/CompileCudaWithLLVM.rst | 39 +- gnu/llvm/llvm/docs/Contributing.rst | 7 + gnu/llvm/llvm/docs/CoverageMappingFormat.rst | 159 +- gnu/llvm/llvm/docs/DependenceGraphs/index.rst | 2 +- gnu/llvm/llvm/docs/DeveloperPolicy.rst | 299 +- gnu/llvm/llvm/docs/Docker.rst | 4 +- gnu/llvm/llvm/docs/ExceptionHandling.rst | 14 +- gnu/llvm/llvm/docs/Extensions.rst | 12 +- gnu/llvm/llvm/docs/FAQ.rst | 8 +- .../llvm/docs/Frontend/PerformanceTips.rst | 6 +- gnu/llvm/llvm/docs/FuzzingLLVM.rst | 2 +- gnu/llvm/llvm/docs/GarbageCollection.rst | 4 +- gnu/llvm/llvm/docs/GettingInvolved.rst | 14 +- gnu/llvm/llvm/docs/GettingStarted.rst | 154 +- gnu/llvm/llvm/docs/GettingStartedVS.rst | 17 +- gnu/llvm/llvm/docs/GitBisecting.rst | 125 + gnu/llvm/llvm/docs/GlobalISel/GMIR.rst | 2 +- .../llvm/docs/GlobalISel/GenericOpcode.rst | 40 +- .../llvm/docs/GlobalISel/IRTranslator.rst | 2 +- gnu/llvm/llvm/docs/GlobalISel/KnownBits.rst | 2 +- gnu/llvm/llvm/docs/GwpAsan.rst | 2 +- .../2007-OriginalClangReadme.txt | 2 +- gnu/llvm/llvm/docs/HowToAddABuilder.rst | 6 +- gnu/llvm/llvm/docs/HowToBuildOnARM.rst | 4 +- .../docs/HowToCrossCompileBuiltinsOnArm.rst | 2 +- gnu/llvm/llvm/docs/HowToCrossCompileLLVM.rst | 4 +- .../llvm/docs/HowToSetUpLLVMStyleRTTI.rst | 61 +- gnu/llvm/llvm/docs/HowToSubmitABug.rst | 4 +- gnu/llvm/llvm/docs/HowToUpdateDebugInfo.rst | 424 + gnu/llvm/llvm/docs/HowToUseAttributes.rst | 4 +- gnu/llvm/llvm/docs/HowToUseInstrMappings.rst | 2 +- gnu/llvm/llvm/docs/LLVMBuild.txt | 2 +- gnu/llvm/llvm/docs/LangRef.rst | 2545 +- gnu/llvm/llvm/docs/Lexicon.rst | 8 +- gnu/llvm/llvm/docs/LibFuzzer.rst | 32 +- gnu/llvm/llvm/docs/LinkTimeOptimization.rst | 6 + gnu/llvm/llvm/docs/LoopTerminology.rst | 416 +- .../llvm/docs/MarkdownQuickstartTemplate.md | 2 +- gnu/llvm/llvm/docs/MarkedUpDisassembly.rst | 2 +- gnu/llvm/llvm/docs/MemTagSanitizer.rst | 4 +- gnu/llvm/llvm/docs/MemorySSA.rst | 82 +- gnu/llvm/llvm/docs/MergeFunctions.rst | 16 +- gnu/llvm/llvm/docs/ORCv2.rst | 294 +- gnu/llvm/llvm/docs/Packaging.rst | 2 +- gnu/llvm/llvm/docs/Passes.rst | 26 +- gnu/llvm/llvm/docs/Phabricator.rst | 40 +- gnu/llvm/llvm/docs/ProgrammersManual.rst | 291 +- gnu/llvm/llvm/docs/Proposals/GitHubMove.rst | 36 +- gnu/llvm/llvm/docs/Proposals/TestSuite.rst | 4 +- .../llvm/docs/Proposals/VariableNames.rst | 2 +- .../llvm/docs/Proposals/VectorPredication.rst | 88 + gnu/llvm/llvm/docs/README.txt | 6 +- gnu/llvm/llvm/docs/Reference.rst | 7 +- gnu/llvm/llvm/docs/ReleaseNotes.rst | 575 +- gnu/llvm/llvm/docs/ReleaseProcess.rst | 8 +- gnu/llvm/llvm/docs/Remarks.rst | 32 + gnu/llvm/llvm/docs/ReportingGuide.rst | 4 +- gnu/llvm/llvm/docs/Security.rst | 220 + gnu/llvm/llvm/docs/SourceLevelDebugging.rst | 192 +- .../llvm/docs/SphinxQuickstartTemplate.rst | 2 +- gnu/llvm/llvm/docs/Statepoints.rst | 49 +- gnu/llvm/llvm/docs/TableGen/LangRef.rst | 4 +- gnu/llvm/llvm/docs/TableGen/index.rst | 2 +- gnu/llvm/llvm/docs/TestSuiteGuide.md | 8 +- gnu/llvm/llvm/docs/TestingGuide.rst | 8 +- gnu/llvm/llvm/docs/TransformMetadata.rst | 2 +- gnu/llvm/llvm/docs/TypeMetadata.rst | 4 +- gnu/llvm/llvm/docs/UserGuides.rst | 16 +- gnu/llvm/llvm/docs/Vectorizers.rst | 6 +- gnu/llvm/llvm/docs/WritingAnLLVMBackend.rst | 34 +- gnu/llvm/llvm/docs/WritingAnLLVMPass.rst | 42 +- gnu/llvm/llvm/docs/XRayFDRFormat.rst | 2 +- gnu/llvm/llvm/docs/YamlIO.rst | 4 +- gnu/llvm/llvm/docs/conf.py | 23 +- gnu/llvm/llvm/docs/doxygen.cfg.in | 2 +- gnu/llvm/llvm/docs/index.rst | 12 +- .../docs/loop-terminology-guarded-loop.png | Bin 0 -> 72585 bytes .../docs/loop-terminology-initial-loop.png | Bin 0 -> 41638 bytes .../docs/loop-terminology-rotated-loop.png | Bin 0 -> 61457 bytes gnu/llvm/llvm/docs/re_format.7 | 4 +- gnu/llvm/llvm/docs/tutorial/BuildingAJIT1.rst | 6 +- gnu/llvm/llvm/docs/tutorial/BuildingAJIT2.rst | 4 +- .../MyFirstLanguageFrontend/LangImpl02.rst | 4 +- .../MyFirstLanguageFrontend/LangImpl03.rst | 6 +- .../MyFirstLanguageFrontend/LangImpl04.rst | 6 +- .../MyFirstLanguageFrontend/LangImpl05.rst | 2 +- .../MyFirstLanguageFrontend/LangImpl06.rst | 2 +- .../MyFirstLanguageFrontend/LangImpl07.rst | 2 +- .../MyFirstLanguageFrontend/LangImpl08.rst | 2 +- .../MyFirstLanguageFrontend/LangImpl09.rst | 4 +- .../llvm/docs/tutorial/OCamlLangImpl3.rst | 8 +- .../llvm/docs/tutorial/OCamlLangImpl5.rst | 2 +- gnu/llvm/llvm/docs/tutorial/index.rst | 2 +- gnu/llvm/llvm/examples/BrainF/BrainF.cpp | 8 +- gnu/llvm/llvm/examples/Bye/Bye.cpp | 11 +- gnu/llvm/llvm/examples/Bye/CMakeLists.txt | 22 +- gnu/llvm/llvm/examples/CMakeLists.txt | 3 +- .../examples/ExceptionDemo/ExceptionDemo.cpp | 4 +- .../BuildingAJIT/Chapter1/KaleidoscopeJIT.h | 2 +- .../BuildingAJIT/Chapter1/toy.cpp | 4 +- .../BuildingAJIT/Chapter2/KaleidoscopeJIT.h | 2 +- .../BuildingAJIT/Chapter2/toy.cpp | 4 +- .../BuildingAJIT/Chapter3/KaleidoscopeJIT.h | 8 +- .../BuildingAJIT/Chapter3/toy.cpp | 4 +- .../BuildingAJIT/Chapter4/KaleidoscopeJIT.h | 8 +- .../BuildingAJIT/Chapter4/toy.cpp | 4 +- .../BuildingAJIT/Chapter5/KaleidoscopeJIT.h | 4 +- .../BuildingAJIT/Chapter5/toy.cpp | 4 +- .../examples/Kaleidoscope/Chapter3/toy.cpp | 2 +- .../examples/Kaleidoscope/Chapter4/toy.cpp | 2 +- .../examples/Kaleidoscope/Chapter5/toy.cpp | 2 +- .../examples/Kaleidoscope/Chapter6/toy.cpp | 2 +- .../examples/Kaleidoscope/Chapter7/toy.cpp | 4 +- .../examples/Kaleidoscope/Chapter8/toy.cpp | 4 +- .../examples/Kaleidoscope/Chapter9/toy.cpp | 8 +- .../Kaleidoscope/include/KaleidoscopeJIT.h | 4 +- .../examples/OrcV2Examples/CMakeLists.txt | 10 + .../examples/OrcV2Examples/ExampleModules.h | 54 + .../LLJITDumpObjects/CMakeLists.txt | 13 + .../LLJITDumpObjects/LLJITDumpObjects.cpp | 70 + .../CMakeLists.txt | 12 + .../LLJITWithCustomObjectLinkingLayer.cpp | 66 + .../CMakeLists.txt | 17 + .../LLJITWithGDBRegistrationListener.cpp | 115 + .../LLJITWithInitializers/CMakeLists.txt | 13 + .../LLJITWithInitializers.cpp | 97 + .../LLJITWithLazyReexports/CMakeLists.txt | 12 + .../LLJITWithLazyReexports.cpp | 163 + .../LLJITWithObjectCache/CMakeLists.txt | 12 + .../LLJITWithObjectCache.cpp | 95 + .../CMakeLists.txt | 12 + .../LLJITWithObjectLinkingLayerPlugin.cpp | 156 + .../CMakeLists.txt | 15 + .../OrcV2CBindingsAddObjectFile.c | 158 + .../OrcV2CBindingsBasicUsage/CMakeLists.txt | 15 + .../OrcV2CBindingsBasicUsage.c | 144 + .../CMakeLists.txt | 17 + .../OrcV2CBindingsReflectProcessSymbols.c | 220 + .../SpeculativeJIT/SpeculativeJIT.cpp | 15 +- .../llvm/examples/ThinLtoJIT/CMakeLists.txt | 19 + .../ThinLtoJIT/ThinLtoDiscoveryThread.cpp | 65 + .../ThinLtoJIT/ThinLtoDiscoveryThread.h | 57 + .../ThinLtoInstrumentationLayer.cpp | 225 + .../ThinLtoJIT/ThinLtoInstrumentationLayer.h | 77 + .../llvm/examples/ThinLtoJIT/ThinLtoJIT.cpp | 340 + .../llvm/examples/ThinLtoJIT/ThinLtoJIT.h | 111 + .../ThinLtoJIT/ThinLtoModuleIndex.cpp | 268 + .../examples/ThinLtoJIT/ThinLtoModuleIndex.h | 94 + gnu/llvm/llvm/examples/ThinLtoJIT/bench | 100 + gnu/llvm/llvm/examples/ThinLtoJIT/main.cpp | 83 + gnu/llvm/llvm/include/llvm-c/Core.h | 78 +- gnu/llvm/llvm/include/llvm-c/DataTypes.h | 6 - gnu/llvm/llvm/include/llvm-c/DebugInfo.h | 13 +- .../llvm/include/llvm-c/ExecutionEngine.h | 5 + gnu/llvm/llvm/include/llvm-c/Orc.h | 335 + .../include/llvm-c/Transforms/Coroutines.h | 4 + gnu/llvm/llvm/include/llvm-c/lto.h | 17 +- gnu/llvm/llvm/include/llvm/ADT/APFloat.h | 72 +- gnu/llvm/llvm/include/llvm/ADT/APInt.h | 19 +- .../llvm/include/llvm/ADT/AllocatorList.h | 4 +- gnu/llvm/llvm/include/llvm/ADT/Any.h | 63 +- gnu/llvm/llvm/include/llvm/ADT/ArrayRef.h | 58 +- gnu/llvm/llvm/include/llvm/ADT/BitVector.h | 58 +- gnu/llvm/llvm/include/llvm/ADT/Bitfields.h | 289 + gnu/llvm/llvm/include/llvm/ADT/BitmaskEnum.h | 41 +- .../llvm/include/llvm/ADT/CachedHashString.h | 3 +- .../include/llvm/ADT/CoalescingBitVector.h | 443 + .../llvm/include/llvm/ADT/DAGDeltaAlgorithm.h | 2 +- .../llvm/include/llvm/ADT/DeltaAlgorithm.h | 2 +- gnu/llvm/llvm/include/llvm/ADT/DenseMap.h | 87 +- gnu/llvm/llvm/include/llvm/ADT/DenseMapInfo.h | 114 +- gnu/llvm/llvm/include/llvm/ADT/DenseSet.h | 6 + .../llvm/include/llvm/ADT/EnumeratedArray.h | 1 + .../llvm/include/llvm/ADT/FloatingPointMode.h | 141 +- gnu/llvm/llvm/include/llvm/ADT/FoldingSet.h | 138 +- .../llvm/include/llvm/ADT/FunctionExtras.h | 225 +- gnu/llvm/llvm/include/llvm/ADT/Hashing.h | 20 +- gnu/llvm/llvm/include/llvm/ADT/ImmutableMap.h | 100 +- gnu/llvm/llvm/include/llvm/ADT/ImmutableSet.h | 104 +- gnu/llvm/llvm/include/llvm/ADT/IntervalMap.h | 14 +- gnu/llvm/llvm/include/llvm/ADT/Optional.h | 2 +- .../include/llvm/ADT/PointerEmbeddedInt.h | 2 +- .../llvm/include/llvm/ADT/PointerIntPair.h | 5 +- .../llvm/include/llvm/ADT/PointerSumType.h | 2 +- gnu/llvm/llvm/include/llvm/ADT/PointerUnion.h | 4 +- .../llvm/include/llvm/ADT/PostOrderIterator.h | 3 +- .../llvm/include/llvm/ADT/PriorityWorklist.h | 2 +- gnu/llvm/llvm/include/llvm/ADT/SCCIterator.h | 8 +- gnu/llvm/llvm/include/llvm/ADT/STLExtras.h | 631 +- .../llvm/include/llvm/ADT/ScopedHashTable.h | 2 +- .../llvm/include/llvm/ADT/SetOperations.h | 21 + gnu/llvm/llvm/include/llvm/ADT/SetVector.h | 25 +- .../llvm/include/llvm/ADT/SmallBitVector.h | 37 +- gnu/llvm/llvm/include/llvm/ADT/SmallPtrSet.h | 19 +- gnu/llvm/llvm/include/llvm/ADT/SmallString.h | 6 +- gnu/llvm/llvm/include/llvm/ADT/SmallVector.h | 107 +- .../llvm/include/llvm/ADT/SparseMultiSet.h | 2 +- gnu/llvm/llvm/include/llvm/ADT/SparseSet.h | 4 +- gnu/llvm/llvm/include/llvm/ADT/StringExtras.h | 22 +- gnu/llvm/llvm/include/llvm/ADT/StringMap.h | 230 +- .../llvm/include/llvm/ADT/StringMapEntry.h | 135 + gnu/llvm/llvm/include/llvm/ADT/StringRef.h | 32 +- gnu/llvm/llvm/include/llvm/ADT/StringSet.h | 66 +- .../llvm/include/llvm/ADT/TinyPtrVector.h | 8 +- gnu/llvm/llvm/include/llvm/ADT/Triple.h | 44 +- gnu/llvm/llvm/include/llvm/ADT/Twine.h | 4 +- gnu/llvm/llvm/include/llvm/ADT/TypeSwitch.h | 176 + gnu/llvm/llvm/include/llvm/ADT/Waymarking.h | 325 + gnu/llvm/llvm/include/llvm/ADT/bit.h | 23 +- .../llvm/include/llvm/ADT/fallible_iterator.h | 8 +- gnu/llvm/llvm/include/llvm/ADT/ilist.h | 8 +- .../llvm/include/llvm/ADT/ilist_iterator.h | 7 +- gnu/llvm/llvm/include/llvm/ADT/iterator.h | 20 +- .../include/llvm/Analysis/AliasAnalysis.h | 66 +- .../include/llvm/Analysis/AliasSetTracker.h | 7 +- .../llvm/Analysis/AssumeBundleQueries.h | 167 + .../include/llvm/Analysis/AssumptionCache.h | 42 +- .../llvm/Analysis/BasicAliasAnalysis.h | 4 +- .../llvm/Analysis/BlockFrequencyInfo.h | 3 + .../llvm/Analysis/BlockFrequencyInfoImpl.h | 126 +- .../llvm/Analysis/BranchProbabilityInfo.h | 22 +- gnu/llvm/llvm/include/llvm/Analysis/CFG.h | 6 +- .../llvm/include/llvm/Analysis/CFGPrinter.h | 194 +- .../include/llvm/Analysis/CGSCCPassManager.h | 87 +- .../llvm/include/llvm/Analysis/CallGraph.h | 36 +- .../include/llvm/Analysis/CallGraphSCCPass.h | 4 + .../include/llvm/Analysis/CaptureTracking.h | 46 +- .../llvm/include/llvm/Analysis/CodeMetrics.h | 4 +- .../include/llvm/Analysis/ConstantFolding.h | 14 +- gnu/llvm/llvm/include/llvm/Analysis/DDG.h | 40 + .../llvm/Analysis/DOTGraphTraitsPass.h | 2 - .../llvm/Analysis/DependenceAnalysis.h | 29 +- .../llvm/Analysis/DependenceGraphBuilder.h | 31 +- .../llvm/Analysis/DivergenceAnalysis.h | 2 +- .../include/llvm/Analysis/DomTreeUpdater.h | 8 +- .../include/llvm/Analysis/DominanceFrontier.h | 2 +- .../include/llvm/Analysis/EHPersonalities.h | 2 +- .../include/llvm/Analysis/GlobalsModRef.h | 5 +- .../llvm/include/llvm/Analysis/HeatUtils.h | 40 + .../include/llvm/Analysis/IVDescriptors.h | 23 +- .../llvm/Analysis/IndirectCallVisitor.h | 4 +- .../include/llvm/Analysis/InlineAdvisor.h | 238 + .../llvm/include/llvm/Analysis/InlineCost.h | 108 +- .../llvm/Analysis/InlineFeaturesAnalysis.h | 45 + .../llvm/Analysis/InlineModelFeatureMaps.h | 70 + .../Analysis/InlineSizeEstimatorAnalysis.h | 35 + .../Analysis/InstructionPrecedenceTracking.h | 20 +- .../llvm/Analysis/InstructionSimplify.h | 22 +- .../llvm/Analysis/IteratedDominanceFrontier.h | 2 +- .../llvm/Analysis/LazyBranchProbabilityInfo.h | 2 +- .../include/llvm/Analysis/LazyCallGraph.h | 17 + .../include/llvm/Analysis/LazyValueInfo.h | 24 +- .../llvm/Analysis/LegacyDivergenceAnalysis.h | 12 +- gnu/llvm/llvm/include/llvm/Analysis/Loads.h | 17 +- .../llvm/Analysis/LoopAccessAnalysis.h | 136 +- .../llvm/Analysis/LoopAnalysisManager.h | 23 +- .../llvm/include/llvm/Analysis/LoopInfo.h | 20 +- .../llvm/include/llvm/Analysis/LoopInfoImpl.h | 1 - .../include/llvm/Analysis/LoopNestAnalysis.h | 162 + .../llvm/include/llvm/Analysis/LoopPass.h | 40 - .../include/llvm/Analysis/MLInlineAdvisor.h | 107 + .../include/llvm/Analysis/MLModelRunner.h | 39 + .../include/llvm/Analysis/MemoryBuiltins.h | 14 +- .../llvm/Analysis/MemoryDependenceAnalysis.h | 30 +- .../include/llvm/Analysis/MemoryLocation.h | 42 +- .../llvm/include/llvm/Analysis/MemorySSA.h | 31 +- .../include/llvm/Analysis/MemorySSAUpdater.h | 24 +- .../llvm/Analysis/ModuleSummaryAnalysis.h | 26 +- .../llvm/include/llvm/Analysis/MustExecute.h | 135 +- .../llvm/Analysis/ObjCARCAnalysisUtils.h | 23 +- .../include/llvm/Analysis/ObjCARCInstKind.h | 2 - .../llvm/Analysis/OptimizationRemarkEmitter.h | 10 +- gnu/llvm/llvm/include/llvm/Analysis/Passes.h | 3 - .../llvm/include/llvm/Analysis/PhiValues.h | 1 - .../include/llvm/Analysis/PostDominators.h | 4 +- .../llvm/Analysis/ProfileSummaryInfo.h | 107 +- .../include/llvm/Analysis/PtrUseVisitor.h | 7 +- .../llvm/include/llvm/Analysis/RegionInfo.h | 5 +- .../include/llvm/Analysis/RegionInfoImpl.h | 8 +- .../llvm/include/llvm/Analysis/RegionPass.h | 4 +- .../include/llvm/Analysis/ScalarEvolution.h | 22 +- .../llvm/Analysis/ScalarEvolutionDivision.h | 69 + .../Analysis/ScalarEvolutionExpressions.h | 24 +- .../Analysis/ScalarEvolutionNormalization.h | 2 +- .../include/llvm/Analysis/ScopedNoAliasAA.h | 1 - .../include/llvm/Analysis/StackLifetime.h | 202 + .../llvm/Analysis/StackSafetyAnalysis.h | 59 +- .../llvm/Analysis/SyncDependenceAnalysis.h | 5 - .../llvm/Analysis/SyntheticCountsUtils.h | 3 - .../llvm/include/llvm/Analysis/TargetFolder.h | 115 +- .../llvm/Analysis/TargetLibraryInfo.def | 36 + .../include/llvm/Analysis/TargetLibraryInfo.h | 36 +- .../llvm/Analysis/TargetTransformInfo.h | 923 +- .../llvm/Analysis/TargetTransformInfoImpl.h | 715 +- .../llvm/Analysis/TypeBasedAliasAnalysis.h | 3 +- .../include/llvm/Analysis/TypeMetadataUtils.h | 9 +- .../llvm/include/llvm/Analysis/Utils/Local.h | 18 +- .../include/llvm/Analysis/Utils/TFUtils.h | 115 + .../llvm/include/llvm/Analysis/ValueLattice.h | 267 +- .../include/llvm/Analysis/ValueTracking.h | 91 +- .../llvm/include/llvm/Analysis/VecFuncs.def | 23 + .../llvm/include/llvm/Analysis/VectorUtils.h | 237 +- gnu/llvm/llvm/include/llvm/AsmParser/Parser.h | 81 +- .../llvm/include/llvm/BinaryFormat/COFF.h | 6 + .../llvm/include/llvm/BinaryFormat/Dwarf.def | 96 +- .../llvm/include/llvm/BinaryFormat/Dwarf.h | 39 +- gnu/llvm/llvm/include/llvm/BinaryFormat/ELF.h | 138 +- .../llvm/BinaryFormat/ELFRelocs/AArch64.def | 4 + .../llvm/BinaryFormat/ELFRelocs/PowerPC64.def | 6 + .../llvm/BinaryFormat/ELFRelocs/RISCV.def | 1 + .../llvm/BinaryFormat/ELFRelocs/VE.def | 48 + .../llvm/include/llvm/BinaryFormat/MachO.h | 17 +- .../llvm/include/llvm/BinaryFormat/Magic.h | 6 +- .../llvm/BinaryFormat/MsgPackDocument.h | 99 +- .../include/llvm/BinaryFormat/MsgPackReader.h | 2 + .../llvm/include/llvm/BinaryFormat/Wasm.h | 31 +- .../include/llvm/BinaryFormat/WasmRelocs.def | 31 +- .../llvm/include/llvm/BinaryFormat/XCOFF.h | 57 +- .../llvm/include/llvm/Bitcode/BitcodeReader.h | 24 +- .../llvm/include/llvm/Bitcode/LLVMBitCodes.h | 17 +- .../include/llvm/Bitstream/BitstreamReader.h | 1 + gnu/llvm/llvm/include/llvm/CMakeLists.txt | 1 + gnu/llvm/llvm/include/llvm/CodeGen/Analysis.h | 6 +- .../include/llvm/CodeGen/AntiDepBreaker.h | 97 + .../llvm/include/llvm/CodeGen/AsmPrinter.h | 148 +- .../include/llvm/CodeGen/AsmPrinterHandler.h | 6 + .../llvm/include/llvm/CodeGen/BasicTTIImpl.h | 920 +- .../include/llvm/CodeGen/CallingConvLower.h | 84 +- .../llvm/include/llvm/CodeGen/CommandFlags.h | 151 + gnu/llvm/llvm/include/llvm/CodeGen/DIE.h | 49 +- .../llvm/CodeGen/DbgEntityHistoryCalculator.h | 3 +- .../include/llvm/CodeGen/DebugHandlerBase.h | 9 +- .../llvm/include/llvm/CodeGen/EdgeBundles.h | 1 - .../include/llvm/CodeGen/ExecutionDomainFix.h | 15 +- gnu/llvm/llvm/include/llvm/CodeGen/FastISel.h | 64 +- .../llvm/CodeGen/FunctionLoweringInfo.h | 75 +- .../include/llvm/CodeGen/GlobalISel/CSEInfo.h | 8 +- .../llvm/CodeGen/GlobalISel/CallLowering.h | 24 +- .../llvm/CodeGen/GlobalISel/CombinerHelper.h | 88 +- .../llvm/CodeGen/GlobalISel/CombinerInfo.h | 2 +- .../CodeGen/GlobalISel/GISelChangeObserver.h | 24 +- .../llvm/CodeGen/GlobalISel/GISelKnownBits.h | 36 +- .../llvm/CodeGen/GlobalISel/IRTranslator.h | 19 +- .../CodeGen/GlobalISel/InlineAsmLowering.h | 67 + .../CodeGen/GlobalISel/InstructionSelector.h | 7 + .../GlobalISel/InstructionSelectorImpl.h | 36 +- .../GlobalISel/LegalizationArtifactCombiner.h | 353 +- .../llvm/CodeGen/GlobalISel/Legalizer.h | 2 + .../llvm/CodeGen/GlobalISel/LegalizerHelper.h | 117 +- .../llvm/CodeGen/GlobalISel/LegalizerInfo.h | 120 +- .../llvm/CodeGen/GlobalISel/Localizer.h | 4 +- .../CodeGen/GlobalISel/LostDebugLocObserver.h | 50 + .../llvm/CodeGen/GlobalISel/MIPatternMatch.h | 74 +- .../CodeGen/GlobalISel/MachineIRBuilder.h | 236 +- .../include/llvm/CodeGen/GlobalISel/Utils.h | 58 +- .../llvm/include/llvm/CodeGen/ISDOpcodes.h | 2355 +- .../include/llvm/CodeGen/IndirectThunks.h | 110 + .../include/llvm/CodeGen/IntrinsicLowering.h | 1 - .../llvm/include/llvm/CodeGen/LexicalScopes.h | 9 +- .../llvm/include/llvm/CodeGen/LiveInterval.h | 13 +- .../include/llvm/CodeGen/LiveIntervalCalc.h | 71 + .../llvm/include/llvm/CodeGen/LiveIntervals.h | 31 +- .../llvm/include/llvm/CodeGen/LiveRangeCalc.h | 57 +- .../llvm/include/llvm/CodeGen/LiveRangeEdit.h | 36 +- .../llvm/include/llvm/CodeGen/LiveVariables.h | 5 + .../llvm/include/llvm/CodeGen/MBFIWrapper.h | 46 + .../include/llvm/CodeGen/MIRParser/MIParser.h | 17 +- .../llvm/CodeGen/MIRParser/MIRParser.h | 6 +- .../include/llvm/CodeGen/MIRYamlMapping.h | 33 +- .../include/llvm/CodeGen/MachineBasicBlock.h | 149 +- .../llvm/CodeGen/MachineBlockFrequencyInfo.h | 2 + .../llvm/CodeGen/MachineCombinerPattern.h | 4 + .../llvm/CodeGen/MachineConstantPool.h | 40 +- .../include/llvm/CodeGen/MachineDominators.h | 12 +- .../include/llvm/CodeGen/MachineFrameInfo.h | 83 +- .../include/llvm/CodeGen/MachineFunction.h | 100 +- .../llvm/include/llvm/CodeGen/MachineInstr.h | 125 +- .../include/llvm/CodeGen/MachineInstrBundle.h | 4 +- .../llvm/CodeGen/MachineInstrBundleIterator.h | 4 +- .../include/llvm/CodeGen/MachineMemOperand.h | 30 +- .../include/llvm/CodeGen/MachineModuleInfo.h | 11 +- .../include/llvm/CodeGen/MachineOperand.h | 9 +- .../MachineOptimizationRemarkEmitter.h | 4 +- .../include/llvm/CodeGen/MachinePipeliner.h | 23 +- .../llvm/CodeGen/MachinePostDominators.h | 10 +- .../llvm/CodeGen/MachineRegisterInfo.h | 184 +- .../include/llvm/CodeGen/MachineSSAUpdater.h | 16 +- .../include/llvm/CodeGen/MachineScheduler.h | 11 +- .../include/llvm/CodeGen/MachineSizeOpts.h | 7 + .../include/llvm/CodeGen/ModuloSchedule.h | 35 +- .../llvm/include/llvm/CodeGen/ParallelCG.h | 5 +- gnu/llvm/llvm/include/llvm/CodeGen/Passes.h | 31 +- .../include/llvm/CodeGen/PseudoSourceValue.h | 5 +- .../llvm/CodeGen/ReachingDefAnalysis.h | 171 +- gnu/llvm/llvm/include/llvm/CodeGen/Register.h | 23 +- .../llvm/CodeGen/ResourcePriorityQueue.h | 10 +- .../llvm/include/llvm/CodeGen/ScheduleDAG.h | 4 + .../llvm/include/llvm/CodeGen/ScheduleDFS.h | 2 +- .../llvm/CodeGen/ScoreboardHazardRecognizer.h | 8 +- .../llvm/include/llvm/CodeGen/SelectionDAG.h | 337 +- .../include/llvm/CodeGen/SelectionDAGISel.h | 14 +- .../include/llvm/CodeGen/SelectionDAGNodes.h | 91 +- .../llvm/CodeGen/SelectionDAGTargetInfo.h | 11 +- .../llvm/include/llvm/CodeGen/SlotIndexes.h | 24 +- gnu/llvm/llvm/include/llvm/CodeGen/Spiller.h | 42 + .../llvm/include/llvm/CodeGen/StackMaps.h | 37 +- .../include/llvm/CodeGen/StackProtector.h | 2 +- .../include/llvm/CodeGen/TailDuplicator.h | 34 +- .../include/llvm/CodeGen/TargetCallingConv.h | 28 +- .../llvm/CodeGen/TargetFrameLowering.h | 82 +- .../include/llvm/CodeGen/TargetInstrInfo.h | 98 +- .../include/llvm/CodeGen/TargetLowering.h | 453 +- .../CodeGen/TargetLoweringObjectFileImpl.h | 36 +- .../include/llvm/CodeGen/TargetPassConfig.h | 20 +- .../include/llvm/CodeGen/TargetRegisterInfo.h | 84 +- .../llvm/CodeGen/TargetSubtargetInfo.h | 17 +- .../llvm/include/llvm/CodeGen/ValueTypes.h | 76 +- .../llvm/include/llvm/CodeGen/ValueTypes.td | 305 +- .../llvm/include/llvm/CodeGen/VirtRegMap.h | 1 - .../include/llvm/CodeGen/WasmEHFuncInfo.h | 6 +- .../llvm/include/llvm/Config/config.h.cmake | 12 +- .../include/llvm/Config/llvm-config.h.cmake | 6 + .../include/llvm/DWARFLinker/DWARFLinker.h | 619 +- .../llvm/DWARFLinker/DWARFLinkerCompileUnit.h | 5 + .../llvm/DWARFLinker/DWARFLinkerDeclContext.h | 1 + .../include/llvm/DWARFLinker/DWARFStreamer.h | 219 + .../CodeView/AppendingTypeTableBuilder.h | 3 +- .../DebugInfo/CodeView/CodeViewRecordIO.h | 14 +- .../CodeView/ContinuationRecordBuilder.h | 1 - .../CodeView/DebugSubsectionRecord.h | 23 +- .../CodeView/GlobalTypeTableBuilder.h | 3 +- .../CodeView/LazyRandomTypeCollection.h | 1 + .../CodeView/MergingTypeTableBuilder.h | 3 +- .../DebugInfo/CodeView/SimpleTypeSerializer.h | 16 +- .../llvm/DebugInfo/CodeView/SymbolRecord.h | 7 + .../llvm/DebugInfo/CodeView/TypeCollection.h | 1 + .../DebugInfo/CodeView/TypeSymbolEmitter.h | 4 +- .../DebugInfo/CodeView/TypeTableCollection.h | 1 + .../llvm/include/llvm/DebugInfo/DIContext.h | 22 +- .../DebugInfo/DWARF/DWARFAcceleratorTable.h | 27 +- .../llvm/DebugInfo/DWARF/DWARFAddressRange.h | 18 + .../llvm/DebugInfo/DWARF/DWARFContext.h | 83 +- .../llvm/DebugInfo/DWARF/DWARFDataExtractor.h | 28 + .../llvm/DebugInfo/DWARF/DWARFDebugAddr.h | 86 +- .../DebugInfo/DWARF/DWARFDebugArangeSet.h | 13 +- .../llvm/DebugInfo/DWARF/DWARFDebugAranges.h | 8 +- .../llvm/DebugInfo/DWARF/DWARFDebugFrame.h | 30 +- .../llvm/DebugInfo/DWARF/DWARFDebugLine.h | 84 +- .../llvm/DebugInfo/DWARF/DWARFDebugMacro.h | 81 +- .../llvm/DebugInfo/DWARF/DWARFDebugPubTable.h | 16 +- .../include/llvm/DebugInfo/DWARF/DWARFDie.h | 16 +- .../llvm/DebugInfo/DWARF/DWARFExpression.h | 28 +- .../llvm/DebugInfo/DWARF/DWARFFormValue.h | 2 + .../llvm/DebugInfo/DWARF/DWARFObject.h | 2 + .../include/llvm/DebugInfo/DWARF/DWARFUnit.h | 35 +- .../llvm/DebugInfo/DWARF/DWARFUnitIndex.h | 75 +- .../llvm/DebugInfo/DWARF/DWARFVerifier.h | 11 +- .../llvm/DebugInfo/GSYM/DwarfTransformer.h | 91 + .../include/llvm/DebugInfo/GSYM/GsymCreator.h | 72 +- .../include/llvm/DebugInfo/GSYM/GsymReader.h | 63 +- .../include/llvm/DebugInfo/GSYM/InlineInfo.h | 2 +- .../include/llvm/DebugInfo/GSYM/LineTable.h | 18 + .../llvm/DebugInfo/GSYM/LookupResult.h | 4 +- .../DebugInfo/GSYM/ObjectFileTransformer.h | 51 + .../llvm/include/llvm/DebugInfo/GSYM/Range.h | 2 + .../llvm/DebugInfo/PDB/DIA/DIASession.h | 12 +- .../include/llvm/DebugInfo/PDB/GenericError.h | 1 - .../llvm/DebugInfo/PDB/IPDBInjectedSource.h | 6 +- .../llvm/DebugInfo/PDB/IPDBLineNumber.h | 2 +- .../llvm/DebugInfo/PDB/IPDBRawSymbol.h | 6 +- .../include/llvm/DebugInfo/PDB/IPDBSession.h | 11 +- .../PDB/Native/DbiModuleDescriptorBuilder.h | 3 +- .../DebugInfo/PDB/Native/DbiStreamBuilder.h | 8 +- .../DebugInfo/PDB/Native/GSIStreamBuilder.h | 78 +- .../PDB/Native/NativeEnumLineNumbers.h | 39 + .../PDB/Native/NativeFunctionSymbol.h | 45 + .../DebugInfo/PDB/Native/NativeLineNumber.h | 51 + .../DebugInfo/PDB/Native/NativePublicSymbol.h | 44 + .../llvm/DebugInfo/PDB/Native/NativeSession.h | 23 +- .../DebugInfo/PDB/Native/NativeSourceFile.h | 40 + .../PDB/Native/NativeTypeFunctionSig.h | 2 +- .../DebugInfo/PDB/Native/NativeTypePointer.h | 2 +- .../DebugInfo/PDB/Native/NativeTypeTypedef.h | 2 +- .../llvm/DebugInfo/PDB/Native/NativeTypeUDT.h | 2 +- .../DebugInfo/PDB/Native/NativeTypeVTShape.h | 2 +- .../DebugInfo/PDB/Native/PDBFileBuilder.h | 1 - .../llvm/DebugInfo/PDB/Native/SymbolCache.h | 51 +- .../include/llvm/DebugInfo/PDB/PDBSymbol.h | 6 +- .../include/llvm/DebugInfo/PDB/PDBTypes.h | 84 + .../llvm/DebugInfo/Symbolize/DIPrinter.h | 10 +- .../DebugInfo/Symbolize/SymbolizableModule.h | 5 +- .../llvm/DebugInfo/Symbolize/Symbolize.h | 6 +- .../llvm/include/llvm/Demangle/Demangle.h | 16 +- .../include/llvm/Demangle/ItaniumDemangle.h | 47 +- .../llvm/Demangle/MicrosoftDemangleNodes.h | 12 +- .../llvm/ExecutionEngine/ExecutionEngine.h | 16 +- .../llvm/ExecutionEngine/JITLink/ELF.h | 31 + .../llvm/ExecutionEngine/JITLink/ELF_x86_64.h | 52 + .../llvm/ExecutionEngine/JITLink/JITLink.h | 35 +- .../JITLink/JITLinkMemoryManager.h | 12 + .../ExecutionEngine/JITLink/MachO_x86_64.h | 1 + .../include/llvm/ExecutionEngine/JITSymbol.h | 38 +- .../llvm/ExecutionEngine/ObjectCache.h | 3 +- .../Orc/CompileOnDemandLayer.h | 92 +- .../llvm/ExecutionEngine/Orc/CompileUtils.h | 4 +- .../include/llvm/ExecutionEngine/Orc/Core.h | 405 +- .../llvm/ExecutionEngine/Orc/DebugUtils.h | 72 + .../llvm/ExecutionEngine/Orc/ExecutionUtils.h | 72 + .../llvm/ExecutionEngine/Orc/IRCompileLayer.h | 10 +- .../ExecutionEngine/Orc/IRTransformLayer.h | 7 +- .../ExecutionEngine/Orc/IndirectionUtils.h | 136 +- .../Orc/JITTargetMachineBuilder.h | 11 +- .../include/llvm/ExecutionEngine/Orc/LLJIT.h | 170 +- .../include/llvm/ExecutionEngine/Orc/Layer.h | 33 +- .../ExecutionEngine/Orc/LazyEmittingLayer.h | 2 +- .../llvm/ExecutionEngine/Orc/LazyReexports.h | 96 +- .../include/llvm/ExecutionEngine/Orc/Legacy.h | 12 +- .../llvm/ExecutionEngine/Orc/MachOPlatform.h | 161 + .../llvm/ExecutionEngine/Orc/Mangling.h | 66 + .../ExecutionEngine/Orc/ObjectLinkingLayer.h | 15 + .../llvm/ExecutionEngine/Orc/OrcABISupport.h | 355 +- .../llvm/ExecutionEngine/Orc/OrcError.h | 4 +- .../Orc/OrcRemoteTargetRPCAPI.h | 3 +- .../Orc/OrcRemoteTargetServer.h | 44 +- .../Orc/RPC/RPCSerialization.h | 17 +- .../llvm/ExecutionEngine/Orc/RPC/RPCUtils.h | 43 +- .../ExecutionEngine/Orc/RPC/RawByteChannel.h | 32 +- .../Orc/RTDyldObjectLinkingLayer.h | 30 +- .../llvm/ExecutionEngine/Orc/Speculation.h | 5 +- .../ExecutionEngine/Orc/SymbolStringPool.h | 7 +- .../ExecutionEngine/Orc/ThreadSafeModule.h | 7 +- .../llvm/ExecutionEngine/RuntimeDyld.h | 27 +- .../ExecutionEngine/SectionMemoryManager.h | 1 - .../llvm/include/llvm/Frontend/CMakeLists.txt | 2 + .../llvm/Frontend/Directive/DirectiveBase.td | 109 + .../llvm/include/llvm/Frontend/OpenACC/ACC.td | 604 + .../llvm/Frontend/OpenACC/CMakeLists.txt | 4 + .../llvm/Frontend/OpenMP/CMakeLists.txt | 4 + .../llvm/include/llvm/Frontend/OpenMP/OMP.td | 1489 + .../llvm/Frontend/OpenMP/OMPConstants.h | 69 +- .../include/llvm/Frontend/OpenMP/OMPContext.h | 187 + .../llvm/Frontend/OpenMP/OMPGridValues.h | 131 + .../llvm/Frontend/OpenMP/OMPIRBuilder.h | 269 +- .../include/llvm/Frontend/OpenMP/OMPKinds.def | 870 +- .../llvm/include/llvm/FuzzMutate/FuzzerCLI.h | 3 +- .../llvm/include/llvm/FuzzMutate/Random.h | 6 +- .../llvm/include/llvm/IR/AbstractCallSite.h | 247 + gnu/llvm/llvm/include/llvm/IR/Argument.h | 11 +- gnu/llvm/llvm/include/llvm/IR/Attributes.h | 46 +- gnu/llvm/llvm/include/llvm/IR/Attributes.td | 34 +- gnu/llvm/llvm/include/llvm/IR/AutoUpgrade.h | 8 +- gnu/llvm/llvm/include/llvm/IR/BasicBlock.h | 107 +- gnu/llvm/llvm/include/llvm/IR/CFG.h | 43 +- gnu/llvm/llvm/include/llvm/IR/Constant.h | 2 + .../llvm/include/llvm/IR/ConstantFolder.h | 107 +- gnu/llvm/llvm/include/llvm/IR/ConstantRange.h | 4 + gnu/llvm/llvm/include/llvm/IR/Constants.h | 103 +- .../llvm/include/llvm/IR/ConstrainedOps.def | 105 +- gnu/llvm/llvm/include/llvm/IR/DIBuilder.h | 35 +- gnu/llvm/llvm/include/llvm/IR/DataLayout.h | 42 +- gnu/llvm/llvm/include/llvm/IR/DebugInfo.h | 18 +- .../llvm/include/llvm/IR/DebugInfoMetadata.h | 345 +- gnu/llvm/llvm/include/llvm/IR/DebugLoc.h | 2 +- gnu/llvm/llvm/include/llvm/IR/DerivedTypes.h | 275 +- .../llvm/include/llvm/IR/DiagnosticInfo.h | 46 +- gnu/llvm/llvm/include/llvm/IR/Dominators.h | 7 +- gnu/llvm/llvm/include/llvm/IR/FPEnv.h | 22 +- gnu/llvm/llvm/include/llvm/IR/Function.h | 28 +- .../llvm/IR/GetElementPtrTypeIterator.h | 12 +- gnu/llvm/llvm/include/llvm/IR/GlobalObject.h | 25 +- gnu/llvm/llvm/include/llvm/IR/GlobalValue.h | 31 +- .../llvm/include/llvm/IR/GlobalVariable.h | 1 - gnu/llvm/llvm/include/llvm/IR/IRBuilder.h | 1036 +- .../llvm/include/llvm/IR/IRBuilderFolder.h | 141 + .../llvm/include/llvm/IR/IRPrintingPasses.h | 17 +- gnu/llvm/llvm/include/llvm/IR/InlineAsm.h | 91 + gnu/llvm/llvm/include/llvm/IR/InstVisitor.h | 26 +- gnu/llvm/llvm/include/llvm/IR/InstrTypes.h | 170 +- gnu/llvm/llvm/include/llvm/IR/Instruction.h | 87 +- gnu/llvm/llvm/include/llvm/IR/Instructions.h | 655 +- gnu/llvm/llvm/include/llvm/IR/IntrinsicInst.h | 1685 +- gnu/llvm/llvm/include/llvm/IR/Intrinsics.h | 50 +- gnu/llvm/llvm/include/llvm/IR/Intrinsics.td | 436 +- .../llvm/include/llvm/IR/IntrinsicsAArch64.td | 923 +- .../llvm/include/llvm/IR/IntrinsicsAMDGPU.td | 696 +- .../llvm/include/llvm/IR/IntrinsicsARM.td | 361 +- .../llvm/include/llvm/IR/IntrinsicsBPF.td | 5 +- .../llvm/include/llvm/IR/IntrinsicsHexagon.td | 6212 +-- .../include/llvm/IR/IntrinsicsHexagonDep.td | 6144 +++ .../llvm/include/llvm/IR/IntrinsicsMips.td | 268 +- .../llvm/include/llvm/IR/IntrinsicsNVVM.td | 26 +- .../llvm/include/llvm/IR/IntrinsicsPowerPC.td | 223 +- .../llvm/include/llvm/IR/IntrinsicsRISCV.td | 4 +- .../llvm/include/llvm/IR/IntrinsicsSystemZ.td | 126 +- .../include/llvm/IR/IntrinsicsWebAssembly.td | 63 +- .../llvm/include/llvm/IR/IntrinsicsX86.td | 801 +- .../llvm/include/llvm/IR/IntrinsicsXCore.td | 72 +- gnu/llvm/llvm/include/llvm/IR/LLVMContext.h | 50 +- .../llvm/include/llvm/IR/LLVMRemarkStreamer.h | 95 + .../llvm/include/llvm/IR/LegacyPassManagers.h | 3 +- .../include/llvm/IR/LegacyPassNameParser.h | 41 - gnu/llvm/llvm/include/llvm/IR/Mangler.h | 2 +- gnu/llvm/llvm/include/llvm/IR/MatrixBuilder.h | 221 + gnu/llvm/llvm/include/llvm/IR/Metadata.h | 32 +- gnu/llvm/llvm/include/llvm/IR/Module.h | 42 +- .../llvm/include/llvm/IR/ModuleSummaryIndex.h | 150 +- .../include/llvm/IR/ModuleSummaryIndexYAML.h | 9 +- gnu/llvm/llvm/include/llvm/IR/NoFolder.h | 155 +- gnu/llvm/llvm/include/llvm/IR/Operator.h | 47 +- .../include/llvm/IR/PassInstrumentation.h | 2 +- gnu/llvm/llvm/include/llvm/IR/PassManager.h | 170 +- .../llvm/include/llvm/IR/PassManagerImpl.h | 157 + .../llvm/include/llvm/IR/PassTimingInfo.h | 9 +- gnu/llvm/llvm/include/llvm/IR/PatternMatch.h | 325 +- .../llvm/include/llvm/IR/ProfileSummary.h | 31 +- .../llvm/include/llvm/IR/RuntimeLibcalls.def | 5 + gnu/llvm/llvm/include/llvm/IR/Statepoint.h | 309 +- gnu/llvm/llvm/include/llvm/IR/Type.h | 83 +- gnu/llvm/llvm/include/llvm/IR/Use.h | 69 +- gnu/llvm/llvm/include/llvm/IR/User.h | 5 + .../llvm/include/llvm/IR/VPIntrinsics.def | 84 + gnu/llvm/llvm/include/llvm/IR/Value.h | 62 +- gnu/llvm/llvm/include/llvm/IR/ValueHandle.h | 44 +- gnu/llvm/llvm/include/llvm/IR/ValueMap.h | 2 +- .../llvm/include/llvm/IRReader/IRReader.h | 29 +- gnu/llvm/llvm/include/llvm/InitializePasses.h | 16 +- gnu/llvm/llvm/include/llvm/LTO/Config.h | 19 + gnu/llvm/llvm/include/llvm/LTO/LTO.h | 29 +- gnu/llvm/llvm/include/llvm/LTO/LTOBackend.h | 3 + .../llvm/LTO/legacy/LTOCodeGenerator.h | 6 +- .../llvm/include/llvm/LTO/legacy/LTOModule.h | 4 + gnu/llvm/llvm/include/llvm/LinkAllPasses.h | 7 +- gnu/llvm/llvm/include/llvm/MC/ConstantPools.h | 1 - gnu/llvm/llvm/include/llvm/MC/LaneBitmask.h | 6 +- gnu/llvm/llvm/include/llvm/MC/MCAsmBackend.h | 25 +- gnu/llvm/llvm/include/llvm/MC/MCAsmInfo.h | 47 +- gnu/llvm/llvm/include/llvm/MC/MCAsmLayout.h | 4 + gnu/llvm/llvm/include/llvm/MC/MCAssembler.h | 5 +- gnu/llvm/llvm/include/llvm/MC/MCContext.h | 88 +- gnu/llvm/llvm/include/llvm/MC/MCDirectives.h | 51 +- .../llvm/MC/MCDisassembler/MCDisassembler.h | 87 +- gnu/llvm/llvm/include/llvm/MC/MCDwarf.h | 38 +- .../llvm/include/llvm/MC/MCELFObjectWriter.h | 14 +- gnu/llvm/llvm/include/llvm/MC/MCELFStreamer.h | 42 +- gnu/llvm/llvm/include/llvm/MC/MCExpr.h | 237 +- gnu/llvm/llvm/include/llvm/MC/MCFixup.h | 13 +- gnu/llvm/llvm/include/llvm/MC/MCFragment.h | 33 +- gnu/llvm/llvm/include/llvm/MC/MCInstPrinter.h | 34 +- gnu/llvm/llvm/include/llvm/MC/MCInstrDesc.h | 25 +- gnu/llvm/llvm/include/llvm/MC/MCInstrInfo.h | 25 +- .../llvm/include/llvm/MC/MCInstrItineraries.h | 7 +- .../llvm/include/llvm/MC/MCMachObjectWriter.h | 3 +- .../llvm/include/llvm/MC/MCObjectFileInfo.h | 12 +- .../llvm/include/llvm/MC/MCObjectStreamer.h | 102 +- .../llvm/include/llvm/MC/MCObjectWriter.h | 6 - .../llvm/include/llvm/MC/MCParser/AsmLexer.h | 4 +- .../include/llvm/MC/MCParser/MCAsmParser.h | 25 +- .../llvm/MC/MCParser/MCAsmParserExtension.h | 2 + .../llvm/MC/MCParser/MCTargetAsmParser.h | 18 +- gnu/llvm/llvm/include/llvm/MC/MCRegister.h | 19 +- gnu/llvm/llvm/include/llvm/MC/MCSchedule.h | 2 +- gnu/llvm/llvm/include/llvm/MC/MCSection.h | 9 +- gnu/llvm/llvm/include/llvm/MC/MCSectionCOFF.h | 13 +- gnu/llvm/llvm/include/llvm/MC/MCSectionELF.h | 34 +- .../llvm/include/llvm/MC/MCSectionMachO.h | 7 - gnu/llvm/llvm/include/llvm/MC/MCSectionWasm.h | 18 +- .../llvm/include/llvm/MC/MCSectionXCOFF.h | 22 +- gnu/llvm/llvm/include/llvm/MC/MCStreamer.h | 247 +- .../llvm/include/llvm/MC/MCSubtargetInfo.h | 9 +- gnu/llvm/llvm/include/llvm/MC/MCSymbolWasm.h | 37 +- gnu/llvm/llvm/include/llvm/MC/MCSymbolXCOFF.h | 52 +- .../llvm/include/llvm/MC/MCTargetOptions.h | 11 + .../llvm/MC/MCTargetOptionsCommandFlags.h | 57 + gnu/llvm/llvm/include/llvm/MC/MCValue.h | 2 - .../llvm/include/llvm/MC/MCWasmObjectWriter.h | 2 +- .../llvm/include/llvm/MC/MCWasmStreamer.h | 36 +- .../include/llvm/MC/MCWinCOFFObjectWriter.h | 2 +- .../llvm/include/llvm/MC/MCWinCOFFStreamer.h | 29 +- .../include/llvm/MC/MCXCOFFObjectWriter.h | 7 + .../llvm/include/llvm/MC/MCXCOFFStreamer.h | 18 +- .../llvm/include/llvm/MC/StringTableBuilder.h | 10 + .../llvm/include/llvm/MC/SubtargetFeature.h | 2 +- gnu/llvm/llvm/include/llvm/MCA/CodeEmitter.h | 3 - .../include/llvm/MCA/HardwareUnits/LSUnit.h | 51 +- .../llvm/MCA/HardwareUnits/RegisterFile.h | 3 +- .../llvm/MCA/HardwareUnits/ResourceManager.h | 1 - gnu/llvm/llvm/include/llvm/MCA/Pipeline.h | 2 - .../include/llvm/MCA/Stages/DispatchStage.h | 1 - .../llvm/include/llvm/Object/ArchiveWriter.h | 3 - gnu/llvm/llvm/include/llvm/Object/Binary.h | 8 +- gnu/llvm/llvm/include/llvm/Object/COFF.h | 136 +- .../llvm/include/llvm/Object/COFFImportFile.h | 2 +- gnu/llvm/llvm/include/llvm/Object/ELF.h | 58 +- .../llvm/include/llvm/Object/ELFObjectFile.h | 121 +- gnu/llvm/llvm/include/llvm/Object/ELFTypes.h | 15 +- gnu/llvm/llvm/include/llvm/Object/Error.h | 10 +- .../llvm/include/llvm/Object/IRObjectFile.h | 2 +- gnu/llvm/llvm/include/llvm/Object/IRSymtab.h | 1 + gnu/llvm/llvm/include/llvm/Object/MachO.h | 11 +- .../llvm/include/llvm/Object/MachOUniversal.h | 23 +- .../include/llvm/Object/ModuleSymbolTable.h | 1 + .../llvm/include/llvm/Object/ObjectFile.h | 23 +- .../llvm/include/llvm/Object/SymbolicFile.h | 7 +- gnu/llvm/llvm/include/llvm/Object/TapiFile.h | 5 +- .../llvm/include/llvm/Object/TapiUniversal.h | 28 +- gnu/llvm/llvm/include/llvm/Object/Wasm.h | 13 +- .../include/llvm/Object/XCOFFObjectFile.h | 26 +- .../include/llvm/ObjectYAML/DWARFEmitter.h | 21 +- .../llvm/include/llvm/ObjectYAML/DWARFYAML.h | 91 +- .../llvm/include/llvm/ObjectYAML/ELFYAML.h | 138 +- .../llvm/include/llvm/ObjectYAML/MachOYAML.h | 20 + .../llvm/include/llvm/ObjectYAML/WasmYAML.h | 20 +- .../llvm/include/llvm/ObjectYAML/yaml2obj.h | 11 +- .../llvm/include/llvm/Option/OptParser.td | 43 + gnu/llvm/llvm/include/llvm/Option/Option.h | 14 +- gnu/llvm/llvm/include/llvm/Pass.h | 14 +- .../llvm/include/llvm/PassAnalysisSupport.h | 34 +- gnu/llvm/llvm/include/llvm/PassSupport.h | 4 + .../llvm/include/llvm/Passes/PassBuilder.h | 96 +- .../ProfileData/Coverage/CoverageMapping.h | 233 +- .../Coverage/CoverageMappingReader.h | 48 +- .../Coverage/CoverageMappingWriter.h | 5 +- gnu/llvm/llvm/include/llvm/ProfileData/GCOV.h | 322 +- .../llvm/include/llvm/ProfileData/InstrProf.h | 14 +- .../llvm/ProfileData/InstrProfData.inc | 51 +- .../include/llvm/ProfileData/ProfileCommon.h | 4 + .../include/llvm/ProfileData/SampleProf.h | 153 +- .../llvm/ProfileData/SampleProfReader.h | 35 +- .../llvm/ProfileData/SampleProfWriter.h | 34 +- gnu/llvm/llvm/include/llvm/Remarks/Remark.h | 2 +- .../llvm/include/llvm/Remarks/RemarkLinker.h | 3 +- .../include/llvm/Remarks/RemarkStreamer.h | 73 + .../include/llvm/Remarks/RemarkStringTable.h | 5 +- .../llvm/Support/AArch64TargetParser.def | 26 + .../llvm/Support/AArch64TargetParser.h | 11 +- .../include/llvm/Support/AMDGPUMetadata.h | 7 +- .../include/llvm/Support/ARMAttributeParser.h | 173 +- .../include/llvm/Support/ARMBuildAttributes.h | 109 +- .../include/llvm/Support/ARMTargetParser.def | 24 + .../include/llvm/Support/ARMTargetParser.h | 50 +- .../llvm/include/llvm/Support/Alignment.h | 166 +- .../llvm/include/llvm/Support/Allocator.h | 150 +- .../llvm/include/llvm/Support/AllocatorBase.h | 103 + .../include/llvm/Support/AtomicOrdering.h | 5 +- gnu/llvm/llvm/include/llvm/Support/Base64.h | 56 + .../include/llvm/Support/BinaryStreamArray.h | 1 + .../include/llvm/Support/BinaryStreamReader.h | 3 +- .../include/llvm/Support/BinaryStreamWriter.h | 2 +- .../include/llvm/Support/BranchProbability.h | 4 +- gnu/llvm/llvm/include/llvm/Support/CFGDiff.h | 250 + .../llvm/include/llvm/Support/CFGUpdate.h | 12 +- .../llvm/include/llvm/Support/CMakeLists.txt | 13 +- .../llvm/include/llvm/Support/CachePruning.h | 3 +- gnu/llvm/llvm/include/llvm/Support/Casting.h | 64 +- .../include/llvm/Support/CheckedArithmetic.h | 18 +- gnu/llvm/llvm/include/llvm/Support/Chrono.h | 4 +- .../llvm/include/llvm/Support/CommandLine.h | 29 +- gnu/llvm/llvm/include/llvm/Support/Compiler.h | 64 +- .../llvm/include/llvm/Support/DataExtractor.h | 146 +- .../llvm/include/llvm/Support/DebugCounter.h | 7 +- .../include/llvm/Support/ELFAttributeParser.h | 72 + .../llvm/include/llvm/Support/ELFAttributes.h | 37 + gnu/llvm/llvm/include/llvm/Support/Endian.h | 4 +- gnu/llvm/llvm/include/llvm/Support/Errno.h | 4 +- gnu/llvm/llvm/include/llvm/Support/Error.h | 35 +- .../llvm/include/llvm/Support/ErrorHandling.h | 11 +- gnu/llvm/llvm/include/llvm/Support/ErrorOr.h | 48 +- .../include/llvm/Support/ExtensibleRTTI.h | 135 + .../llvm/include/llvm/Support/FileCheck.h | 19 +- .../llvm/include/llvm/Support/FileCollector.h | 58 +- .../include/llvm/Support/FileOutputBuffer.h | 2 - .../include/llvm/Support/FormatAdapters.h | 11 +- .../include/llvm/Support/FormatProviders.h | 14 +- .../include/llvm/Support/FormatVariadic.h | 63 +- .../llvm/Support/FormatVariadicDetails.h | 34 +- .../include/llvm/Support/FormattedStream.h | 40 +- .../include/llvm/Support/GenericDomTree.h | 66 +- .../llvm/Support/GenericDomTreeConstruction.h | 77 +- .../GenericIteratedDominanceFrontier.h | 20 +- .../llvm/include/llvm/Support/GlobPattern.h | 4 +- .../llvm/include/llvm/Support/GraphWriter.h | 20 +- gnu/llvm/llvm/include/llvm/Support/Host.h | 8 +- .../Support/ItaniumManglingCanonicalizer.h | 6 +- gnu/llvm/llvm/include/llvm/Support/JSON.h | 29 +- .../llvm/include/llvm/Support/KnownBits.h | 93 +- gnu/llvm/llvm/include/llvm/Support/LEB128.h | 4 +- .../include/llvm/Support/LockFileManager.h | 4 +- .../include/llvm/Support/LowLevelTypeImpl.h | 28 + gnu/llvm/llvm/include/llvm/Support/MD5.h | 2 +- .../llvm/Support/MSVCErrorWorkarounds.h | 9 +- .../include/llvm/Support/MachineValueType.h | 489 +- .../llvm/include/llvm/Support/MathExtras.h | 77 +- gnu/llvm/llvm/include/llvm/Support/MemAlloc.h | 23 +- .../llvm/include/llvm/Support/MemoryBuffer.h | 22 +- .../include/llvm/Support/NativeFormatting.h | 3 +- .../llvm/Support/OptimizedStructLayout.h | 142 + gnu/llvm/llvm/include/llvm/Support/Parallel.h | 92 +- gnu/llvm/llvm/include/llvm/Support/Path.h | 42 +- .../llvm/Support/PointerLikeTypeTraits.h | 21 +- .../include/llvm/Support/PrettyStackTrace.h | 7 + gnu/llvm/llvm/include/llvm/Support/Process.h | 7 +- gnu/llvm/llvm/include/llvm/Support/Program.h | 28 +- .../llvm/Support/RISCVAttributeParser.h | 37 + .../include/llvm/Support/RISCVAttributes.h | 44 + .../llvm/Support/RISCVTargetParser.def | 13 + gnu/llvm/llvm/include/llvm/Support/Regex.h | 16 +- gnu/llvm/llvm/include/llvm/Support/SHA1.h | 9 +- .../llvm/include/llvm/Support/ScaledNumber.h | 4 +- .../llvm/Support/SmallVectorMemoryBuffer.h | 2 +- .../llvm/include/llvm/Support/SourceMgr.h | 98 +- .../include/llvm/Support/SpecialCaseList.h | 20 +- .../llvm/include/llvm/Support/SuffixTree.h | 350 + .../llvm/include/llvm/Support/SwapByteOrder.h | 81 +- .../llvm/include/llvm/Support/SystemUtils.h | 7 +- .../include/llvm/Support/TargetOpcodes.def | 41 +- .../llvm/include/llvm/Support/TargetParser.h | 79 +- .../llvm/include/llvm/Support/TaskQueue.h | 6 +- .../llvm/include/llvm/Support/ThreadPool.h | 25 +- .../llvm/include/llvm/Support/Threading.h | 98 +- .../llvm/include/llvm/Support/TimeProfiler.h | 26 +- .../include/llvm/Support/ToolOutputFile.h | 11 +- .../include/llvm/Support/TrailingObjects.h | 8 +- .../llvm/include/llvm/Support/TrigramIndex.h | 1 - gnu/llvm/llvm/include/llvm/Support/TypeSize.h | 70 +- .../llvm/include/llvm/Support/VersionTuple.h | 9 +- .../include/llvm/Support/VirtualFileSystem.h | 23 +- .../llvm/Support/Windows/WindowsSupport.h | 6 + .../llvm/include/llvm/Support/WithColor.h | 48 +- .../Support/X86DisassemblerDecoderCommon.h | 5 +- .../include/llvm/Support/X86TargetParser.def | 281 +- .../include/llvm/Support/X86TargetParser.h | 148 + .../llvm/include/llvm/Support/YAMLParser.h | 2 +- .../llvm/include/llvm/Support/YAMLTraits.h | 127 +- .../llvm/Support/circular_raw_ostream.h | 4 +- .../llvm/include/llvm/Support/raw_ostream.h | 93 +- .../llvm/include/llvm/Support/type_traits.h | 13 +- gnu/llvm/llvm/include/llvm/TableGen/Main.h | 2 +- gnu/llvm/llvm/include/llvm/TableGen/Record.h | 22 +- .../llvm/TableGen/StringToOffsetTable.h | 2 +- .../include/llvm/Target/GenericOpcodes.td | 110 +- .../include/llvm/Target/GlobalISel/Combine.td | 139 +- .../Target/GlobalISel/SelectionDAGCompat.td | 14 + .../include/llvm/Target/GlobalISel/Target.td | 9 +- gnu/llvm/llvm/include/llvm/Target/Target.td | 73 +- .../include/llvm/Target/TargetCallingConv.td | 5 + .../include/llvm/Target/TargetIntrinsicInfo.h | 1 - .../include/llvm/Target/TargetItinerary.td | 2 +- .../llvm/Target/TargetLoweringObjectFile.h | 66 +- .../llvm/include/llvm/Target/TargetMachine.h | 35 +- .../llvm/include/llvm/Target/TargetOptions.h | 94 +- .../include/llvm/Target/TargetSchedule.td | 4 +- .../include/llvm/Target/TargetSelectionDAG.td | 67 +- .../llvm/Testing/Support/Annotations.h | 2 + .../llvm/include/llvm/Testing/Support/Error.h | 42 + .../include/llvm/TextAPI/ELF/TBEHandler.h | 1 - .../llvm/TextAPI/MachO/Architecture.def | 27 +- .../include/llvm/TextAPI/MachO/Architecture.h | 14 +- .../llvm/TextAPI/MachO/ArchitectureSet.h | 5 +- .../llvm/TextAPI/MachO/InterfaceFile.h | 31 +- .../llvm/TextAPI/MachO/PackedVersion.h | 7 +- .../llvm/TextAPI/MachO/TextAPIReader.h | 4 +- .../llvm/TextAPI/MachO/TextAPIWriter.h | 6 +- .../llvm/Transforms/Coroutines/CoroCleanup.h | 28 + .../llvm/Transforms/Coroutines/CoroEarly.h | 31 + .../llvm/Transforms/Coroutines/CoroElide.h | 30 + .../llvm/Transforms/Coroutines/CoroSplit.h | 30 + gnu/llvm/llvm/include/llvm/Transforms/IPO.h | 24 +- .../llvm/Transforms/IPO/ArgumentPromotion.h | 12 + .../include/llvm/Transforms/IPO/Attributor.h | 1586 +- .../Transforms/IPO/DeadArgumentElimination.h | 1 + .../llvm/Transforms/IPO/FunctionImport.h | 10 +- .../include/llvm/Transforms/IPO/Inliner.h | 49 +- .../llvm/Transforms/IPO/LowerTypeTests.h | 7 +- .../include/llvm/Transforms/IPO/OpenMPOpt.h | 66 + .../llvm/Transforms/IPO/PassManagerBuilder.h | 11 +- .../IPO/SyntheticCountsPropagation.h | 12 +- .../llvm/Transforms/IPO/WholeProgramDevirt.h | 5 + .../llvm/Transforms/InstCombine/InstCombine.h | 16 +- .../InstCombine/InstCombineWorklist.h | 90 +- .../include/llvm/Transforms/Instrumentation.h | 25 +- .../Instrumentation/AddressSanitizer.h | 2 +- .../Instrumentation/AddressSanitizerCommon.h | 49 + .../Transforms/Instrumentation/CGProfile.h | 5 - .../Instrumentation/InstrProfiling.h | 3 + .../Instrumentation/SanitizerCoverage.h | 25 +- .../llvm/include/llvm/Transforms/Scalar.h | 4 - .../Scalar/AlignmentFromAssumptions.h | 8 +- .../llvm/Transforms/Scalar/Float2Int.h | 8 +- .../llvm/include/llvm/Transforms/Scalar/GVN.h | 58 +- .../llvm/Transforms/Scalar/GVNExpression.h | 9 +- .../Scalar/InductiveRangeCheckElimination.h | 4 +- .../llvm/Transforms/Scalar/JumpThreading.h | 11 +- .../llvm/Transforms/Scalar/LoopPassManager.h | 57 +- .../Transforms/Scalar/LoopUnrollAndJamPass.h | 3 - .../llvm/Transforms/Scalar/MemCpyOptimizer.h | 11 +- .../llvm/Transforms/Scalar/Reassociate.h | 4 +- gnu/llvm/llvm/include/llvm/Transforms/Utils.h | 37 +- .../llvm/Transforms/Utils/AMDGPUEmitPrintf.h | 25 + .../Transforms/Utils/AssumeBundleBuilder.h | 60 + .../llvm/Transforms/Utils/BasicBlockUtils.h | 100 +- .../llvm/Transforms/Utils/BuildLibCalls.h | 103 +- .../llvm/Transforms/Utils/CallGraphUpdater.h | 109 + .../Transforms/Utils/CallPromotionUtils.h | 39 +- .../Utils/CanonicalizeFreezeInLoops.h | 33 + .../include/llvm/Transforms/Utils/Cloning.h | 24 +- .../llvm/Transforms/Utils/CodeExtractor.h | 6 +- .../llvm/Transforms/Utils/CodeMoverUtils.h | 41 +- .../include/llvm/Transforms/Utils/Debugify.h | 22 + .../include/llvm/Transforms/Utils/Evaluator.h | 20 +- .../Transforms/Utils/FunctionComparator.h | 2 +- .../Transforms/Utils/FunctionImportUtils.h | 23 +- .../include/llvm/Transforms/Utils/Local.h | 102 +- .../llvm/Transforms/Utils/LoopSimplify.h | 8 +- .../include/llvm/Transforms/Utils/LoopUtils.h | 156 +- .../llvm/Transforms/Utils/LoopVersioning.h | 20 +- .../Transforms/Utils/LowerMemIntrinsics.h | 6 +- .../llvm/Transforms/Utils/ModuleUtils.h | 8 +- .../llvm/Transforms/Utils/PredicateInfo.h | 85 +- .../llvm/Transforms/Utils/PromoteMemToReg.h | 1 - .../llvm/Transforms/Utils/SSAUpdaterBulk.h | 1 - .../Utils/ScalarEvolutionExpander.h | 435 + .../llvm/Transforms/Utils/SimplifyIndVar.h | 7 +- .../llvm/Transforms/Utils/SimplifyLibCalls.h | 169 +- .../include/llvm/Transforms/Utils/SizeOpts.h | 51 +- .../Transforms/Utils/UnifyFunctionExitNodes.h | 3 +- .../Utils/UniqueInternalLinkageNames.h | 31 + .../llvm/Transforms/Utils/UnrollLoop.h | 46 +- .../llvm/Transforms/Utils/VNCoercion.h | 6 +- .../llvm/include/llvm/Transforms/Vectorize.h | 6 + .../Vectorize/LoopVectorizationLegality.h | 20 +- .../llvm/Transforms/Vectorize/LoopVectorize.h | 32 +- .../llvm/Transforms/Vectorize/SLPVectorizer.h | 13 +- .../llvm/Transforms/Vectorize/VectorCombine.h | 30 + gnu/llvm/llvm/include/llvm/XRay/Graph.h | 24 +- .../include/llvm/XRay/InstrumentationMap.h | 4 + gnu/llvm/llvm/include/llvm/module.modulemap | 27 +- gnu/llvm/llvm/lib/Analysis/AliasAnalysis.cpp | 14 +- .../lib/Analysis/AliasAnalysisEvaluator.cpp | 2 +- .../lib/Analysis/AliasAnalysisSummary.cpp | 1 + .../llvm/lib/Analysis/AliasAnalysisSummary.h | 5 +- .../llvm/lib/Analysis/AliasSetTracker.cpp | 2 +- .../llvm/lib/Analysis/AssumeBundleQueries.cpp | 206 + .../llvm/lib/Analysis/AssumptionCache.cpp | 64 +- .../llvm/lib/Analysis/BasicAliasAnalysis.cpp | 132 +- .../llvm/lib/Analysis/BlockFrequencyInfo.cpp | 7 +- .../lib/Analysis/BlockFrequencyInfoImpl.cpp | 17 +- .../lib/Analysis/BranchProbabilityInfo.cpp | 265 +- gnu/llvm/llvm/lib/Analysis/CFG.cpp | 8 +- gnu/llvm/llvm/lib/Analysis/CFGPrinter.cpp | 309 +- .../lib/Analysis/CFLAndersAliasAnalysis.cpp | 2 +- .../llvm/lib/Analysis/CGSCCPassManager.cpp | 169 +- gnu/llvm/llvm/lib/Analysis/CMakeLists.txt | 48 +- gnu/llvm/llvm/lib/Analysis/CallGraph.cpp | 72 +- .../llvm/lib/Analysis/CallGraphSCCPass.cpp | 74 +- gnu/llvm/llvm/lib/Analysis/CallPrinter.cpp | 272 +- .../llvm/lib/Analysis/CaptureTracking.cpp | 48 +- gnu/llvm/llvm/lib/Analysis/CodeMetrics.cpp | 5 +- .../llvm/lib/Analysis/ConstantFolding.cpp | 531 +- gnu/llvm/llvm/lib/Analysis/DDG.cpp | 46 +- .../llvm/lib/Analysis/DependenceAnalysis.cpp | 160 +- .../lib/Analysis/DependenceGraphBuilder.cpp | 104 + .../llvm/lib/Analysis/DivergenceAnalysis.cpp | 40 +- gnu/llvm/llvm/lib/Analysis/DomPrinter.cpp | 8 +- gnu/llvm/llvm/lib/Analysis/DomTreeUpdater.cpp | 6 +- gnu/llvm/llvm/lib/Analysis/GlobalsModRef.cpp | 12 +- gnu/llvm/llvm/lib/Analysis/GuardUtils.cpp | 8 +- gnu/llvm/llvm/lib/Analysis/HeatUtils.cpp | 78 + gnu/llvm/llvm/lib/Analysis/IVDescriptors.cpp | 1 + .../IndirectCallPromotionAnalysis.cpp | 1 - gnu/llvm/llvm/lib/Analysis/InlineAdvisor.cpp | 408 + gnu/llvm/llvm/lib/Analysis/InlineCost.cpp | 479 +- .../lib/Analysis/InlineFeaturesAnalysis.cpp | 41 + .../Analysis/InlineSizeEstimatorAnalysis.cpp | 299 + .../InstructionPrecedenceTracking.cpp | 27 +- .../llvm/lib/Analysis/InstructionSimplify.cpp | 476 +- gnu/llvm/llvm/lib/Analysis/LazyCallGraph.cpp | 57 +- gnu/llvm/llvm/lib/Analysis/LazyValueInfo.cpp | 1009 +- .../lib/Analysis/LegacyDivergenceAnalysis.cpp | 9 +- gnu/llvm/llvm/lib/Analysis/Lint.cpp | 135 +- gnu/llvm/llvm/lib/Analysis/Loads.cpp | 129 +- .../llvm/lib/Analysis/LoopAccessAnalysis.cpp | 278 +- .../llvm/lib/Analysis/LoopAnalysisManager.cpp | 1 + .../llvm/lib/Analysis/LoopCacheAnalysis.cpp | 46 +- gnu/llvm/llvm/lib/Analysis/LoopInfo.cpp | 11 +- .../llvm/lib/Analysis/LoopNestAnalysis.cpp | 296 + gnu/llvm/llvm/lib/Analysis/LoopPass.cpp | 37 +- .../llvm/lib/Analysis/LoopUnrollAnalyzer.cpp | 1 + .../llvm/lib/Analysis/MLInlineAdvisor.cpp | 301 + gnu/llvm/llvm/lib/Analysis/MemDepPrinter.cpp | 2 + .../llvm/lib/Analysis/MemDerefPrinter.cpp | 3 +- gnu/llvm/llvm/lib/Analysis/MemoryBuiltins.cpp | 70 +- .../lib/Analysis/MemoryDependenceAnalysis.cpp | 220 +- gnu/llvm/llvm/lib/Analysis/MemoryLocation.cpp | 17 + gnu/llvm/llvm/lib/Analysis/MemorySSA.cpp | 11 +- .../llvm/lib/Analysis/MemorySSAUpdater.cpp | 14 +- .../lib/Analysis/ModuleSummaryAnalysis.cpp | 97 +- gnu/llvm/llvm/lib/Analysis/MustExecute.cpp | 175 +- .../lib/Analysis/ObjCARCAliasAnalysis.cpp | 4 +- .../llvm/lib/Analysis/ObjCARCInstKind.cpp | 8 +- .../Analysis/OptimizationRemarkEmitter.cpp | 7 +- .../llvm/lib/Analysis/ProfileSummaryInfo.cpp | 279 +- gnu/llvm/llvm/lib/Analysis/RegionPrinter.cpp | 8 +- .../lib/Analysis/ReleaseModeModelRunner.cpp | 87 + .../llvm/lib/Analysis/ScalarEvolution.cpp | 512 +- .../lib/Analysis/ScalarEvolutionDivision.cpp | 259 + gnu/llvm/llvm/lib/Analysis/StackLifetime.cpp | 373 + .../llvm/lib/Analysis/StackSafetyAnalysis.cpp | 915 +- .../lib/Analysis/SyncDependenceAnalysis.cpp | 10 +- .../lib/Analysis/SyntheticCountsUtils.cpp | 1 - gnu/llvm/llvm/lib/Analysis/TFUtils.cpp | 289 + .../llvm/lib/Analysis/TargetLibraryInfo.cpp | 42 +- .../llvm/lib/Analysis/TargetTransformInfo.cpp | 717 +- .../llvm/lib/Analysis/TypeMetadataUtils.cpp | 9 +- .../llvm/lib/Analysis/VFABIDemangling.cpp | 108 +- gnu/llvm/llvm/lib/Analysis/ValueLattice.cpp | 6 + .../llvm/lib/Analysis/ValueLatticeUtils.cpp | 18 +- gnu/llvm/llvm/lib/Analysis/ValueTracking.cpp | 1413 +- gnu/llvm/llvm/lib/Analysis/VectorUtils.cpp | 269 +- .../Analysis/models/inliner/saved_model.pbtxt | 32634 ++++++++++++++++ .../variables/variables.data-00000-of-00001 | Bin 0 -> 39110 bytes .../models/inliner/variables/variables.index | Bin 0 -> 377 bytes gnu/llvm/llvm/lib/AsmParser/CMakeLists.txt | 2 +- gnu/llvm/llvm/lib/AsmParser/LLLexer.cpp | 20 +- gnu/llvm/llvm/lib/AsmParser/LLLexer.h | 4 +- gnu/llvm/llvm/lib/AsmParser/LLParser.cpp | 534 +- gnu/llvm/llvm/lib/AsmParser/LLParser.h | 36 +- gnu/llvm/llvm/lib/AsmParser/LLToken.h | 8 + gnu/llvm/llvm/lib/AsmParser/Parser.cpp | 101 +- .../BinaryFormat/AMDGPUMetadataVerifier.cpp | 20 +- gnu/llvm/llvm/lib/BinaryFormat/CMakeLists.txt | 1 + gnu/llvm/llvm/lib/BinaryFormat/Dwarf.cpp | 33 + gnu/llvm/llvm/lib/BinaryFormat/MachO.cpp | 109 + gnu/llvm/llvm/lib/BinaryFormat/Magic.cpp | 3 +- .../llvm/lib/BinaryFormat/MsgPackDocument.cpp | 122 +- gnu/llvm/llvm/lib/BinaryFormat/Wasm.cpp | 4 + gnu/llvm/llvm/lib/BinaryFormat/XCOFF.cpp | 80 +- .../lib/Bitcode/Reader/BitcodeAnalyzer.cpp | 15 +- .../llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 404 +- .../lib/Bitcode/Reader/MetadataLoader.cpp | 90 +- .../llvm/lib/Bitcode/Reader/MetadataLoader.h | 2 - .../llvm/lib/Bitcode/Reader/ValueList.cpp | 2 +- .../llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | 170 +- .../lib/Bitcode/Writer/ValueEnumerator.cpp | 49 +- .../llvm/lib/Bitcode/Writer/ValueEnumerator.h | 2 - .../lib/Bitstream/Reader/BitstreamReader.cpp | 18 +- .../lib/CodeGen/AggressiveAntiDepBreaker.cpp | 11 +- .../lib/CodeGen/AggressiveAntiDepBreaker.h | 2 +- gnu/llvm/llvm/lib/CodeGen/AllocationOrder.h | 3 +- gnu/llvm/llvm/lib/CodeGen/Analysis.cpp | 84 +- .../lib/CodeGen/AsmPrinter/ARMException.cpp | 12 +- .../lib/CodeGen/AsmPrinter/AccelTable.cpp | 42 +- .../lib/CodeGen/AsmPrinter/AddressPool.cpp | 10 +- .../lib/CodeGen/AsmPrinter/AsmPrinter.cpp | 913 +- .../CodeGen/AsmPrinter/AsmPrinterDwarf.cpp | 78 +- .../AsmPrinter/AsmPrinterInlineAsm.cpp | 13 +- .../lib/CodeGen/AsmPrinter/ByteStreamer.h | 24 +- .../lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | 275 +- .../lib/CodeGen/AsmPrinter/CodeViewDebug.h | 13 +- gnu/llvm/llvm/lib/CodeGen/AsmPrinter/DIE.cpp | 90 +- .../llvm/lib/CodeGen/AsmPrinter/DIEHash.cpp | 9 +- .../llvm/lib/CodeGen/AsmPrinter/DIEHash.h | 1 - .../AsmPrinter/DbgEntityHistoryCalculator.cpp | 3 +- .../CodeGen/AsmPrinter/DebugHandlerBase.cpp | 39 +- .../CodeGen/AsmPrinter/DwarfCFIException.cpp | 23 +- .../CodeGen/AsmPrinter/DwarfCompileUnit.cpp | 203 +- .../lib/CodeGen/AsmPrinter/DwarfCompileUnit.h | 34 +- .../lib/CodeGen/AsmPrinter/DwarfDebug.cpp | 910 +- .../llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h | 27 +- .../lib/CodeGen/AsmPrinter/DwarfException.h | 3 + .../CodeGen/AsmPrinter/DwarfExpression.cpp | 134 +- .../lib/CodeGen/AsmPrinter/DwarfExpression.h | 74 +- .../llvm/lib/CodeGen/AsmPrinter/DwarfFile.cpp | 2 +- .../CodeGen/AsmPrinter/DwarfStringPool.cpp | 8 +- .../llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp | 84 +- .../llvm/lib/CodeGen/AsmPrinter/DwarfUnit.h | 1 - .../lib/CodeGen/AsmPrinter/EHStreamer.cpp | 50 +- .../CodeGen/AsmPrinter/ErlangGCPrinter.cpp | 4 +- .../lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp | 12 +- .../lib/CodeGen/AsmPrinter/WasmException.cpp | 4 +- .../lib/CodeGen/AsmPrinter/WinException.cpp | 129 +- .../lib/CodeGen/AsmPrinter/WinException.h | 2 - .../llvm/lib/CodeGen/AtomicExpandPass.cpp | 346 +- .../llvm/lib/CodeGen/BBSectionsPrepare.cpp | 457 + gnu/llvm/llvm/lib/CodeGen/BranchFolding.cpp | 154 +- gnu/llvm/llvm/lib/CodeGen/BranchFolding.h | 31 +- .../llvm/lib/CodeGen/BranchRelaxation.cpp | 16 +- gnu/llvm/llvm/lib/CodeGen/BreakFalseDeps.cpp | 9 + .../llvm/lib/CodeGen/CFIInstrInserter.cpp | 191 +- gnu/llvm/llvm/lib/CodeGen/CMakeLists.txt | 10 +- .../llvm/lib/CodeGen/CalcSpillWeights.cpp | 9 +- .../llvm/lib/CodeGen/CallingConvLower.cpp | 34 +- gnu/llvm/llvm/lib/CodeGen/CodeGen.cpp | 5 + gnu/llvm/llvm/lib/CodeGen/CodeGenPrepare.cpp | 910 +- gnu/llvm/llvm/lib/CodeGen/CommandFlags.cpp | 634 + .../lib/CodeGen/CriticalAntiDepBreaker.cpp | 9 +- .../llvm/lib/CodeGen/CriticalAntiDepBreaker.h | 2 +- gnu/llvm/llvm/lib/CodeGen/DwarfEHPrepare.cpp | 19 +- .../llvm/lib/CodeGen/EarlyIfConversion.cpp | 19 +- gnu/llvm/llvm/lib/CodeGen/EdgeBundles.cpp | 1 + gnu/llvm/llvm/lib/CodeGen/ExpandMemCmp.cpp | 185 +- .../llvm/lib/CodeGen/ExpandReductions.cpp | 6 +- gnu/llvm/llvm/lib/CodeGen/FEntryInserter.cpp | 4 +- gnu/llvm/llvm/lib/CodeGen/FaultMaps.cpp | 22 +- .../CodeGen/FixupStatepointCallerSaved.cpp | 311 + gnu/llvm/llvm/lib/CodeGen/GCMetadata.cpp | 2 +- gnu/llvm/llvm/lib/CodeGen/GCRootLowering.cpp | 14 +- .../lib/CodeGen/GlobalISel/CMakeLists.txt | 5 + .../llvm/lib/CodeGen/GlobalISel/CSEInfo.cpp | 60 +- .../lib/CodeGen/GlobalISel/CSEMIRBuilder.cpp | 2 +- .../lib/CodeGen/GlobalISel/CallLowering.cpp | 119 +- .../lib/CodeGen/GlobalISel/CombinerHelper.cpp | 576 +- .../GlobalISel/GISelChangeObserver.cpp | 8 + .../lib/CodeGen/GlobalISel/GISelKnownBits.cpp | 263 +- .../lib/CodeGen/GlobalISel/IRTranslator.cpp | 515 +- .../CodeGen/GlobalISel/InlineAsmLowering.cpp | 671 + .../CodeGen/GlobalISel/InstructionSelect.cpp | 15 +- .../GlobalISel/InstructionSelector.cpp | 2 +- .../CodeGen/GlobalISel/LegalityPredicates.cpp | 38 +- .../llvm/lib/CodeGen/GlobalISel/Legalizer.cpp | 72 +- .../CodeGen/GlobalISel/LegalizerHelper.cpp | 2006 +- .../lib/CodeGen/GlobalISel/LegalizerInfo.cpp | 22 +- .../llvm/lib/CodeGen/GlobalISel/Localizer.cpp | 65 +- .../GlobalISel/LostDebugLocObserver.cpp | 113 + .../CodeGen/GlobalISel/MachineIRBuilder.cpp | 163 +- .../lib/CodeGen/GlobalISel/RegBankSelect.cpp | 9 + .../llvm/lib/CodeGen/GlobalISel/Utils.cpp | 266 +- gnu/llvm/llvm/lib/CodeGen/GlobalMerge.cpp | 5 +- gnu/llvm/llvm/lib/CodeGen/HardwareLoops.cpp | 23 +- gnu/llvm/llvm/lib/CodeGen/IfConversion.cpp | 38 +- .../llvm/lib/CodeGen/ImplicitNullChecks.cpp | 8 +- gnu/llvm/llvm/lib/CodeGen/InlineSpiller.cpp | 158 +- gnu/llvm/llvm/lib/CodeGen/InterferenceCache.h | 2 - .../lib/CodeGen/InterleavedAccessPass.cpp | 10 +- .../CodeGen/InterleavedLoadCombinePass.cpp | 26 +- .../llvm/lib/CodeGen/IntrinsicLowering.cpp | 19 +- .../llvm/lib/CodeGen/LLVMTargetMachine.cpp | 3 - gnu/llvm/llvm/lib/CodeGen/LexicalScopes.cpp | 55 +- gnu/llvm/llvm/lib/CodeGen/LiveDebugValues.cpp | 799 +- .../llvm/lib/CodeGen/LiveDebugVariables.cpp | 297 +- .../llvm/lib/CodeGen/LiveDebugVariables.h | 2 +- .../llvm/lib/CodeGen/LiveIntervalCalc.cpp | 205 + gnu/llvm/llvm/lib/CodeGen/LiveIntervals.cpp | 102 +- gnu/llvm/llvm/lib/CodeGen/LivePhysRegs.cpp | 13 + gnu/llvm/llvm/lib/CodeGen/LiveRangeCalc.cpp | 154 +- gnu/llvm/llvm/lib/CodeGen/LiveRangeEdit.cpp | 27 +- gnu/llvm/llvm/lib/CodeGen/LiveRangeShrink.cpp | 3 +- gnu/llvm/llvm/lib/CodeGen/LiveVariables.cpp | 28 + .../lib/CodeGen/LocalStackSlotAllocation.cpp | 34 +- gnu/llvm/llvm/lib/CodeGen/LowLevelType.cpp | 2 +- gnu/llvm/llvm/lib/CodeGen/LowerEmuTLS.cpp | 19 +- gnu/llvm/llvm/lib/CodeGen/MBFIWrapper.cpp | 49 + .../llvm/lib/CodeGen/MIRCanonicalizerPass.cpp | 4 +- .../llvm/lib/CodeGen/MIRParser/CMakeLists.txt | 3 + .../llvm/lib/CodeGen/MIRParser/MILexer.cpp | 23 +- gnu/llvm/llvm/lib/CodeGen/MIRParser/MILexer.h | 3 +- .../llvm/lib/CodeGen/MIRParser/MIParser.cpp | 104 +- .../llvm/lib/CodeGen/MIRParser/MIRParser.cpp | 63 +- gnu/llvm/llvm/lib/CodeGen/MIRPrinter.cpp | 72 +- .../llvm/lib/CodeGen/MIRVRegNamerUtils.cpp | 8 +- gnu/llvm/llvm/lib/CodeGen/MIRVRegNamerUtils.h | 18 +- .../llvm/lib/CodeGen/MachineBasicBlock.cpp | 247 +- .../lib/CodeGen/MachineBlockFrequencyInfo.cpp | 6 + .../lib/CodeGen/MachineBlockPlacement.cpp | 298 +- gnu/llvm/llvm/lib/CodeGen/MachineCSE.cpp | 15 +- gnu/llvm/llvm/lib/CodeGen/MachineCombiner.cpp | 8 +- .../lib/CodeGen/MachineCopyPropagation.cpp | 8 +- gnu/llvm/llvm/lib/CodeGen/MachineDebugify.cpp | 172 + .../llvm/lib/CodeGen/MachineFrameInfo.cpp | 28 +- gnu/llvm/llvm/lib/CodeGen/MachineFunction.cpp | 174 +- gnu/llvm/llvm/lib/CodeGen/MachineInstr.cpp | 142 +- .../llvm/lib/CodeGen/MachineInstrBundle.cpp | 29 +- gnu/llvm/llvm/lib/CodeGen/MachineLICM.cpp | 38 +- .../llvm/lib/CodeGen/MachineLoopUtils.cpp | 3 +- .../llvm/lib/CodeGen/MachineModuleInfo.cpp | 61 +- gnu/llvm/llvm/lib/CodeGen/MachineOperand.cpp | 32 +- .../MachineOptimizationRemarkEmitter.cpp | 2 +- gnu/llvm/llvm/lib/CodeGen/MachineOutliner.cpp | 658 +- .../llvm/lib/CodeGen/MachinePipeliner.cpp | 150 +- .../llvm/lib/CodeGen/MachineRegisterInfo.cpp | 72 +- .../llvm/lib/CodeGen/MachineSSAUpdater.cpp | 54 +- .../llvm/lib/CodeGen/MachineScheduler.cpp | 167 +- gnu/llvm/llvm/lib/CodeGen/MachineSink.cpp | 44 +- gnu/llvm/llvm/lib/CodeGen/MachineSizeOpts.cpp | 90 +- .../llvm/lib/CodeGen/MachineStripDebug.cpp | 111 + gnu/llvm/llvm/lib/CodeGen/MachineVerifier.cpp | 629 +- gnu/llvm/llvm/lib/CodeGen/ModuloSchedule.cpp | 74 +- gnu/llvm/llvm/lib/CodeGen/PHIElimination.cpp | 45 +- .../llvm/lib/CodeGen/PHIEliminationUtils.cpp | 45 +- gnu/llvm/llvm/lib/CodeGen/ParallelCG.cpp | 2 +- .../llvm/lib/CodeGen/PatchableFunction.cpp | 11 +- .../llvm/lib/CodeGen/PeepholeOptimizer.cpp | 23 +- .../llvm/lib/CodeGen/PostRASchedulerList.cpp | 14 +- .../lib/CodeGen/PreISelIntrinsicLowering.cpp | 4 +- .../llvm/lib/CodeGen/PrologEpilogInserter.cpp | 105 +- .../llvm/lib/CodeGen/ReachingDefAnalysis.cpp | 527 +- gnu/llvm/llvm/lib/CodeGen/RegAllocBase.cpp | 4 +- gnu/llvm/llvm/lib/CodeGen/RegAllocBase.h | 4 +- gnu/llvm/llvm/lib/CodeGen/RegAllocBasic.cpp | 26 +- gnu/llvm/llvm/lib/CodeGen/RegAllocFast.cpp | 6 +- gnu/llvm/llvm/lib/CodeGen/RegAllocGreedy.cpp | 169 +- gnu/llvm/llvm/lib/CodeGen/RegAllocPBQP.cpp | 12 +- .../lib/CodeGen/RegUsageInfoPropagate.cpp | 11 +- .../llvm/lib/CodeGen/RegisterCoalescer.cpp | 62 +- .../llvm/lib/CodeGen/RegisterPressure.cpp | 4 +- .../llvm/lib/CodeGen/RegisterScavenging.cpp | 6 +- gnu/llvm/llvm/lib/CodeGen/SafeStack.cpp | 62 +- gnu/llvm/llvm/lib/CodeGen/SafeStackLayout.cpp | 10 +- gnu/llvm/llvm/lib/CodeGen/SafeStackLayout.h | 10 +- .../lib/CodeGen/ScalarizeMaskedMemIntrin.cpp | 106 +- gnu/llvm/llvm/lib/CodeGen/ScheduleDAG.cpp | 8 + .../llvm/lib/CodeGen/ScheduleDAGInstrs.cpp | 19 +- .../llvm/lib/CodeGen/ScheduleDAGPrinter.cpp | 2 +- .../CodeGen/ScoreboardHazardRecognizer.cpp | 13 +- .../lib/CodeGen/SelectionDAG/FastISel.cpp | 309 +- .../SelectionDAG/FunctionLoweringInfo.cpp | 75 +- .../lib/CodeGen/SelectionDAG/InstrEmitter.cpp | 96 +- .../lib/CodeGen/SelectionDAG/InstrEmitter.h | 34 +- .../lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | 342 +- .../SelectionDAG/LegalizeFloatTypes.cpp | 479 +- .../SelectionDAG/LegalizeIntegerTypes.cpp | 299 +- .../CodeGen/SelectionDAG/LegalizeTypes.cpp | 62 +- .../lib/CodeGen/SelectionDAG/LegalizeTypes.h | 89 +- .../SelectionDAG/LegalizeTypesGeneric.cpp | 58 +- .../SelectionDAG/LegalizeVectorOps.cpp | 202 +- .../SelectionDAG/LegalizeVectorTypes.cpp | 748 +- .../SelectionDAG/ResourcePriorityQueue.cpp | 4 + .../CodeGen/SelectionDAG/ScheduleDAGFast.cpp | 2 +- .../SelectionDAG/ScheduleDAGRRList.cpp | 4 +- .../SelectionDAG/ScheduleDAGSDNodes.cpp | 38 +- .../CodeGen/SelectionDAG/ScheduleDAGSDNodes.h | 2 +- .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp | 1298 +- .../SelectionDAG/SelectionDAGBuilder.cpp | 1578 +- .../SelectionDAG/SelectionDAGBuilder.h | 19 +- .../SelectionDAG/SelectionDAGDumper.cpp | 18 +- .../CodeGen/SelectionDAG/SelectionDAGISel.cpp | 90 +- .../SelectionDAG/SelectionDAGPrinter.cpp | 16 +- .../SelectionDAG/StatepointLowering.cpp | 429 +- .../CodeGen/SelectionDAG/StatepointLowering.h | 2 - .../CodeGen/SelectionDAG/TargetLowering.cpp | 1511 +- gnu/llvm/llvm/lib/CodeGen/ShrinkWrap.cpp | 16 +- gnu/llvm/llvm/lib/CodeGen/SjLjEHPrepare.cpp | 36 +- gnu/llvm/llvm/lib/CodeGen/SlotIndexes.cpp | 9 +- gnu/llvm/llvm/lib/CodeGen/SplitKit.cpp | 86 +- gnu/llvm/llvm/lib/CodeGen/SplitKit.h | 27 +- gnu/llvm/llvm/lib/CodeGen/StackColoring.cpp | 9 +- gnu/llvm/llvm/lib/CodeGen/StackMaps.cpp | 72 +- gnu/llvm/llvm/lib/CodeGen/StackProtector.cpp | 37 +- .../llvm/lib/CodeGen/StackSlotColoring.cpp | 10 +- .../lib/CodeGen/SwiftErrorValueTracking.cpp | 5 +- .../llvm/lib/CodeGen/SwitchLoweringUtils.cpp | 1 + gnu/llvm/llvm/lib/CodeGen/TailDuplication.cpp | 6 +- gnu/llvm/llvm/lib/CodeGen/TailDuplicator.cpp | 117 +- .../lib/CodeGen/TargetFrameLoweringImpl.cpp | 21 +- gnu/llvm/llvm/lib/CodeGen/TargetInstrInfo.cpp | 125 +- .../llvm/lib/CodeGen/TargetLoweringBase.cpp | 347 +- .../CodeGen/TargetLoweringObjectFileImpl.cpp | 454 +- .../llvm/lib/CodeGen/TargetOptionsImpl.cpp | 6 + .../llvm/lib/CodeGen/TargetPassConfig.cpp | 157 +- .../llvm/lib/CodeGen/TargetRegisterInfo.cpp | 74 +- .../lib/CodeGen/TwoAddressInstructionPass.cpp | 194 +- gnu/llvm/llvm/lib/CodeGen/TypePromotion.cpp | 1 + .../llvm/lib/CodeGen/UnreachableBlockElim.cpp | 6 +- gnu/llvm/llvm/lib/CodeGen/ValueTypes.cpp | 473 +- gnu/llvm/llvm/lib/CodeGen/VirtRegMap.cpp | 4 +- gnu/llvm/llvm/lib/CodeGen/WasmEHPrepare.cpp | 169 +- gnu/llvm/llvm/lib/CodeGen/WinEHPrepare.cpp | 42 +- .../llvm/lib/CodeGen/XRayInstrumentation.cpp | 135 +- gnu/llvm/llvm/lib/DWARFLinker/CMakeLists.txt | 4 + gnu/llvm/llvm/lib/DWARFLinker/DWARFLinker.cpp | 2575 ++ .../DWARFLinker/DWARFLinkerCompileUnit.cpp | 8 + .../DWARFLinker/DWARFLinkerDeclContext.cpp | 8 +- .../llvm/lib/DWARFLinker/DWARFStreamer.cpp | 774 + .../CodeView/AppendingTypeTableBuilder.cpp | 23 +- .../DebugInfo/CodeView/CodeViewRecordIO.cpp | 40 +- .../CodeView/DebugSubsectionRecord.cpp | 22 +- .../CodeView/GlobalTypeTableBuilder.cpp | 34 + .../CodeView/LazyRandomTypeCollection.cpp | 5 + .../CodeView/MergingTypeTableBuilder.cpp | 27 + .../lib/DebugInfo/CodeView/RecordName.cpp | 2 +- .../CodeView/SimpleTypeSerializer.cpp | 11 + .../DebugInfo/CodeView/TypeRecordMapping.cpp | 39 +- .../DebugInfo/CodeView/TypeStreamMerger.cpp | 3 +- .../CodeView/TypeTableCollection.cpp | 5 + .../DWARF/DWARFAbbreviationDeclaration.cpp | 36 +- .../DebugInfo/DWARF/DWARFAcceleratorTable.cpp | 92 +- .../lib/DebugInfo/DWARF/DWARFCompileUnit.cpp | 14 +- .../llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | 406 +- .../DebugInfo/DWARF/DWARFDataExtractor.cpp | 37 +- .../lib/DebugInfo/DWARF/DWARFDebugAddr.cpp | 258 +- .../DebugInfo/DWARF/DWARFDebugArangeSet.cpp | 198 +- .../lib/DebugInfo/DWARF/DWARFDebugAranges.cpp | 19 +- .../lib/DebugInfo/DWARF/DWARFDebugFrame.cpp | 433 +- .../lib/DebugInfo/DWARF/DWARFDebugLine.cpp | 783 +- .../lib/DebugInfo/DWARF/DWARFDebugLoc.cpp | 17 +- .../lib/DebugInfo/DWARF/DWARFDebugMacro.cpp | 185 +- .../DebugInfo/DWARF/DWARFDebugPubTable.cpp | 93 +- .../llvm/lib/DebugInfo/DWARF/DWARFDie.cpp | 33 +- .../lib/DebugInfo/DWARF/DWARFExpression.cpp | 231 +- .../lib/DebugInfo/DWARF/DWARFFormValue.cpp | 70 +- .../lib/DebugInfo/DWARF/DWARFListTable.cpp | 50 +- .../lib/DebugInfo/DWARF/DWARFTypeUnit.cpp | 23 +- .../llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp | 164 +- .../lib/DebugInfo/DWARF/DWARFUnitIndex.cpp | 142 +- .../lib/DebugInfo/DWARF/DWARFVerifier.cpp | 82 +- .../llvm/lib/DebugInfo/GSYM/CMakeLists.txt | 6 + .../lib/DebugInfo/GSYM/DwarfTransformer.cpp | 572 + .../llvm/lib/DebugInfo/GSYM/FunctionInfo.cpp | 11 +- .../llvm/lib/DebugInfo/GSYM/GsymCreator.cpp | 61 +- .../llvm/lib/DebugInfo/GSYM/GsymReader.cpp | 153 +- .../llvm/lib/DebugInfo/GSYM/InlineInfo.cpp | 18 +- .../llvm/lib/DebugInfo/GSYM/LLVMBuild.txt | 2 +- .../llvm/lib/DebugInfo/GSYM/LookupResult.cpp | 31 +- .../DebugInfo/GSYM/ObjectFileTransformer.cpp | 116 + gnu/llvm/llvm/lib/DebugInfo/GSYM/Range.cpp | 10 + .../llvm/lib/DebugInfo/PDB/CMakeLists.txt | 5 + .../llvm/lib/DebugInfo/PDB/DIA/DIASession.cpp | 8 +- gnu/llvm/llvm/lib/DebugInfo/PDB/LLVMBuild.txt | 2 +- .../PDB/Native/DbiModuleDescriptorBuilder.cpp | 18 +- .../DebugInfo/PDB/Native/DbiStreamBuilder.cpp | 17 +- .../lib/DebugInfo/PDB/Native/EnumTables.cpp | 2 +- .../DebugInfo/PDB/Native/GSIStreamBuilder.cpp | 446 +- .../PDB/Native/NativeCompilandSymbol.cpp | 4 +- .../PDB/Native/NativeEnumInjectedSources.cpp | 6 +- .../PDB/Native/NativeEnumLineNumbers.cpp | 42 + .../DebugInfo/PDB/Native/NativeExeSymbol.cpp | 2 +- .../PDB/Native/NativeFunctionSymbol.cpp | 57 + .../DebugInfo/PDB/Native/NativeLineNumber.cpp | 50 + .../PDB/Native/NativePublicSymbol.cpp | 52 + .../DebugInfo/PDB/Native/NativeSession.cpp | 197 +- .../DebugInfo/PDB/Native/NativeSourceFile.cpp | 47 + .../PDB/Native/NativeSymbolEnumerator.cpp | 4 +- .../DebugInfo/PDB/Native/NativeTypeArray.cpp | 2 +- .../DebugInfo/PDB/Native/NativeTypeEnum.cpp | 2 +- .../PDB/Native/NativeTypeTypedef.cpp | 4 +- .../DebugInfo/PDB/Native/NativeTypeUDT.cpp | 2 +- .../llvm/lib/DebugInfo/PDB/Native/PDBFile.cpp | 3 +- .../DebugInfo/PDB/Native/PDBFileBuilder.cpp | 7 +- .../lib/DebugInfo/PDB/Native/SymbolCache.cpp | 377 +- gnu/llvm/llvm/lib/DebugInfo/PDB/PDB.cpp | 19 +- .../lib/DebugInfo/Symbolize/DIPrinter.cpp | 4 +- .../Symbolize/SymbolizableObjectFile.cpp | 62 +- .../Symbolize/SymbolizableObjectFile.h | 15 +- .../lib/DebugInfo/Symbolize/Symbolize.cpp | 51 +- gnu/llvm/llvm/lib/Demangle/Demangle.cpp | 4 +- .../llvm/lib/Demangle/ItaniumDemangle.cpp | 6 +- .../llvm/lib/Demangle/MicrosoftDemangle.cpp | 7 +- .../lib/ExecutionEngine/ExecutionEngine.cpp | 89 +- .../ExecutionEngineBindings.cpp | 12 + .../IntelJITEvents/jitprofiling.c | 2 +- .../ExecutionEngine/Interpreter/Execution.cpp | 172 +- .../Interpreter/ExternalFunctions.cpp | 2 +- .../ExecutionEngine/Interpreter/Interpreter.h | 14 +- .../JITLink/BasicGOTAndStubsBuilder.h | 30 +- .../ExecutionEngine/JITLink/CMakeLists.txt | 12 + .../llvm/lib/ExecutionEngine/JITLink/ELF.cpp | 51 + .../ExecutionEngine/JITLink/ELF_x86_64.cpp | 463 + .../lib/ExecutionEngine/JITLink/JITLink.cpp | 17 +- .../JITLink/JITLinkGeneric.cpp | 119 +- .../ExecutionEngine/JITLink/JITLinkGeneric.h | 109 +- .../JITLink/JITLinkMemoryManager.cpp | 2 +- .../lib/ExecutionEngine/JITLink/MachO.cpp | 26 +- .../JITLink/MachOLinkGraphBuilder.cpp | 82 +- .../JITLink/MachOLinkGraphBuilder.h | 28 +- .../ExecutionEngine/JITLink/MachO_arm64.cpp | 34 +- .../ExecutionEngine/JITLink/MachO_x86_64.cpp | 131 +- .../llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp | 10 +- .../llvm/lib/ExecutionEngine/MCJIT/MCJIT.h | 5 +- .../lib/ExecutionEngine/Orc/CMakeLists.txt | 3 + .../Orc/CompileOnDemandLayer.cpp | 102 +- .../lib/ExecutionEngine/Orc/CompileUtils.cpp | 4 +- .../llvm/lib/ExecutionEngine/Orc/Core.cpp | 685 +- .../lib/ExecutionEngine/Orc/DebugUtils.cpp | 281 + .../ExecutionEngine/Orc/ExecutionUtils.cpp | 95 +- .../ExecutionEngine/Orc/IndirectionUtils.cpp | 3 +- .../Orc/JITTargetMachineBuilder.cpp | 76 +- .../llvm/lib/ExecutionEngine/Orc/LLJIT.cpp | 1038 +- .../llvm/lib/ExecutionEngine/Orc/Layer.cpp | 95 +- .../lib/ExecutionEngine/Orc/LazyReexports.cpp | 110 +- .../lib/ExecutionEngine/Orc/MachOPlatform.cpp | 506 + .../llvm/lib/ExecutionEngine/Orc/Mangling.cpp | 160 + .../Orc/ObjectLinkingLayer.cpp | 229 +- .../lib/ExecutionEngine/Orc/OrcABISupport.cpp | 641 +- .../ExecutionEngine/Orc/OrcCBindingsStack.h | 4 +- .../ExecutionEngine/Orc/OrcMCJITReplacement.h | 9 +- .../ExecutionEngine/Orc/OrcV2CBindings.cpp | 254 + .../Orc/RTDyldObjectLinkingLayer.cpp | 104 +- .../ExecutionEngine/Orc/SpeculateAnalyses.cpp | 2 +- .../lib/ExecutionEngine/Orc/Speculation.cpp | 2 +- .../lib/ExecutionEngine/OrcError/OrcError.cpp | 4 + .../PerfJITEvents/PerfJITEventListener.cpp | 10 +- .../ExecutionEngine/RuntimeDyld/JITSymbol.cpp | 46 +- .../ExecutionEngine/RuntimeDyld/LLVMBuild.txt | 2 +- .../RuntimeDyld/RuntimeDyld.cpp | 95 +- .../RuntimeDyld/RuntimeDyldCOFF.cpp | 38 +- .../RuntimeDyld/RuntimeDyldCOFF.h | 17 +- .../RuntimeDyld/RuntimeDyldChecker.cpp | 21 +- .../RuntimeDyld/RuntimeDyldELF.cpp | 23 +- .../RuntimeDyld/RuntimeDyldELF.h | 5 +- .../RuntimeDyld/RuntimeDyldImpl.h | 53 +- .../Targets/RuntimeDyldCOFFAArch64.h | 31 +- .../RuntimeDyld/Targets/RuntimeDyldCOFFI386.h | 35 +- .../Targets/RuntimeDyldCOFFThumb.h | 47 +- .../Targets/RuntimeDyldCOFFX86_64.h | 31 +- gnu/llvm/llvm/lib/Extensions/LLVMBuild.txt | 2 +- gnu/llvm/llvm/lib/Frontend/CMakeLists.txt | 1 + .../llvm/lib/Frontend/OpenACC/CMakeLists.txt | 18 + .../llvm/lib/Frontend/OpenMP/CMakeLists.txt | 11 +- .../llvm/lib/Frontend/OpenMP/OMPContext.cpp | 527 + .../llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp | 842 +- gnu/llvm/llvm/lib/FuzzMutate/FuzzerCLI.cpp | 7 +- gnu/llvm/llvm/lib/FuzzMutate/Operations.cpp | 24 +- gnu/llvm/llvm/lib/IR/AbstractCallSite.cpp | 41 +- gnu/llvm/llvm/lib/IR/AsmWriter.cpp | 240 +- gnu/llvm/llvm/lib/IR/AttributeImpl.h | 108 +- gnu/llvm/llvm/lib/IR/Attributes.cpp | 425 +- gnu/llvm/llvm/lib/IR/AutoUpgrade.cpp | 419 +- gnu/llvm/llvm/lib/IR/BasicBlock.cpp | 136 +- gnu/llvm/llvm/lib/IR/CMakeLists.txt | 6 +- gnu/llvm/llvm/lib/IR/ConstantFold.cpp | 252 +- gnu/llvm/llvm/lib/IR/ConstantFold.h | 2 +- gnu/llvm/llvm/lib/IR/ConstantRange.cpp | 22 + gnu/llvm/llvm/lib/IR/Constants.cpp | 541 +- gnu/llvm/llvm/lib/IR/ConstantsContext.h | 164 +- gnu/llvm/llvm/lib/IR/Core.cpp | 56 +- gnu/llvm/llvm/lib/IR/DIBuilder.cpp | 74 +- gnu/llvm/llvm/lib/IR/DataLayout.cpp | 79 +- gnu/llvm/llvm/lib/IR/DebugInfo.cpp | 119 +- gnu/llvm/llvm/lib/IR/DebugInfoMetadata.cpp | 223 +- gnu/llvm/llvm/lib/IR/DebugLoc.cpp | 2 +- gnu/llvm/llvm/lib/IR/DiagnosticInfo.cpp | 40 +- gnu/llvm/llvm/lib/IR/Dominators.cpp | 39 +- gnu/llvm/llvm/lib/IR/FPEnv.cpp | 37 +- gnu/llvm/llvm/lib/IR/Function.cpp | 203 +- gnu/llvm/llvm/lib/IR/Globals.cpp | 34 +- gnu/llvm/llvm/lib/IR/IRBuilder.cpp | 610 +- gnu/llvm/llvm/lib/IR/InlineAsm.cpp | 10 +- gnu/llvm/llvm/lib/IR/Instruction.cpp | 39 +- gnu/llvm/llvm/lib/IR/Instructions.cpp | 611 +- gnu/llvm/llvm/lib/IR/IntrinsicInst.cpp | 239 +- gnu/llvm/llvm/lib/IR/LLVMContext.cpp | 45 +- gnu/llvm/llvm/lib/IR/LLVMContextImpl.cpp | 38 +- gnu/llvm/llvm/lib/IR/LLVMContextImpl.h | 145 +- gnu/llvm/llvm/lib/IR/LLVMRemarkStreamer.cpp | 174 + gnu/llvm/llvm/lib/IR/LegacyPassManager.cpp | 234 +- gnu/llvm/llvm/lib/IR/MDBuilder.cpp | 2 +- gnu/llvm/llvm/lib/IR/Mangler.cpp | 13 +- gnu/llvm/llvm/lib/IR/Metadata.cpp | 9 +- gnu/llvm/llvm/lib/IR/Module.cpp | 109 +- gnu/llvm/llvm/lib/IR/ModuleSummaryIndex.cpp | 65 +- gnu/llvm/llvm/lib/IR/Operator.cpp | 108 +- gnu/llvm/llvm/lib/IR/Pass.cpp | 3 - gnu/llvm/llvm/lib/IR/PassManager.cpp | 3 +- gnu/llvm/llvm/lib/IR/PassRegistry.cpp | 2 +- gnu/llvm/llvm/lib/IR/PassTimingInfo.cpp | 37 +- gnu/llvm/llvm/lib/IR/ProfileSummary.cpp | 140 +- gnu/llvm/llvm/lib/IR/SafepointIRVerifier.cpp | 5 +- gnu/llvm/llvm/lib/IR/Statepoint.cpp | 34 - .../llvm/lib/IR/SymbolTableListTraitsImpl.h | 15 +- gnu/llvm/llvm/lib/IR/Type.cpp | 176 +- gnu/llvm/llvm/lib/IR/Use.cpp | 77 +- gnu/llvm/llvm/lib/IR/User.cpp | 32 +- gnu/llvm/llvm/lib/IR/Value.cpp | 162 +- gnu/llvm/llvm/lib/IR/ValueSymbolTable.cpp | 13 +- gnu/llvm/llvm/lib/IR/Verifier.cpp | 646 +- gnu/llvm/llvm/lib/IRReader/IRReader.cpp | 19 +- gnu/llvm/llvm/lib/LTO/Caching.cpp | 2 +- gnu/llvm/llvm/lib/LTO/LLVMBuild.txt | 1 + gnu/llvm/llvm/lib/LTO/LTO.cpp | 157 +- gnu/llvm/llvm/lib/LTO/LTOBackend.cpp | 106 +- gnu/llvm/llvm/lib/LTO/LTOCodeGenerator.cpp | 20 +- gnu/llvm/llvm/lib/LTO/LTOModule.cpp | 14 +- .../llvm/lib/LTO/ThinLTOCodeGenerator.cpp | 63 +- gnu/llvm/llvm/lib/LTO/UpdateCompilerUsed.cpp | 1 + gnu/llvm/llvm/lib/LineEditor/LineEditor.cpp | 4 +- gnu/llvm/llvm/lib/Linker/IRMover.cpp | 16 +- gnu/llvm/llvm/lib/MC/CMakeLists.txt | 3 + gnu/llvm/llvm/lib/MC/ConstantPools.cpp | 10 +- gnu/llvm/llvm/lib/MC/ELFObjectWriter.cpp | 20 +- gnu/llvm/llvm/lib/MC/MCAsmInfo.cpp | 4 +- gnu/llvm/llvm/lib/MC/MCAsmInfoCOFF.cpp | 4 +- gnu/llvm/llvm/lib/MC/MCAsmInfoDarwin.cpp | 7 +- gnu/llvm/llvm/lib/MC/MCAsmInfoELF.cpp | 2 +- gnu/llvm/llvm/lib/MC/MCAsmInfoXCOFF.cpp | 28 +- gnu/llvm/llvm/lib/MC/MCAsmStreamer.cpp | 535 +- gnu/llvm/llvm/lib/MC/MCAssembler.cpp | 198 +- gnu/llvm/llvm/lib/MC/MCCodeView.cpp | 52 +- gnu/llvm/llvm/lib/MC/MCContext.cpp | 205 +- .../lib/MC/MCDisassembler/MCDisassembler.cpp | 60 +- gnu/llvm/llvm/lib/MC/MCDwarf.cpp | 706 +- gnu/llvm/llvm/lib/MC/MCELFStreamer.cpp | 80 +- gnu/llvm/llvm/lib/MC/MCExpr.cpp | 84 +- gnu/llvm/llvm/lib/MC/MCFragment.cpp | 29 +- gnu/llvm/llvm/lib/MC/MCInstPrinter.cpp | 26 +- gnu/llvm/llvm/lib/MC/MCInstrAnalysis.cpp | 13 +- gnu/llvm/llvm/lib/MC/MCInstrDesc.cpp | 11 - gnu/llvm/llvm/lib/MC/MCInstrInfo.cpp | 27 + gnu/llvm/llvm/lib/MC/MCMachOStreamer.cpp | 131 +- gnu/llvm/llvm/lib/MC/MCNullStreamer.cpp | 10 +- gnu/llvm/llvm/lib/MC/MCObjectFileInfo.cpp | 60 +- gnu/llvm/llvm/lib/MC/MCObjectStreamer.cpp | 228 +- gnu/llvm/llvm/lib/MC/MCParser/AsmLexer.cpp | 25 +- gnu/llvm/llvm/lib/MC/MCParser/AsmParser.cpp | 257 +- gnu/llvm/llvm/lib/MC/MCParser/CMakeLists.txt | 2 + .../llvm/lib/MC/MCParser/COFFAsmParser.cpp | 14 +- .../llvm/lib/MC/MCParser/COFFMasmParser.cpp | 386 + .../llvm/lib/MC/MCParser/DarwinAsmParser.cpp | 38 +- .../llvm/lib/MC/MCParser/ELFAsmParser.cpp | 111 +- gnu/llvm/llvm/lib/MC/MCParser/MCAsmParser.cpp | 5 + .../lib/MC/MCParser/MCAsmParserExtension.cpp | 43 + gnu/llvm/llvm/lib/MC/MCParser/MasmParser.cpp | 6873 ++++ .../llvm/lib/MC/MCParser/WasmAsmParser.cpp | 4 +- gnu/llvm/llvm/lib/MC/MCSection.cpp | 10 +- gnu/llvm/llvm/lib/MC/MCSectionCOFF.cpp | 12 +- gnu/llvm/llvm/lib/MC/MCSectionELF.cpp | 14 +- gnu/llvm/llvm/lib/MC/MCSectionMachO.cpp | 9 +- gnu/llvm/llvm/lib/MC/MCSectionWasm.cpp | 7 +- gnu/llvm/llvm/lib/MC/MCSectionXCOFF.cpp | 10 +- gnu/llvm/llvm/lib/MC/MCStreamer.cpp | 423 +- gnu/llvm/llvm/lib/MC/MCSubtargetInfo.cpp | 39 +- gnu/llvm/llvm/lib/MC/MCSymbolXCOFF.cpp | 39 + gnu/llvm/llvm/lib/MC/MCTargetOptions.cpp | 6 +- .../lib/MC/MCTargetOptionsCommandFlags.cpp | 114 + gnu/llvm/llvm/lib/MC/MCWasmStreamer.cpp | 44 +- gnu/llvm/llvm/lib/MC/MCWin64EH.cpp | 130 +- gnu/llvm/llvm/lib/MC/MCWinCOFFStreamer.cpp | 69 +- gnu/llvm/llvm/lib/MC/MCXCOFFStreamer.cpp | 62 +- gnu/llvm/llvm/lib/MC/MachObjectWriter.cpp | 6 +- gnu/llvm/llvm/lib/MC/SubtargetFeature.cpp | 4 +- gnu/llvm/llvm/lib/MC/WasmObjectWriter.cpp | 360 +- gnu/llvm/llvm/lib/MC/WinCOFFObjectWriter.cpp | 83 +- gnu/llvm/llvm/lib/MC/XCOFFObjectWriter.cpp | 281 +- gnu/llvm/llvm/lib/MCA/CodeEmitter.cpp | 2 +- .../llvm/lib/MCA/HardwareUnits/LSUnit.cpp | 86 +- gnu/llvm/llvm/lib/MCA/InstrBuilder.cpp | 25 +- gnu/llvm/llvm/lib/Object/Archive.cpp | 14 +- gnu/llvm/llvm/lib/Object/ArchiveWriter.cpp | 14 +- gnu/llvm/llvm/lib/Object/COFFImportFile.cpp | 2 +- .../llvm/lib/Object/COFFModuleDefinition.cpp | 8 +- gnu/llvm/llvm/lib/Object/COFFObjectFile.cpp | 573 +- gnu/llvm/llvm/lib/Object/ELF.cpp | 30 +- gnu/llvm/llvm/lib/Object/ELFObjectFile.cpp | 101 +- gnu/llvm/llvm/lib/Object/Error.cpp | 6 +- gnu/llvm/llvm/lib/Object/IRObjectFile.cpp | 3 +- gnu/llvm/llvm/lib/Object/IRSymtab.cpp | 8 +- gnu/llvm/llvm/lib/Object/MachOObjectFile.cpp | 41 +- .../llvm/lib/Object/ModuleSymbolTable.cpp | 8 +- gnu/llvm/llvm/lib/Object/ObjectFile.cpp | 30 +- gnu/llvm/llvm/lib/Object/RecordStreamer.cpp | 22 +- gnu/llvm/llvm/lib/Object/RecordStreamer.h | 15 +- .../llvm/lib/Object/RelocationResolver.cpp | 76 +- gnu/llvm/llvm/lib/Object/SymbolSize.cpp | 13 +- gnu/llvm/llvm/lib/Object/TapiFile.cpp | 22 +- gnu/llvm/llvm/lib/Object/TapiUniversal.cpp | 17 +- gnu/llvm/llvm/lib/Object/WasmObjectFile.cpp | 229 +- gnu/llvm/llvm/lib/Object/WindowsResource.cpp | 10 +- gnu/llvm/llvm/lib/Object/XCOFFObjectFile.cpp | 110 +- gnu/llvm/llvm/lib/ObjectYAML/COFFEmitter.cpp | 4 +- gnu/llvm/llvm/lib/ObjectYAML/DWARFEmitter.cpp | 274 +- gnu/llvm/llvm/lib/ObjectYAML/DWARFVisitor.cpp | 29 +- gnu/llvm/llvm/lib/ObjectYAML/DWARFVisitor.h | 3 +- gnu/llvm/llvm/lib/ObjectYAML/DWARFYAML.cpp | 110 +- gnu/llvm/llvm/lib/ObjectYAML/ELFEmitter.cpp | 1035 +- gnu/llvm/llvm/lib/ObjectYAML/ELFYAML.cpp | 157 +- gnu/llvm/llvm/lib/ObjectYAML/MachOEmitter.cpp | 159 +- gnu/llvm/llvm/lib/ObjectYAML/MachOYAML.cpp | 15 + gnu/llvm/llvm/lib/ObjectYAML/WasmEmitter.cpp | 39 +- gnu/llvm/llvm/lib/ObjectYAML/WasmYAML.cpp | 27 +- gnu/llvm/llvm/lib/ObjectYAML/yaml2obj.cpp | 4 +- gnu/llvm/llvm/lib/Option/Arg.cpp | 2 +- gnu/llvm/llvm/lib/Option/ArgList.cpp | 2 +- gnu/llvm/llvm/lib/Option/OptTable.cpp | 6 +- gnu/llvm/llvm/lib/Passes/CMakeLists.txt | 1 + gnu/llvm/llvm/lib/Passes/LLVMBuild.txt | 2 +- gnu/llvm/llvm/lib/Passes/PassBuilder.cpp | 639 +- gnu/llvm/llvm/lib/Passes/PassRegistry.def | 46 +- .../lib/Passes/StandardInstrumentations.cpp | 20 +- .../ProfileData/Coverage/CoverageMapping.cpp | 5 +- .../Coverage/CoverageMappingReader.cpp | 377 +- .../Coverage/CoverageMappingWriter.cpp | 34 +- gnu/llvm/llvm/lib/ProfileData/GCOV.cpp | 592 +- gnu/llvm/llvm/lib/ProfileData/InstrProf.cpp | 8 +- .../llvm/lib/ProfileData/InstrProfReader.cpp | 7 +- .../lib/ProfileData/ProfileSummaryBuilder.cpp | 13 + gnu/llvm/llvm/lib/ProfileData/SampleProf.cpp | 1 + .../llvm/lib/ProfileData/SampleProfReader.cpp | 117 +- .../llvm/lib/ProfileData/SampleProfWriter.cpp | 32 +- .../lib/Remarks/BitstreamRemarkParser.cpp | 2 +- gnu/llvm/llvm/lib/Remarks/CMakeLists.txt | 4 + gnu/llvm/llvm/lib/Remarks/Remark.cpp | 3 +- gnu/llvm/llvm/lib/Remarks/RemarkLinker.cpp | 2 +- gnu/llvm/llvm/lib/Remarks/RemarkStreamer.cpp | 72 + .../llvm/lib/Remarks/RemarkStringTable.cpp | 4 +- .../llvm/lib/Remarks/YAMLRemarkParser.cpp | 1 - gnu/llvm/llvm/lib/Remarks/YAMLRemarkParser.h | 2 +- .../llvm/lib/Support/AArch64TargetParser.cpp | 10 +- gnu/llvm/llvm/lib/Support/AMDGPUMetadata.cpp | 6 +- gnu/llvm/llvm/lib/Support/APFloat.cpp | 461 +- gnu/llvm/llvm/lib/Support/APInt.cpp | 25 +- gnu/llvm/llvm/lib/Support/APSInt.cpp | 9 +- .../llvm/lib/Support/ARMAttributeParser.cpp | 848 +- gnu/llvm/llvm/lib/Support/ARMBuildAttrs.cpp | 140 +- gnu/llvm/llvm/lib/Support/ARMTargetParser.cpp | 42 +- .../llvm/lib/Support/BranchProbability.cpp | 2 +- gnu/llvm/llvm/lib/Support/CMakeLists.txt | 12 +- gnu/llvm/llvm/lib/Support/COPYRIGHT.regex | 2 +- gnu/llvm/llvm/lib/Support/CachePruning.cpp | 2 +- gnu/llvm/llvm/lib/Support/CodeGenCoverage.cpp | 17 +- gnu/llvm/llvm/lib/Support/CommandLine.cpp | 170 +- gnu/llvm/llvm/lib/Support/Compression.cpp | 4 +- .../llvm/lib/Support/ConvertUTFWrapper.cpp | 2 +- gnu/llvm/llvm/lib/Support/DataExtractor.cpp | 164 +- gnu/llvm/llvm/lib/Support/Debug.cpp | 2 +- gnu/llvm/llvm/lib/Support/DebugCounter.cpp | 8 +- .../llvm/lib/Support/ELFAttributeParser.cpp | 233 + gnu/llvm/llvm/lib/Support/ELFAttributes.cpp | 34 + gnu/llvm/llvm/lib/Support/ErrorHandling.cpp | 2 +- gnu/llvm/llvm/lib/Support/ExtensibleRTTI.cpp | 13 + gnu/llvm/llvm/lib/Support/FileCheck.cpp | 928 +- gnu/llvm/llvm/lib/Support/FileCheckImpl.h | 349 +- gnu/llvm/llvm/lib/Support/FileCollector.cpp | 67 +- .../llvm/lib/Support/FileOutputBuffer.cpp | 6 +- gnu/llvm/llvm/lib/Support/FileUtilities.cpp | 10 +- gnu/llvm/llvm/lib/Support/FoldingSet.cpp | 51 +- gnu/llvm/llvm/lib/Support/FormatVariadic.cpp | 5 +- gnu/llvm/llvm/lib/Support/FormattedStream.cpp | 66 +- gnu/llvm/llvm/lib/Support/GraphWriter.cpp | 31 +- gnu/llvm/llvm/lib/Support/Host.cpp | 555 +- gnu/llvm/llvm/lib/Support/IntEqClasses.cpp | 1 + gnu/llvm/llvm/lib/Support/IntervalMap.cpp | 1 + .../Support/ItaniumManglingCanonicalizer.cpp | 11 +- gnu/llvm/llvm/lib/Support/KnownBits.cpp | 26 + gnu/llvm/llvm/lib/Support/LockFileManager.cpp | 80 +- gnu/llvm/llvm/lib/Support/MD5.cpp | 1 + gnu/llvm/llvm/lib/Support/MemAlloc.cpp | 34 + gnu/llvm/llvm/lib/Support/MemoryBuffer.cpp | 18 +- .../llvm/lib/Support/NativeFormatting.cpp | 5 +- .../lib/Support/OptimizedStructLayout.cpp | 449 + gnu/llvm/llvm/lib/Support/Parallel.cpp | 27 +- gnu/llvm/llvm/lib/Support/Path.cpp | 154 +- .../llvm/lib/Support/PrettyStackTrace.cpp | 15 + gnu/llvm/llvm/lib/Support/Process.cpp | 2 +- gnu/llvm/llvm/lib/Support/Program.cpp | 27 +- .../llvm/lib/Support/RISCVAttributeParser.cpp | 67 + gnu/llvm/llvm/lib/Support/RISCVAttributes.cpp | 25 + gnu/llvm/llvm/lib/Support/Regex.cpp | 8 +- gnu/llvm/llvm/lib/Support/SHA1.cpp | 11 +- gnu/llvm/llvm/lib/Support/Signals.cpp | 2 +- gnu/llvm/llvm/lib/Support/SmallVector.cpp | 47 +- gnu/llvm/llvm/lib/Support/SourceMgr.cpp | 254 +- gnu/llvm/llvm/lib/Support/SpecialCaseList.cpp | 6 +- gnu/llvm/llvm/lib/Support/Statistic.cpp | 2 +- gnu/llvm/llvm/lib/Support/StringExtras.cpp | 45 + gnu/llvm/llvm/lib/Support/StringMap.cpp | 52 +- gnu/llvm/llvm/lib/Support/StringRef.cpp | 16 +- gnu/llvm/llvm/lib/Support/SuffixTree.cpp | 210 + gnu/llvm/llvm/lib/Support/SystemUtils.cpp | 13 +- gnu/llvm/llvm/lib/Support/TarWriter.cpp | 15 +- gnu/llvm/llvm/lib/Support/TargetParser.cpp | 74 +- gnu/llvm/llvm/lib/Support/ThreadPool.cpp | 46 +- gnu/llvm/llvm/lib/Support/Threading.cpp | 67 +- gnu/llvm/llvm/lib/Support/TimeProfiler.cpp | 214 +- gnu/llvm/llvm/lib/Support/Timer.cpp | 3 +- gnu/llvm/llvm/lib/Support/ToolOutputFile.cpp | 28 +- gnu/llvm/llvm/lib/Support/TrigramIndex.cpp | 1 + gnu/llvm/llvm/lib/Support/Triple.cpp | 92 +- gnu/llvm/llvm/lib/Support/Unix/Host.inc | 2 +- gnu/llvm/llvm/lib/Support/Unix/Memory.inc | 1 + gnu/llvm/llvm/lib/Support/Unix/Path.inc | 111 +- gnu/llvm/llvm/lib/Support/Unix/Process.inc | 30 +- gnu/llvm/llvm/lib/Support/Unix/Program.inc | 87 +- gnu/llvm/llvm/lib/Support/Unix/Threading.inc | 35 + gnu/llvm/llvm/lib/Support/Unix/Unix.h | 4 - gnu/llvm/llvm/lib/Support/VersionTuple.cpp | 3 + .../llvm/lib/Support/VirtualFileSystem.cpp | 146 +- gnu/llvm/llvm/lib/Support/Windows/Path.inc | 136 +- gnu/llvm/llvm/lib/Support/Windows/Process.inc | 46 +- gnu/llvm/llvm/lib/Support/Windows/Program.inc | 30 +- gnu/llvm/llvm/lib/Support/Windows/Signals.inc | 18 +- .../llvm/lib/Support/Windows/Threading.inc | 174 + gnu/llvm/llvm/lib/Support/WithColor.cpp | 48 +- gnu/llvm/llvm/lib/Support/X86TargetParser.cpp | 614 + gnu/llvm/llvm/lib/Support/YAMLParser.cpp | 24 +- gnu/llvm/llvm/lib/Support/YAMLTraits.cpp | 8 +- gnu/llvm/llvm/lib/Support/Z3Solver.cpp | 40 +- gnu/llvm/llvm/lib/Support/raw_ostream.cpp | 192 +- gnu/llvm/llvm/lib/TableGen/Main.cpp | 2 +- gnu/llvm/llvm/lib/TableGen/Record.cpp | 32 +- gnu/llvm/llvm/lib/TableGen/SetTheory.cpp | 2 +- gnu/llvm/llvm/lib/TableGen/TGLexer.cpp | 1 + gnu/llvm/llvm/lib/TableGen/TGLexer.h | 4 +- gnu/llvm/llvm/lib/TableGen/TGParser.cpp | 294 +- gnu/llvm/llvm/lib/TableGen/TGParser.h | 12 +- .../llvm/lib/TableGen/TableGenBackend.cpp | 1 + gnu/llvm/llvm/lib/Target/AArch64/AArch64.h | 9 +- gnu/llvm/llvm/lib/Target/AArch64/AArch64.td | 148 +- .../lib/Target/AArch64/AArch64AsmPrinter.cpp | 189 +- .../AArch64/AArch64CallingConvention.cpp | 24 +- .../AArch64/AArch64CallingConvention.td | 145 +- .../AArch64CleanupLocalDynamicTLSPass.cpp | 4 + .../lib/Target/AArch64/AArch64CollectLOH.cpp | 21 +- .../llvm/lib/Target/AArch64/AArch64Combine.td | 68 +- .../AArch64/AArch64CompressJumpTables.cpp | 2 +- .../Target/AArch64/AArch64CondBrTuning.cpp | 16 +- .../AArch64/AArch64ConditionOptimizer.cpp | 37 +- .../AArch64/AArch64ConditionalCompares.cpp | 14 +- .../AArch64/AArch64ExpandPseudoInsts.cpp | 327 +- .../Target/AArch64/AArch64FalkorHWPFFix.cpp | 3 - .../lib/Target/AArch64/AArch64FastISel.cpp | 15 +- .../Target/AArch64/AArch64FrameLowering.cpp | 794 +- .../lib/Target/AArch64/AArch64FrameLowering.h | 51 +- .../Target/AArch64/AArch64ISelDAGToDAG.cpp | 752 +- .../Target/AArch64/AArch64ISelLowering.cpp | 2955 +- .../lib/Target/AArch64/AArch64ISelLowering.h | 232 +- .../lib/Target/AArch64/AArch64InstrFormats.td | 561 +- .../lib/Target/AArch64/AArch64InstrGISel.td | 124 + .../lib/Target/AArch64/AArch64InstrInfo.cpp | 589 +- .../lib/Target/AArch64/AArch64InstrInfo.h | 99 +- .../lib/Target/AArch64/AArch64InstrInfo.td | 615 +- .../AArch64/AArch64LoadStoreOptimizer.cpp | 104 +- .../AArch64/AArch64MachineFunctionInfo.cpp | 32 + .../AArch64/AArch64MachineFunctionInfo.h | 32 + .../Target/AArch64/AArch64PromoteConstant.cpp | 23 +- .../Target/AArch64/AArch64RegisterInfo.cpp | 191 +- .../lib/Target/AArch64/AArch64RegisterInfo.h | 22 +- .../lib/Target/AArch64/AArch64RegisterInfo.td | 37 +- .../Target/AArch64/AArch64SIMDInstrOpt.cpp | 5 +- .../Target/AArch64/AArch64SLSHardening.cpp | 443 + .../lib/Target/AArch64/AArch64SVEInstrInfo.td | 2162 +- .../lib/Target/AArch64/AArch64SchedA57.td | 2 +- .../lib/Target/AArch64/AArch64SchedCyclone.td | 2 +- .../Target/AArch64/AArch64SchedExynosM3.td | 2 +- .../Target/AArch64/AArch64SchedExynosM4.td | 2 +- .../Target/AArch64/AArch64SchedExynosM5.td | 2 +- .../AArch64/AArch64SchedFalkorDetails.td | 4 +- .../Target/AArch64/AArch64SchedKryoDetails.td | 4 +- .../AArch64/AArch64SchedThunderX2T99.td | 2 +- .../AArch64/AArch64SelectionDAGInfo.cpp | 29 +- .../Target/AArch64/AArch64SelectionDAGInfo.h | 3 +- .../lib/Target/AArch64/AArch64StackOffset.h | 13 + .../Target/AArch64/AArch64StackTagging.cpp | 49 +- .../AArch64/AArch64StorePairSuppress.cpp | 4 +- .../lib/Target/AArch64/AArch64Subtarget.cpp | 56 +- .../lib/Target/AArch64/AArch64Subtarget.h | 59 +- .../Target/AArch64/AArch64SystemOperands.td | 60 +- .../Target/AArch64/AArch64TargetMachine.cpp | 68 +- .../lib/Target/AArch64/AArch64TargetMachine.h | 8 + .../AArch64/AArch64TargetObjectFile.cpp | 5 +- .../Target/AArch64/AArch64TargetObjectFile.h | 5 + .../AArch64/AArch64TargetTransformInfo.cpp | 202 +- .../AArch64/AArch64TargetTransformInfo.h | 69 +- .../AArch64/AsmParser/AArch64AsmParser.cpp | 125 +- .../llvm/lib/Target/AArch64/CMakeLists.txt | 19 +- .../Disassembler/AArch64Disassembler.cpp | 36 + .../AArch64/GISel/AArch64CallLowering.cpp | 1054 + .../AArch64/GISel/AArch64CallLowering.h | 84 + .../GISel/AArch64InstructionSelector.cpp | 5672 +++ .../AArch64/GISel/AArch64LegalizerInfo.cpp | 817 + .../AArch64/GISel/AArch64LegalizerInfo.h | 51 + .../GISel/AArch64PostLegalizerCombiner.cpp | 507 + .../GISel/AArch64PreLegalizerCombiner.cpp | 203 + .../AArch64/GISel/AArch64RegisterBankInfo.cpp | 869 + .../AArch64/GISel/AArch64RegisterBankInfo.h | 145 + .../MCTargetDesc/AArch64AddressingModes.h | 7 +- .../MCTargetDesc/AArch64AsmBackend.cpp | 84 +- .../MCTargetDesc/AArch64ELFObjectWriter.cpp | 17 +- .../MCTargetDesc/AArch64ELFStreamer.cpp | 36 +- .../MCTargetDesc/AArch64InstPrinter.cpp | 52 +- .../AArch64/MCTargetDesc/AArch64InstPrinter.h | 21 +- .../AArch64/MCTargetDesc/AArch64MCAsmInfo.cpp | 4 +- .../MCTargetDesc/AArch64MCCodeEmitter.cpp | 31 +- .../MCTargetDesc/AArch64MCTargetDesc.cpp | 2 +- .../MCTargetDesc/AArch64MachObjectWriter.cpp | 4 +- .../MCTargetDesc/AArch64TargetStreamer.cpp | 2 +- .../MCTargetDesc/AArch64TargetStreamer.h | 4 + .../AArch64WinCOFFObjectWriter.cpp | 28 +- .../MCTargetDesc/AArch64WinCOFFStreamer.cpp | 16 +- .../Target/AArch64/MCTargetDesc/LLVMBuild.txt | 2 +- .../lib/Target/AArch64/SVEInstrFormats.td | 1926 +- .../lib/Target/AArch64/SVEIntrinsicOpts.cpp | 265 + .../Target/AArch64/Utils/AArch64BaseInfo.h | 1 + gnu/llvm/llvm/lib/Target/AMDGPU/AMDGPU.h | 32 +- gnu/llvm/llvm/lib/Target/AMDGPU/AMDGPU.td | 278 +- .../lib/Target/AMDGPU/AMDGPUAliasAnalysis.cpp | 10 +- .../lib/Target/AMDGPU/AMDGPUAliasAnalysis.h | 4 - .../Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp | 7 + .../AMDGPU/AMDGPUAnnotateKernelFeatures.cpp | 69 +- .../AMDGPU/AMDGPUAnnotateUniformValues.cpp | 28 +- .../Target/AMDGPU/AMDGPUArgumentUsageInfo.cpp | 119 +- .../Target/AMDGPU/AMDGPUArgumentUsageInfo.h | 35 +- .../lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp | 201 +- .../llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.h | 16 +- .../Target/AMDGPU/AMDGPUAtomicOptimizer.cpp | 7 +- .../lib/Target/AMDGPU/AMDGPUCallLowering.cpp | 253 +- .../lib/Target/AMDGPU/AMDGPUCallLowering.h | 10 +- .../lib/Target/AMDGPU/AMDGPUCallingConv.td | 26 +- .../Target/AMDGPU/AMDGPUCodeGenPrepare.cpp | 714 +- .../llvm/lib/Target/AMDGPU/AMDGPUCombine.td | 69 + .../Target/AMDGPU/AMDGPUExportClustering.cpp | 150 + .../Target/AMDGPU/AMDGPUExportClustering.h | 15 + .../llvm/lib/Target/AMDGPU/AMDGPUFeatures.td | 23 +- .../AMDGPU/AMDGPUFixFunctionBitcasts.cpp | 12 +- .../lib/Target/AMDGPU/AMDGPUFrameLowering.h | 2 +- .../llvm/lib/Target/AMDGPU/AMDGPUGISel.td | 114 +- .../AMDGPU/AMDGPUGenRegisterBankInfo.def | 80 +- .../Target/AMDGPU/AMDGPUGlobalISelUtils.cpp | 9 + .../lib/Target/AMDGPU/AMDGPUGlobalISelUtils.h | 33 + .../AMDGPU/AMDGPUHSAMetadataStreamer.cpp | 118 +- .../Target/AMDGPU/AMDGPUHSAMetadataStreamer.h | 15 +- .../lib/Target/AMDGPU/AMDGPUISelDAGToDAG.cpp | 583 +- .../lib/Target/AMDGPU/AMDGPUISelLowering.cpp | 493 +- .../lib/Target/AMDGPU/AMDGPUISelLowering.h | 33 +- .../llvm/lib/Target/AMDGPU/AMDGPUInline.cpp | 44 +- .../lib/Target/AMDGPU/AMDGPUInstrInfo.cpp | 1 - .../llvm/lib/Target/AMDGPU/AMDGPUInstrInfo.h | 3 + .../llvm/lib/Target/AMDGPU/AMDGPUInstrInfo.td | 90 +- .../AMDGPU/AMDGPUInstructionSelector.cpp | 2537 +- .../Target/AMDGPU/AMDGPUInstructionSelector.h | 122 +- .../lib/Target/AMDGPU/AMDGPUInstructions.td | 42 +- .../lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp | 2837 +- .../lib/Target/AMDGPU/AMDGPULegalizerInfo.h | 93 +- .../llvm/lib/Target/AMDGPU/AMDGPULibCalls.cpp | 56 +- .../llvm/lib/Target/AMDGPU/AMDGPULibFunc.cpp | 21 +- .../llvm/lib/Target/AMDGPU/AMDGPULibFunc.h | 5 +- .../Target/AMDGPU/AMDGPULowerIntrinsics.cpp | 12 +- .../AMDGPU/AMDGPULowerKernelArguments.cpp | 27 +- .../lib/Target/AMDGPU/AMDGPUMCInstLower.cpp | 8 +- .../Target/AMDGPU/AMDGPUMachineFunction.cpp | 18 +- .../lib/Target/AMDGPU/AMDGPUMachineFunction.h | 14 +- .../lib/Target/AMDGPU/AMDGPUMacroFusion.cpp | 1 + .../AMDGPUOpenCLEnqueuedBlockLowering.cpp | 1 + .../Target/AMDGPU/AMDGPUPerfHintAnalysis.cpp | 6 +- .../AMDGPU/AMDGPUPostLegalizerCombiner.cpp | 359 + .../AMDGPU/AMDGPUPreLegalizerCombiner.cpp | 153 + .../AMDGPU/AMDGPUPrintfRuntimeBinding.cpp | 25 +- .../lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp | 255 +- .../AMDGPU/AMDGPUPropagateAttributes.cpp | 137 +- .../Target/AMDGPU/AMDGPURegBankCombiner.cpp | 154 + .../Target/AMDGPU/AMDGPURegisterBankInfo.cpp | 2156 +- .../Target/AMDGPU/AMDGPURegisterBankInfo.h | 27 +- .../lib/Target/AMDGPU/AMDGPURegisterBanks.td | 6 +- .../AMDGPU/AMDGPURewriteOutArguments.cpp | 11 +- .../Target/AMDGPU/AMDGPUSearchableTables.td | 11 + .../lib/Target/AMDGPU/AMDGPUSubtarget.cpp | 181 +- .../llvm/lib/Target/AMDGPU/AMDGPUSubtarget.h | 172 +- .../lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | 115 +- .../lib/Target/AMDGPU/AMDGPUTargetMachine.h | 4 +- .../Target/AMDGPU/AMDGPUTargetObjectFile.h | 2 - .../AMDGPU/AMDGPUTargetTransformInfo.cpp | 507 +- .../Target/AMDGPU/AMDGPUTargetTransformInfo.h | 94 +- .../AMDGPU/AMDGPUUnifyDivergentExitNodes.cpp | 35 +- .../AMDGPU/AsmParser/AMDGPUAsmParser.cpp | 280 +- .../llvm/lib/Target/AMDGPU/BUFInstructions.td | 183 +- .../llvm/lib/Target/AMDGPU/CMakeLists.txt | 15 +- .../lib/Target/AMDGPU/CaymanInstructions.td | 5 +- .../llvm/lib/Target/AMDGPU/DSInstructions.td | 59 +- .../Disassembler/AMDGPUDisassembler.cpp | 46 +- .../Target/AMDGPU/EvergreenInstructions.td | 7 +- .../lib/Target/AMDGPU/FLATInstructions.td | 75 +- .../llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | 37 +- .../lib/Target/AMDGPU/GCNHazardRecognizer.cpp | 15 +- .../lib/Target/AMDGPU/GCNHazardRecognizer.h | 1 - .../Target/AMDGPU/GCNIterativeScheduler.cpp | 5 + .../lib/Target/AMDGPU/GCNIterativeScheduler.h | 8 + .../lib/Target/AMDGPU/GCNMinRegStrategy.cpp | 10 +- .../llvm/lib/Target/AMDGPU/GCNNSAReassign.cpp | 11 +- .../llvm/lib/Target/AMDGPU/GCNProcessors.td | 4 + .../lib/Target/AMDGPU/GCNRegBankReassign.cpp | 109 +- .../llvm/lib/Target/AMDGPU/GCNRegPressure.cpp | 27 +- .../llvm/lib/Target/AMDGPU/GCNRegPressure.h | 10 +- .../lib/Target/AMDGPU/GCNSchedStrategy.cpp | 123 +- .../llvm/lib/Target/AMDGPU/GCNSchedStrategy.h | 12 + .../AMDGPU/MCTargetDesc/AMDGPUAsmBackend.cpp | 12 +- .../MCTargetDesc/AMDGPUELFObjectWriter.cpp | 11 + .../AMDGPU/MCTargetDesc/AMDGPUInstPrinter.cpp | 73 +- .../AMDGPU/MCTargetDesc/AMDGPUInstPrinter.h | 13 +- .../AMDGPU/MCTargetDesc/AMDGPUMCAsmInfo.cpp | 3 + .../AMDGPU/MCTargetDesc/AMDGPUMCCodeEmitter.h | 6 + .../MCTargetDesc/AMDGPUMCTargetDesc.cpp | 8 +- .../AMDGPU/MCTargetDesc/AMDGPUMCTargetDesc.h | 4 + .../MCTargetDesc/AMDGPUTargetStreamer.cpp | 100 +- .../MCTargetDesc/AMDGPUTargetStreamer.h | 7 +- .../AMDGPU/MCTargetDesc/R600MCCodeEmitter.cpp | 2 +- .../AMDGPU/MCTargetDesc/SIMCCodeEmitter.cpp | 41 +- .../lib/Target/AMDGPU/MIMGInstructions.td | 239 +- .../llvm/lib/Target/AMDGPU/R600AsmPrinter.cpp | 14 +- .../llvm/lib/Target/AMDGPU/R600AsmPrinter.h | 2 +- .../AMDGPU/R600ControlFlowFinalizer.cpp | 7 +- .../Target/AMDGPU/R600ExpandSpecialInstrs.cpp | 8 +- .../lib/Target/AMDGPU/R600FrameLowering.cpp | 11 +- .../lib/Target/AMDGPU/R600FrameLowering.h | 4 +- .../lib/Target/AMDGPU/R600ISelLowering.cpp | 22 +- .../llvm/lib/Target/AMDGPU/R600InstrInfo.cpp | 8 +- .../lib/Target/AMDGPU/R600Instructions.td | 2 +- .../AMDGPU/R600OptimizeVectorRegisters.cpp | 32 +- .../lib/Target/AMDGPU/R600RegisterInfo.cpp | 22 +- .../llvm/lib/Target/AMDGPU/R600RegisterInfo.h | 11 +- .../lib/Target/AMDGPU/R600RegisterInfo.td | 6 +- .../llvm/lib/Target/AMDGPU/SIAddIMGInit.cpp | 8 +- .../Target/AMDGPU/SIAnnotateControlFlow.cpp | 2 +- gnu/llvm/llvm/lib/Target/AMDGPU/SIDefines.h | 26 +- .../lib/Target/AMDGPU/SIFixSGPRCopies.cpp | 33 +- .../lib/Target/AMDGPU/SIFixupVectorISel.cpp | 5 + .../llvm/lib/Target/AMDGPU/SIFoldOperands.cpp | 95 +- .../lib/Target/AMDGPU/SIFrameLowering.cpp | 997 +- .../llvm/lib/Target/AMDGPU/SIFrameLowering.h | 37 +- .../llvm/lib/Target/AMDGPU/SIISelLowering.cpp | 2276 +- .../llvm/lib/Target/AMDGPU/SIISelLowering.h | 63 +- .../lib/Target/AMDGPU/SIInsertHardClauses.cpp | 203 + .../llvm/lib/Target/AMDGPU/SIInsertSkips.cpp | 373 +- .../lib/Target/AMDGPU/SIInsertWaitcnts.cpp | 496 +- .../llvm/lib/Target/AMDGPU/SIInstrFormats.td | 5 +- .../llvm/lib/Target/AMDGPU/SIInstrInfo.cpp | 1090 +- gnu/llvm/llvm/lib/Target/AMDGPU/SIInstrInfo.h | 67 +- .../llvm/lib/Target/AMDGPU/SIInstrInfo.td | 98 +- .../llvm/lib/Target/AMDGPU/SIInstructions.td | 677 +- .../Target/AMDGPU/SILoadStoreOptimizer.cpp | 627 +- .../lib/Target/AMDGPU/SILowerControlFlow.cpp | 303 +- .../lib/Target/AMDGPU/SILowerI1Copies.cpp | 5 + .../lib/Target/AMDGPU/SILowerSGPRSpills.cpp | 60 +- .../Target/AMDGPU/SIMachineFunctionInfo.cpp | 190 +- .../lib/Target/AMDGPU/SIMachineFunctionInfo.h | 142 +- .../lib/Target/AMDGPU/SIMachineScheduler.cpp | 28 +- .../lib/Target/AMDGPU/SIMachineScheduler.h | 6 - .../lib/Target/AMDGPU/SIMemoryLegalizer.cpp | 28 + .../llvm/lib/Target/AMDGPU/SIModeRegister.cpp | 59 +- .../AMDGPU/SIOptimizeExecMaskingPreRA.cpp | 175 +- .../llvm/lib/Target/AMDGPU/SIPeepholeSDWA.cpp | 25 +- .../lib/Target/AMDGPU/SIPostRABundler.cpp | 139 + .../lib/Target/AMDGPU/SIPreEmitPeephole.cpp | 334 + .../llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp | 1387 +- .../llvm/lib/Target/AMDGPU/SIRegisterInfo.h | 165 +- .../llvm/lib/Target/AMDGPU/SIRegisterInfo.td | 453 +- .../AMDGPU/SIRemoveShortExecBranches.cpp | 160 + gnu/llvm/llvm/lib/Target/AMDGPU/SISchedule.td | 39 +- .../Target/AMDGPU/SIShrinkInstructions.cpp | 147 +- .../lib/Target/AMDGPU/SIWholeQuadMode.cpp | 59 +- .../llvm/lib/Target/AMDGPU/SMInstructions.td | 104 +- .../llvm/lib/Target/AMDGPU/SOPInstructions.td | 153 +- .../Target/AMDGPU/Utils/AMDGPUAsmUtils.cpp | 6 +- .../Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp | 215 +- .../lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.h | 156 +- .../Target/AMDGPU/Utils/AMDGPUPALMetadata.cpp | 114 +- .../Target/AMDGPU/Utils/AMDGPUPALMetadata.h | 6 +- .../lib/Target/AMDGPU/VOP1Instructions.td | 139 +- .../lib/Target/AMDGPU/VOP2Instructions.td | 76 +- .../lib/Target/AMDGPU/VOP3Instructions.td | 242 +- .../lib/Target/AMDGPU/VOP3PInstructions.td | 92 +- .../lib/Target/AMDGPU/VOPCInstructions.td | 10 +- .../llvm/lib/Target/AMDGPU/VOPInstructions.td | 43 +- .../llvm/lib/Target/ARC/ARCAsmPrinter.cpp | 12 +- .../llvm/lib/Target/ARC/ARCFrameLowering.cpp | 14 +- .../llvm/lib/Target/ARC/ARCFrameLowering.h | 4 +- .../llvm/lib/Target/ARC/ARCISelLowering.cpp | 14 +- .../llvm/lib/Target/ARC/ARCInstrFormats.td | 48 +- gnu/llvm/llvm/lib/Target/ARC/ARCInstrInfo.cpp | 16 +- gnu/llvm/llvm/lib/Target/ARC/ARCInstrInfo.h | 4 +- gnu/llvm/llvm/lib/Target/ARC/ARCInstrInfo.td | 30 +- .../lib/Target/ARC/ARCMachineFunctionInfo.h | 5 +- .../llvm/lib/Target/ARC/ARCRegisterInfo.cpp | 5 - .../llvm/lib/Target/ARC/ARCRegisterInfo.h | 2 - .../llvm/lib/Target/ARC/ARCRegisterInfo.td | 16 +- .../llvm/lib/Target/ARC/ARCTargetMachine.cpp | 2 +- .../Target/ARC/MCTargetDesc/ARCInstPrinter.h | 4 + .../ARC/MCTargetDesc/ARCMCTargetDesc.cpp | 2 +- gnu/llvm/llvm/lib/Target/ARM/ARM.h | 2 + gnu/llvm/llvm/lib/Target/ARM/ARM.td | 73 + .../llvm/lib/Target/ARM/ARMAsmPrinter.cpp | 267 +- gnu/llvm/llvm/lib/Target/ARM/ARMAsmPrinter.h | 26 +- .../llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp | 662 +- .../llvm/lib/Target/ARM/ARMBaseInstrInfo.h | 190 +- .../lib/Target/ARM/ARMBaseRegisterInfo.cpp | 95 +- .../llvm/lib/Target/ARM/ARMBaseRegisterInfo.h | 29 +- .../llvm/lib/Target/ARM/ARMBasicBlockInfo.cpp | 2 +- .../llvm/lib/Target/ARM/ARMBasicBlockInfo.h | 6 +- .../llvm/lib/Target/ARM/ARMCallLowering.cpp | 57 +- .../llvm/lib/Target/ARM/ARMCallingConv.cpp | 65 +- .../llvm/lib/Target/ARM/ARMCallingConv.td | 48 +- .../lib/Target/ARM/ARMConstantIslandPass.cpp | 72 +- .../lib/Target/ARM/ARMConstantPoolValue.cpp | 10 +- .../lib/Target/ARM/ARMConstantPoolValue.h | 14 +- .../lib/Target/ARM/ARMExpandPseudoInsts.cpp | 858 +- gnu/llvm/llvm/lib/Target/ARM/ARMFastISel.cpp | 94 +- .../llvm/lib/Target/ARM/ARMFrameLowering.cpp | 239 +- .../llvm/lib/Target/ARM/ARMFrameLowering.h | 41 +- .../llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp | 532 +- .../llvm/lib/Target/ARM/ARMISelLowering.cpp | 2359 +- .../llvm/lib/Target/ARM/ARMISelLowering.h | 87 +- gnu/llvm/llvm/lib/Target/ARM/ARMInstrCDE.td | 666 + .../llvm/lib/Target/ARM/ARMInstrFormats.td | 10 +- gnu/llvm/llvm/lib/Target/ARM/ARMInstrInfo.cpp | 2 +- gnu/llvm/llvm/lib/Target/ARM/ARMInstrInfo.td | 146 +- gnu/llvm/llvm/lib/Target/ARM/ARMInstrMVE.td | 2090 +- gnu/llvm/llvm/lib/Target/ARM/ARMInstrNEON.td | 486 +- gnu/llvm/llvm/lib/Target/ARM/ARMInstrThumb.td | 14 +- .../llvm/lib/Target/ARM/ARMInstrThumb2.td | 92 +- gnu/llvm/llvm/lib/Target/ARM/ARMInstrVFP.td | 266 +- .../lib/Target/ARM/ARMInstructionSelector.cpp | 32 +- .../llvm/lib/Target/ARM/ARMLegalizerInfo.cpp | 14 +- .../llvm/lib/Target/ARM/ARMLegalizerInfo.h | 4 +- .../lib/Target/ARM/ARMLoadStoreOptimizer.cpp | 311 +- .../lib/Target/ARM/ARMLowOverheadLoops.cpp | 1116 +- .../llvm/lib/Target/ARM/ARMMCInstLower.cpp | 8 +- .../lib/Target/ARM/ARMMachineFunctionInfo.cpp | 4 +- .../lib/Target/ARM/ARMMachineFunctionInfo.h | 18 +- .../llvm/lib/Target/ARM/ARMParallelDSP.cpp | 32 +- gnu/llvm/llvm/lib/Target/ARM/ARMPredicates.td | 130 +- .../lib/Target/ARM/ARMRegisterBankInfo.cpp | 60 +- .../llvm/lib/Target/ARM/ARMRegisterInfo.td | 24 +- .../llvm/lib/Target/ARM/ARMScheduleA57.td | 2 +- .../llvm/lib/Target/ARM/ARMScheduleSwift.td | 6 +- .../lib/Target/ARM/ARMSelectionDAGInfo.cpp | 24 +- .../llvm/lib/Target/ARM/ARMSelectionDAGInfo.h | 8 +- gnu/llvm/llvm/lib/Target/ARM/ARMSubtarget.cpp | 5 +- gnu/llvm/llvm/lib/Target/ARM/ARMSubtarget.h | 19 + .../llvm/lib/Target/ARM/ARMTargetMachine.cpp | 20 +- .../lib/Target/ARM/ARMTargetObjectFile.cpp | 2 +- .../lib/Target/ARM/ARMTargetTransformInfo.cpp | 532 +- .../lib/Target/ARM/ARMTargetTransformInfo.h | 67 +- .../lib/Target/ARM/AsmParser/ARMAsmParser.cpp | 442 +- gnu/llvm/llvm/lib/Target/ARM/CMakeLists.txt | 1 + .../ARM/Disassembler/ARMDisassembler.cpp | 59 +- .../Target/ARM/MCTargetDesc/ARMAsmBackend.cpp | 85 +- .../Target/ARM/MCTargetDesc/ARMAsmBackend.h | 4 +- .../ARM/MCTargetDesc/ARMAsmBackendDarwin.h | 12 +- .../lib/Target/ARM/MCTargetDesc/ARMBaseInfo.h | 14 +- .../ARM/MCTargetDesc/ARMELFObjectWriter.cpp | 50 +- .../ARM/MCTargetDesc/ARMELFStreamer.cpp | 147 +- .../ARM/MCTargetDesc/ARMInstPrinter.cpp | 13 +- .../Target/ARM/MCTargetDesc/ARMInstPrinter.h | 25 +- .../Target/ARM/MCTargetDesc/ARMMCAsmInfo.cpp | 5 - .../ARM/MCTargetDesc/ARMMCCodeEmitter.cpp | 8 - .../ARM/MCTargetDesc/ARMMCTargetDesc.cpp | 42 +- .../Target/ARM/MCTargetDesc/ARMMCTargetDesc.h | 3 + .../ARM/MCTargetDesc/ARMTargetStreamer.cpp | 4 +- .../ARM/MCTargetDesc/ARMUnwindOpAsm.cpp | 2 +- .../Target/ARM/MCTargetDesc/ARMUnwindOpAsm.h | 4 +- .../ARM/MCTargetDesc/ARMWinCOFFStreamer.cpp | 12 +- .../lib/Target/ARM/MCTargetDesc/LLVMBuild.txt | 2 +- .../Target/ARM/MVEGatherScatterLowering.cpp | 911 +- .../lib/Target/ARM/MVETailPredication.cpp | 592 +- .../llvm/lib/Target/ARM/MVEVPTBlockPass.cpp | 286 +- .../Target/ARM/MVEVPTOptimisationsPass.cpp | 464 + gnu/llvm/llvm/lib/Target/ARM/README-Thumb.txt | 2 +- .../lib/Target/ARM/Thumb1FrameLowering.cpp | 54 +- .../llvm/lib/Target/ARM/Thumb1FrameLowering.h | 11 +- .../llvm/lib/Target/ARM/Thumb1InstrInfo.cpp | 8 +- .../llvm/lib/Target/ARM/Thumb1InstrInfo.h | 4 +- .../llvm/lib/Target/ARM/Thumb2ITBlockPass.cpp | 6 +- .../llvm/lib/Target/ARM/Thumb2InstrInfo.cpp | 58 +- .../llvm/lib/Target/ARM/Thumb2InstrInfo.h | 19 +- .../lib/Target/ARM/Thumb2SizeReduction.cpp | 26 +- .../llvm/lib/Target/ARM/ThumbRegisterInfo.cpp | 31 +- .../llvm/lib/Target/ARM/ThumbRegisterInfo.h | 8 +- .../llvm/lib/Target/ARM/Utils/ARMBaseInfo.cpp | 31 + .../llvm/lib/Target/ARM/Utils/ARMBaseInfo.h | 66 +- .../llvm/lib/Target/AVR/AVRAsmPrinter.cpp | 4 +- .../llvm/lib/Target/AVR/AVRCallingConv.td | 18 +- gnu/llvm/llvm/lib/Target/AVR/AVRDevices.td | 18 +- .../lib/Target/AVR/AVRExpandPseudoInsts.cpp | 276 +- .../llvm/lib/Target/AVR/AVRFrameLowering.cpp | 119 +- .../llvm/lib/Target/AVR/AVRFrameLowering.h | 4 +- .../llvm/lib/Target/AVR/AVRISelDAGToDAG.cpp | 4 +- .../llvm/lib/Target/AVR/AVRISelLowering.cpp | 411 +- .../llvm/lib/Target/AVR/AVRISelLowering.h | 6 +- .../llvm/lib/Target/AVR/AVRInstrFormats.td | 20 +- gnu/llvm/llvm/lib/Target/AVR/AVRInstrInfo.cpp | 12 +- gnu/llvm/llvm/lib/Target/AVR/AVRInstrInfo.h | 4 +- gnu/llvm/llvm/lib/Target/AVR/AVRInstrInfo.td | 70 +- .../lib/Target/AVR/AVRMachineFunctionInfo.h | 20 +- .../llvm/lib/Target/AVR/AVRRegisterInfo.cpp | 27 +- .../llvm/lib/Target/AVR/AVRRegisterInfo.h | 6 +- .../llvm/lib/Target/AVR/AVRRegisterInfo.td | 27 + gnu/llvm/llvm/lib/Target/AVR/AVRSubtarget.cpp | 11 +- gnu/llvm/llvm/lib/Target/AVR/AVRSubtarget.h | 19 +- .../llvm/lib/Target/AVR/AVRTargetMachine.cpp | 2 +- .../lib/Target/AVR/AVRTargetObjectFile.cpp | 2 +- .../lib/Target/AVR/AsmParser/AVRAsmParser.cpp | 50 +- .../AVR/Disassembler/AVRDisassembler.cpp | 159 +- .../Target/AVR/MCTargetDesc/AVRAsmBackend.cpp | 96 +- .../Target/AVR/MCTargetDesc/AVRAsmBackend.h | 6 - .../Target/AVR/MCTargetDesc/AVRFixupKinds.h | 2 +- .../AVR/MCTargetDesc/AVRInstPrinter.cpp | 33 +- .../Target/AVR/MCTargetDesc/AVRInstPrinter.h | 11 +- .../Target/AVR/MCTargetDesc/AVRMCAsmInfo.cpp | 2 +- .../AVR/MCTargetDesc/AVRMCELFStreamer.cpp | 4 +- .../AVR/MCTargetDesc/AVRMCELFStreamer.h | 2 +- .../Target/AVR/MCTargetDesc/AVRMCTargetDesc.h | 3 - .../AVR/MCTargetDesc/AVRTargetStreamer.cpp | 4 +- .../lib/Target/BPF/AsmParser/BPFAsmParser.cpp | 16 +- gnu/llvm/llvm/lib/Target/BPF/BPF.h | 2 + .../Target/BPF/BPFAbstractMemberAccess.cpp | 63 +- .../llvm/lib/Target/BPF/BPFAsmPrinter.cpp | 4 +- gnu/llvm/llvm/lib/Target/BPF/BPFCORE.h | 18 +- .../llvm/lib/Target/BPF/BPFISelDAGToDAG.cpp | 4 +- .../llvm/lib/Target/BPF/BPFISelLowering.cpp | 40 + .../llvm/lib/Target/BPF/BPFISelLowering.h | 15 +- gnu/llvm/llvm/lib/Target/BPF/BPFInstrInfo.cpp | 4 +- gnu/llvm/llvm/lib/Target/BPF/BPFInstrInfo.h | 4 +- gnu/llvm/llvm/lib/Target/BPF/BPFInstrInfo.td | 5 +- gnu/llvm/llvm/lib/Target/BPF/BPFMCInstLower.h | 2 - .../llvm/lib/Target/BPF/BPFMIPeephole.cpp | 69 +- .../lib/Target/BPF/BPFMISimplifyPatchable.cpp | 87 +- .../llvm/lib/Target/BPF/BPFPreserveDIType.cpp | 131 + .../lib/Target/BPF/BPFSelectionDAGInfo.cpp | 6 +- .../llvm/lib/Target/BPF/BPFSelectionDAGInfo.h | 4 +- .../llvm/lib/Target/BPF/BPFTargetMachine.cpp | 8 +- gnu/llvm/llvm/lib/Target/BPF/BTFDebug.cpp | 250 +- gnu/llvm/llvm/lib/Target/BPF/BTFDebug.h | 68 +- gnu/llvm/llvm/lib/Target/BPF/CMakeLists.txt | 1 + .../BPF/Disassembler/BPFDisassembler.cpp | 3 + .../Target/BPF/MCTargetDesc/BPFAsmBackend.cpp | 3 - .../Target/BPF/MCTargetDesc/BPFMCAsmInfo.h | 3 +- .../Target/BPF/MCTargetDesc/BPFMCTargetDesc.h | 4 - .../Hexagon/AsmParser/HexagonAsmParser.cpp | 148 +- .../llvm/lib/Target/Hexagon/BitTracker.cpp | 3 + .../Disassembler/HexagonDisassembler.cpp | 29 +- gnu/llvm/llvm/lib/Target/Hexagon/Hexagon.td | 99 +- .../llvm/lib/Target/Hexagon/HexagonArch.h | 37 + .../lib/Target/Hexagon/HexagonAsmPrinter.cpp | 20 +- .../lib/Target/Hexagon/HexagonAsmPrinter.h | 2 +- .../lib/Target/Hexagon/HexagonBitSimplify.cpp | 12 +- .../lib/Target/Hexagon/HexagonBitTracker.cpp | 2 +- .../Hexagon/HexagonBranchRelaxation.cpp | 2 +- .../lib/Target/Hexagon/HexagonCallingConv.td | 32 +- .../lib/Target/Hexagon/HexagonCommonGEP.cpp | 15 +- .../Target/Hexagon/HexagonConstExtenders.cpp | 38 +- .../Hexagon/HexagonConstPropagation.cpp | 17 +- .../Target/Hexagon/HexagonCopyToCombine.cpp | 14 +- .../llvm/lib/Target/Hexagon/HexagonDepArch.h | 39 +- .../llvm/lib/Target/Hexagon/HexagonDepArch.td | 26 +- .../lib/Target/Hexagon/HexagonDepDecoders.inc | 40 +- .../lib/Target/Hexagon/HexagonDepIICHVX.td | 493 +- .../lib/Target/Hexagon/HexagonDepIICScalar.td | 8257 ++-- .../lib/Target/Hexagon/HexagonDepITypes.h | 87 +- .../lib/Target/Hexagon/HexagonDepITypes.td | 87 +- .../Target/Hexagon/HexagonDepInstrFormats.td | 6145 +-- .../lib/Target/Hexagon/HexagonDepInstrInfo.td | 6032 +-- .../Target/Hexagon/HexagonDepMapAsm2Intrin.td | 6124 +-- .../lib/Target/Hexagon/HexagonDepMappings.td | 11 +- .../llvm/lib/Target/Hexagon/HexagonDepMask.h | 2821 ++ .../lib/Target/Hexagon/HexagonDepOperands.td | 182 +- .../Target/Hexagon/HexagonDepTimingClasses.h | 200 +- .../lib/Target/Hexagon/HexagonEarlyIfConv.cpp | 6 +- .../Target/Hexagon/HexagonFixupHwLoops.cpp | 4 +- .../Target/Hexagon/HexagonFrameLowering.cpp | 275 +- .../lib/Target/Hexagon/HexagonFrameLowering.h | 19 +- .../lib/Target/Hexagon/HexagonGenExtract.cpp | 5 +- .../Target/Hexagon/HexagonHardwareLoops.cpp | 12 +- .../lib/Target/Hexagon/HexagonIICScalar.td | 2 +- .../Target/Hexagon/HexagonISelDAGToDAG.cpp | 81 +- .../lib/Target/Hexagon/HexagonISelDAGToDAG.h | 8 +- .../Target/Hexagon/HexagonISelDAGToDAGHVX.cpp | 26 +- .../Target/Hexagon/HexagonISelLowering.cpp | 330 +- .../lib/Target/Hexagon/HexagonISelLowering.h | 37 +- .../Target/Hexagon/HexagonISelLoweringHVX.cpp | 224 +- .../lib/Target/Hexagon/HexagonInstrFormats.td | 103 +- .../Target/Hexagon/HexagonInstrFormatsV65.td | 4 +- .../lib/Target/Hexagon/HexagonInstrInfo.cpp | 260 +- .../lib/Target/Hexagon/HexagonInstrInfo.h | 43 +- .../lib/Target/Hexagon/HexagonIntrinsics.td | 76 +- .../Target/Hexagon/HexagonIntrinsicsV60.td | 64 +- .../Hexagon/HexagonLoopIdiomRecognition.cpp | 2 +- .../lib/Target/Hexagon/HexagonMCInstLower.cpp | 2 +- .../Hexagon/HexagonMachineFunctionInfo.h | 12 + .../Target/Hexagon/HexagonNewValueJump.cpp | 2 +- .../lib/Target/Hexagon/HexagonOptAddrMode.cpp | 11 +- .../lib/Target/Hexagon/HexagonPatterns.td | 70 +- .../lib/Target/Hexagon/HexagonPeephole.cpp | 2 +- .../llvm/lib/Target/Hexagon/HexagonPseudo.td | 18 +- .../Target/Hexagon/HexagonRegisterInfo.cpp | 9 +- .../lib/Target/Hexagon/HexagonRegisterInfo.h | 4 - .../lib/Target/Hexagon/HexagonRegisterInfo.td | 82 +- .../lib/Target/Hexagon/HexagonSchedule.td | 26 +- .../lib/Target/Hexagon/HexagonScheduleV67.td | 39 + .../lib/Target/Hexagon/HexagonScheduleV67T.td | 61 + .../Hexagon/HexagonSelectionDAGInfo.cpp | 4 +- .../Target/Hexagon/HexagonSelectionDAGInfo.h | 4 +- .../lib/Target/Hexagon/HexagonSplitDouble.cpp | 9 +- .../Target/Hexagon/HexagonStoreWidening.cpp | 7 +- .../lib/Target/Hexagon/HexagonSubtarget.cpp | 51 +- .../lib/Target/Hexagon/HexagonSubtarget.h | 55 +- .../Target/Hexagon/HexagonTargetMachine.cpp | 8 + .../Hexagon/HexagonTargetObjectFile.cpp | 6 +- .../Target/Hexagon/HexagonTargetObjectFile.h | 1 + .../Target/Hexagon/HexagonTargetStreamer.h | 6 +- .../Hexagon/HexagonTargetTransformInfo.cpp | 117 +- .../Hexagon/HexagonTargetTransformInfo.h | 52 +- .../lib/Target/Hexagon/HexagonVExtract.cpp | 18 +- .../Target/Hexagon/HexagonVLIWPacketizer.cpp | 74 +- .../Target/Hexagon/HexagonVLIWPacketizer.h | 8 + .../lib/Target/Hexagon/HexagonVectorPrint.cpp | 7 +- .../MCTargetDesc/HexagonAsmBackend.cpp | 23 +- .../Hexagon/MCTargetDesc/HexagonBaseInfo.h | 8 +- .../MCTargetDesc/HexagonELFObjectWriter.cpp | 2 +- .../Hexagon/MCTargetDesc/HexagonMCAsmInfo.cpp | 1 + .../Hexagon/MCTargetDesc/HexagonMCChecker.cpp | 31 +- .../Hexagon/MCTargetDesc/HexagonMCChecker.h | 5 + .../MCTargetDesc/HexagonMCCodeEmitter.cpp | 24 +- .../MCTargetDesc/HexagonMCDuplexInfo.cpp | 6 +- .../MCTargetDesc/HexagonMCELFStreamer.cpp | 10 +- .../MCTargetDesc/HexagonMCELFStreamer.h | 2 +- .../Hexagon/MCTargetDesc/HexagonMCExpr.h | 1 - .../MCTargetDesc/HexagonMCInstrInfo.cpp | 167 +- .../Hexagon/MCTargetDesc/HexagonMCInstrInfo.h | 43 +- .../MCTargetDesc/HexagonMCTargetDesc.cpp | 165 +- .../MCTargetDesc/HexagonMCTargetDesc.h | 10 +- .../Hexagon/MCTargetDesc/HexagonShuffler.cpp | 730 +- .../Hexagon/MCTargetDesc/HexagonShuffler.h | 83 +- gnu/llvm/llvm/lib/Target/LLVMBuild.txt | 8 +- .../Target/Lanai/AsmParser/LanaiAsmParser.cpp | 36 +- gnu/llvm/llvm/lib/Target/Lanai/Lanai.h | 3 - .../llvm/lib/Target/Lanai/LanaiAsmPrinter.cpp | 16 +- .../lib/Target/Lanai/LanaiFrameLowering.cpp | 4 +- .../lib/Target/Lanai/LanaiISelLowering.cpp | 14 +- .../llvm/lib/Target/Lanai/LanaiInstrInfo.cpp | 32 +- .../llvm/lib/Target/Lanai/LanaiInstrInfo.h | 21 +- .../llvm/lib/Target/Lanai/LanaiMCInstLower.h | 2 - .../Target/Lanai/LanaiMachineFunctionInfo.cpp | 9 - .../Target/Lanai/LanaiMachineFunctionInfo.h | 14 +- .../lib/Target/Lanai/LanaiRegisterInfo.cpp | 5 - .../llvm/lib/Target/Lanai/LanaiRegisterInfo.h | 2 - .../Target/Lanai/LanaiSelectionDAGInfo.cpp | 2 +- .../lib/Target/Lanai/LanaiSelectionDAGInfo.h | 4 +- .../llvm/lib/Target/Lanai/LanaiSubtarget.cpp | 2 +- .../lib/Target/Lanai/LanaiTargetMachine.h | 1 - .../Target/Lanai/LanaiTargetObjectFile.cpp | 11 +- .../lib/Target/Lanai/LanaiTargetObjectFile.h | 3 +- .../Target/Lanai/LanaiTargetTransformInfo.h | 18 +- .../Lanai/MCTargetDesc/LanaiAsmBackend.cpp | 4 - .../Lanai/MCTargetDesc/LanaiInstPrinter.cpp | 2 +- .../Lanai/MCTargetDesc/LanaiInstPrinter.h | 7 +- .../Lanai/MCTargetDesc/LanaiMCAsmInfo.cpp | 3 - .../Lanai/MCTargetDesc/LanaiMCTargetDesc.cpp | 2 +- .../Lanai/MCTargetDesc/LanaiMCTargetDesc.h | 5 - .../MSP430/AsmParser/MSP430AsmParser.cpp | 51 +- .../Disassembler/MSP430Disassembler.cpp | 4 +- .../MSP430/MCTargetDesc/MSP430AsmBackend.cpp | 3 - .../MSP430/MCTargetDesc/MSP430ELFStreamer.cpp | 24 +- .../MSP430/MCTargetDesc/MSP430InstPrinter.cpp | 2 +- .../MSP430/MCTargetDesc/MSP430InstPrinter.h | 7 +- .../MSP430/MCTargetDesc/MSP430MCAsmInfo.cpp | 3 +- gnu/llvm/llvm/lib/Target/MSP430/MSP430.h | 1 - .../lib/Target/MSP430/MSP430AsmPrinter.cpp | 8 +- .../lib/Target/MSP430/MSP430FrameLowering.cpp | 30 +- .../lib/Target/MSP430/MSP430FrameLowering.h | 11 +- .../lib/Target/MSP430/MSP430ISelDAGToDAG.cpp | 12 +- .../lib/Target/MSP430/MSP430ISelLowering.cpp | 16 +- .../lib/Target/MSP430/MSP430ISelLowering.h | 4 + .../lib/Target/MSP430/MSP430InstrInfo.cpp | 20 +- .../llvm/lib/Target/MSP430/MSP430InstrInfo.h | 5 +- .../lib/Target/MSP430/MSP430MCInstLower.h | 1 - .../Target/MSP430/MSP430MachineFunctionInfo.h | 6 +- .../lib/Target/MSP430/MSP430RegisterInfo.cpp | 12 +- .../lib/Target/MSP430/MSP430RegisterInfo.td | 10 +- .../lib/Target/MSP430/MSP430Subtarget.cpp | 2 +- .../lib/Target/MSP430/MSP430TargetMachine.cpp | 2 +- gnu/llvm/llvm/lib/Target/Mips/CMakeLists.txt | 1 - .../Mips/MCTargetDesc/MipsABIFlagsSection.cpp | 22 +- .../Target/Mips/MCTargetDesc/MipsABIInfo.h | 1 - .../Target/Mips/MCTargetDesc/MipsAsmBackend.h | 13 - .../Mips/MCTargetDesc/MipsELFObjectWriter.cpp | 61 +- .../Mips/MCTargetDesc/MipsELFStreamer.cpp | 28 +- .../Mips/MCTargetDesc/MipsELFStreamer.h | 14 +- .../Mips/MCTargetDesc/MipsInstPrinter.cpp | 2 +- .../Mips/MCTargetDesc/MipsInstPrinter.h | 11 +- .../Mips/MCTargetDesc/MipsMCAsmInfo.cpp | 1 - .../Mips/MCTargetDesc/MipsMCCodeEmitter.cpp | 25 +- .../Mips/MCTargetDesc/MipsMCCodeEmitter.h | 2 +- .../Mips/MCTargetDesc/MipsMCTargetDesc.h | 2 - .../Mips/MCTargetDesc/MipsNaClELFStreamer.cpp | 28 +- .../Mips/MCTargetDesc/MipsOptionRecord.cpp | 34 +- .../Mips/MCTargetDesc/MipsTargetStreamer.cpp | 72 +- .../lib/Target/Mips/MicroMipsInstrFormats.td | 2 +- .../lib/Target/Mips/MicroMipsInstrInfo.td | 2 +- .../Target/Mips/MicroMipsSizeReduction.cpp | 12 +- gnu/llvm/llvm/lib/Target/Mips/Mips.td | 35 +- .../lib/Target/Mips/Mips16FrameLowering.cpp | 19 +- .../lib/Target/Mips/Mips16FrameLowering.h | 11 +- .../llvm/lib/Target/Mips/Mips16HardFloat.cpp | 10 +- .../lib/Target/Mips/Mips16ISelDAGToDAG.cpp | 2 +- .../lib/Target/Mips/Mips16ISelLowering.cpp | 2 +- .../llvm/lib/Target/Mips/Mips16InstrInfo.cpp | 6 +- .../llvm/lib/Target/Mips/Mips16InstrInfo.h | 4 +- .../llvm/lib/Target/Mips/Mips16InstrInfo.td | 2 +- .../lib/Target/Mips/Mips16RegisterInfo.cpp | 12 +- .../llvm/lib/Target/Mips/Mips16RegisterInfo.h | 9 +- .../llvm/lib/Target/Mips/Mips64InstrInfo.td | 14 + .../llvm/lib/Target/Mips/MipsAsmPrinter.cpp | 153 +- .../llvm/lib/Target/Mips/MipsAsmPrinter.h | 20 +- .../lib/Target/Mips/MipsBranchExpansion.cpp | 21 +- gnu/llvm/llvm/lib/Target/Mips/MipsCCState.cpp | 6 +- .../llvm/lib/Target/Mips/MipsCallLowering.cpp | 114 +- .../Target/Mips/MipsConstantIslandPass.cpp | 17 +- .../lib/Target/Mips/MipsDSPInstrFormats.td | 6 +- .../lib/Target/Mips/MipsDelaySlotFiller.cpp | 2 +- .../llvm/lib/Target/Mips/MipsFastISel.cpp | 12 +- .../lib/Target/Mips/MipsFrameLowering.cpp | 9 - .../llvm/lib/Target/Mips/MipsFrameLowering.h | 8 +- .../llvm/lib/Target/Mips/MipsISelDAGToDAG.cpp | 4 +- .../llvm/lib/Target/Mips/MipsISelLowering.cpp | 370 +- .../llvm/lib/Target/Mips/MipsISelLowering.h | 17 +- gnu/llvm/llvm/lib/Target/Mips/MipsInstrFPU.td | 34 +- .../llvm/lib/Target/Mips/MipsInstrFormats.td | 47 - .../llvm/lib/Target/Mips/MipsInstrInfo.cpp | 58 +- gnu/llvm/llvm/lib/Target/Mips/MipsInstrInfo.h | 18 +- .../llvm/lib/Target/Mips/MipsInstrInfo.td | 170 +- .../Target/Mips/MipsInstructionSelector.cpp | 125 +- .../lib/Target/Mips/MipsLegalizerInfo.cpp | 221 +- .../llvm/lib/Target/Mips/MipsLegalizerInfo.h | 8 +- .../llvm/lib/Target/Mips/MipsMSAInstrInfo.td | 20 + .../lib/Target/Mips/MipsMachineFunction.cpp | 36 +- .../lib/Target/Mips/MipsMachineFunction.h | 26 +- .../lib/Target/Mips/MipsOptimizePICCall.cpp | 3 +- .../Target/Mips/MipsPreLegalizerCombiner.cpp | 15 +- .../lib/Target/Mips/MipsRegisterBankInfo.cpp | 142 +- .../lib/Target/Mips/MipsRegisterBankInfo.h | 60 +- .../llvm/lib/Target/Mips/MipsRegisterInfo.cpp | 7 +- .../llvm/lib/Target/Mips/MipsRegisterInfo.h | 2 - .../llvm/lib/Target/Mips/MipsRegisterInfo.td | 16 +- .../lib/Target/Mips/MipsSEFrameLowering.cpp | 34 +- .../lib/Target/Mips/MipsSEFrameLowering.h | 4 +- .../lib/Target/Mips/MipsSEISelDAGToDAG.cpp | 79 +- .../lib/Target/Mips/MipsSEISelLowering.cpp | 5 +- .../llvm/lib/Target/Mips/MipsSEInstrInfo.cpp | 18 +- .../llvm/lib/Target/Mips/MipsSEInstrInfo.h | 6 +- .../llvm/lib/Target/Mips/MipsSERegisterInfo.h | 1 - gnu/llvm/llvm/lib/Target/Mips/MipsSchedule.td | 2 + .../lib/Target/Mips/MipsScheduleGeneric.td | 8 +- .../llvm/lib/Target/Mips/MipsScheduleP5600.td | 5 +- .../llvm/lib/Target/Mips/MipsSubtarget.cpp | 2 +- gnu/llvm/llvm/lib/Target/Mips/MipsSubtarget.h | 4 + .../lib/Target/Mips/MipsTargetObjectFile.cpp | 6 +- .../lib/Target/Mips/MipsTargetObjectFile.h | 2 +- .../llvm/lib/Target/Mips/MipsTargetStreamer.h | 9 +- .../NVPTX/MCTargetDesc/NVPTXMCAsmInfo.cpp | 2 + .../NVPTX/MCTargetDesc/NVPTXMCAsmInfo.h | 1 - .../NVPTX/MCTargetDesc/NVPTXMCTargetDesc.h | 5 - .../MCTargetDesc/NVPTXTargetStreamer.cpp | 6 +- gnu/llvm/llvm/lib/Target/NVPTX/NVPTX.h | 1 - gnu/llvm/llvm/lib/Target/NVPTX/NVPTX.td | 7 + .../llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp | 96 +- .../llvm/lib/Target/NVPTX/NVPTXAsmPrinter.h | 13 +- .../lib/Target/NVPTX/NVPTXFrameLowering.cpp | 7 +- .../lib/Target/NVPTX/NVPTXFrameLowering.h | 5 +- .../lib/Target/NVPTX/NVPTXGenericToNVVM.cpp | 2 +- .../lib/Target/NVPTX/NVPTXISelLowering.cpp | 164 +- .../llvm/lib/Target/NVPTX/NVPTXISelLowering.h | 7 +- .../llvm/lib/Target/NVPTX/NVPTXInstrInfo.cpp | 2 +- .../lib/Target/NVPTX/NVPTXLowerAggrCopies.cpp | 4 +- .../llvm/lib/Target/NVPTX/NVPTXLowerArgs.cpp | 6 +- .../Target/NVPTX/NVPTXPrologEpilogPass.cpp | 35 +- .../Target/NVPTX/NVPTXReplaceImageHandles.cpp | 2 +- .../llvm/lib/Target/NVPTX/NVPTXSubtarget.cpp | 10 +- .../lib/Target/NVPTX/NVPTXTargetMachine.cpp | 9 +- .../lib/Target/NVPTX/NVPTXTargetObjectFile.h | 2 +- .../Target/NVPTX/NVPTXTargetTransformInfo.cpp | 14 +- .../Target/NVPTX/NVPTXTargetTransformInfo.h | 11 +- .../llvm/lib/Target/NVPTX/NVPTXUtilities.cpp | 6 +- .../Target/PowerPC/AsmParser/PPCAsmParser.cpp | 83 +- .../PowerPC/Disassembler/PPCDisassembler.cpp | 76 +- .../PowerPC/MCTargetDesc/CMakeLists.txt | 2 +- .../Target/PowerPC/MCTargetDesc/LLVMBuild.txt | 2 +- .../PowerPC/MCTargetDesc/PPCAsmBackend.cpp | 79 +- .../MCTargetDesc/PPCELFObjectWriter.cpp | 23 +- .../PowerPC/MCTargetDesc/PPCELFStreamer.cpp | 112 + .../PowerPC/MCTargetDesc/PPCELFStreamer.h | 54 + .../PowerPC/MCTargetDesc/PPCFixupKinds.h | 7 + .../PowerPC/MCTargetDesc/PPCInstPrinter.cpp | 75 +- .../PowerPC/MCTargetDesc/PPCInstPrinter.h | 13 +- .../PowerPC/MCTargetDesc/PPCMCAsmInfo.cpp | 11 +- .../PowerPC/MCTargetDesc/PPCMCAsmInfo.h | 2 +- .../PowerPC/MCTargetDesc/PPCMCCodeEmitter.cpp | 124 +- .../PowerPC/MCTargetDesc/PPCMCCodeEmitter.h | 14 +- .../Target/PowerPC/MCTargetDesc/PPCMCExpr.cpp | 63 +- .../Target/PowerPC/MCTargetDesc/PPCMCExpr.h | 26 +- .../PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp | 84 +- .../PowerPC/MCTargetDesc/PPCMCTargetDesc.h | 3 - .../MCTargetDesc/PPCXCOFFObjectWriter.cpp | 49 +- gnu/llvm/llvm/lib/Target/PowerPC/PPC.h | 37 +- gnu/llvm/llvm/lib/Target/PowerPC/PPC.td | 95 +- .../lib/Target/PowerPC/PPCBoolRetToInt.cpp | 17 +- .../Target/PowerPC/PPCBranchCoalescing.cpp | 5 + .../lib/Target/PowerPC/PPCBranchSelector.cpp | 35 +- .../llvm/lib/Target/PowerPC/PPCCTRLoops.cpp | 2 +- .../llvm/lib/Target/PowerPC/PPCCallingConv.td | 44 +- .../lib/Target/PowerPC/PPCEarlyReturn.cpp | 6 +- .../llvm/lib/Target/PowerPC/PPCExpandISEL.cpp | 57 +- .../llvm/lib/Target/PowerPC/PPCFastISel.cpp | 91 +- .../lib/Target/PowerPC/PPCISelDAGToDAG.cpp | 510 +- .../llvm/lib/Target/PowerPC/PPCISelLowering.h | 179 +- .../llvm/lib/Target/PowerPC/PPCInstr64Bit.td | 137 +- .../lib/Target/PowerPC/PPCInstrAltivec.td | 55 +- .../lib/Target/PowerPC/PPCInstrFormats.td | 6 +- .../llvm/lib/Target/PowerPC/PPCInstrHTM.td | 7 +- .../llvm/lib/Target/PowerPC/PPCInstrInfo.cpp | 1443 +- .../llvm/lib/Target/PowerPC/PPCInstrInfo.h | 205 +- .../llvm/lib/Target/PowerPC/PPCInstrPrefix.td | 1035 + .../llvm/lib/Target/PowerPC/PPCInstrQPX.td | 31 +- .../llvm/lib/Target/PowerPC/PPCInstrSPE.td | 16 +- .../llvm/lib/Target/PowerPC/PPCInstrVSX.td | 6401 +-- .../Target/PowerPC/PPCLoopInstrFormPrep.cpp | 12 +- .../Target/PowerPC/PPCLowerMASSVEntries.cpp | 34 +- .../lib/Target/PowerPC/PPCMCInstLower.cpp | 78 +- .../llvm/lib/Target/PowerPC/PPCMIPeephole.cpp | 49 +- .../Target/PowerPC/PPCMachineFunctionInfo.cpp | 23 +- .../Target/PowerPC/PPCMachineFunctionInfo.h | 41 +- .../Target/PowerPC/PPCMachineScheduler.cpp | 52 +- .../lib/Target/PowerPC/PPCMachineScheduler.h | 3 + .../lib/Target/PowerPC/PPCMacroFusion.cpp | 203 + .../lib/Target/PowerPC/PPCMacroFusion.def | 45 + .../llvm/lib/Target/PowerPC/PPCMacroFusion.h | 22 + .../lib/Target/PowerPC/PPCPreEmitPeephole.cpp | 10 + .../lib/Target/PowerPC/PPCRegisterInfo.cpp | 301 +- .../llvm/lib/Target/PowerPC/PPCRegisterInfo.h | 22 +- .../lib/Target/PowerPC/PPCRegisterInfo.td | 20 +- .../llvm/lib/Target/PowerPC/PPCScheduleP9.td | 10 +- .../llvm/lib/Target/PowerPC/PPCSubtarget.cpp | 38 +- .../lib/Target/PowerPC/PPCTLSDynamicCall.cpp | 4 +- .../lib/Target/PowerPC/PPCTargetMachine.cpp | 23 +- .../Target/PowerPC/PPCTargetObjectFile.cpp | 2 +- .../Target/PowerPC/PPCTargetTransformInfo.cpp | 167 +- .../Target/PowerPC/PPCTargetTransformInfo.h | 44 +- gnu/llvm/llvm/lib/Target/PowerPC/README.txt | 61 - .../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 579 +- gnu/llvm/llvm/lib/Target/RISCV/CMakeLists.txt | 1 + .../RISCV/Disassembler/RISCVDisassembler.cpp | 49 +- .../RISCV/MCTargetDesc/RISCVAsmBackend.cpp | 75 +- .../RISCV/MCTargetDesc/RISCVAsmBackend.h | 49 +- .../MCTargetDesc/RISCVELFObjectWriter.cpp | 2 + .../RISCV/MCTargetDesc/RISCVELFStreamer.cpp | 103 +- .../RISCV/MCTargetDesc/RISCVELFStreamer.h | 90 +- .../RISCV/MCTargetDesc/RISCVInstPrinter.cpp | 35 +- .../RISCV/MCTargetDesc/RISCVInstPrinter.h | 15 +- .../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 51 +- .../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 2 +- .../RISCV/MCTargetDesc/RISCVMCTargetDesc.cpp | 52 +- .../RISCV/MCTargetDesc/RISCVMCTargetDesc.h | 4 - .../MCTargetDesc/RISCVTargetStreamer.cpp | 70 + .../RISCV/MCTargetDesc/RISCVTargetStreamer.h | 33 +- gnu/llvm/llvm/lib/Target/RISCV/RISCV.h | 3 + gnu/llvm/llvm/lib/Target/RISCV/RISCV.td | 149 +- .../llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 61 +- .../RISCV/RISCVExpandAtomicPseudoInsts.cpp | 618 + .../Target/RISCV/RISCVExpandPseudoInsts.cpp | 523 +- .../lib/Target/RISCV/RISCVFrameLowering.cpp | 364 +- .../lib/Target/RISCV/RISCVFrameLowering.h | 14 +- .../lib/Target/RISCV/RISCVISelDAGToDAG.cpp | 431 +- .../llvm/lib/Target/RISCV/RISCVISelDAGToDAG.h | 65 + .../lib/Target/RISCV/RISCVISelLowering.cpp | 145 +- .../llvm/lib/Target/RISCV/RISCVISelLowering.h | 61 +- .../lib/Target/RISCV/RISCVInstrFormats.td | 18 + .../lib/Target/RISCV/RISCVInstrFormatsV.td | 300 + .../llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 61 +- .../llvm/lib/Target/RISCV/RISCVInstrInfo.h | 25 +- .../llvm/lib/Target/RISCV/RISCVInstrInfo.td | 64 +- .../llvm/lib/Target/RISCV/RISCVInstrInfoA.td | 8 +- .../llvm/lib/Target/RISCV/RISCVInstrInfoB.td | 1063 + .../llvm/lib/Target/RISCV/RISCVInstrInfoD.td | 51 +- .../llvm/lib/Target/RISCV/RISCVInstrInfoF.td | 42 +- .../llvm/lib/Target/RISCV/RISCVInstrInfoV.td | 873 + .../Target/RISCV/RISCVInstructionSelector.cpp | 1 + .../Target/RISCV/RISCVMachineFunctionInfo.h | 21 +- .../lib/Target/RISCV/RISCVRegisterInfo.cpp | 42 +- .../llvm/lib/Target/RISCV/RISCVRegisterInfo.h | 11 +- .../lib/Target/RISCV/RISCVRegisterInfo.td | 99 + .../lib/Target/RISCV/RISCVSchedRocket32.td | 18 +- .../lib/Target/RISCV/RISCVSchedRocket64.td | 18 +- .../llvm/lib/Target/RISCV/RISCVSchedule.td | 9 + .../llvm/lib/Target/RISCV/RISCVSubtarget.cpp | 2 +- .../llvm/lib/Target/RISCV/RISCVSubtarget.h | 28 +- .../lib/Target/RISCV/RISCVSystemOperands.td | 27 +- .../lib/Target/RISCV/RISCVTargetMachine.cpp | 6 +- .../Target/RISCV/RISCVTargetObjectFile.cpp | 6 +- .../lib/Target/RISCV/RISCVTargetObjectFile.h | 3 +- .../Target/RISCV/RISCVTargetTransformInfo.cpp | 10 +- .../Target/RISCV/RISCVTargetTransformInfo.h | 9 +- .../lib/Target/RISCV/Utils/RISCVBaseInfo.h | 3 +- .../Target/Sparc/AsmParser/SparcAsmParser.cpp | 19 +- .../llvm/lib/Target/Sparc/LeonFeatures.td | 16 +- .../Sparc/MCTargetDesc/SparcAsmBackend.cpp | 5 +- .../Sparc/MCTargetDesc/SparcInstPrinter.cpp | 3 +- .../Sparc/MCTargetDesc/SparcInstPrinter.h | 8 +- .../Sparc/MCTargetDesc/SparcMCAsmInfo.cpp | 2 - .../Sparc/MCTargetDesc/SparcMCTargetDesc.cpp | 4 +- .../Sparc/MCTargetDesc/SparcMCTargetDesc.h | 4 - gnu/llvm/llvm/lib/Target/Sparc/Sparc.h | 1 - gnu/llvm/llvm/lib/Target/Sparc/Sparc.td | 6 +- .../llvm/lib/Target/Sparc/SparcAsmPrinter.cpp | 21 +- .../llvm/lib/Target/Sparc/SparcCallingConv.td | 2 +- .../lib/Target/Sparc/SparcFrameLowering.cpp | 17 +- .../lib/Target/Sparc/SparcFrameLowering.h | 2 +- .../lib/Target/Sparc/SparcISelLowering.cpp | 107 +- .../llvm/lib/Target/Sparc/SparcISelLowering.h | 4 +- .../llvm/lib/Target/Sparc/SparcInstr64Bit.td | 9 +- .../lib/Target/Sparc/SparcInstrAliases.td | 4 +- .../lib/Target/Sparc/SparcInstrFormats.td | 2 +- .../llvm/lib/Target/Sparc/SparcInstrInfo.cpp | 15 +- .../llvm/lib/Target/Sparc/SparcInstrInfo.h | 6 +- .../llvm/lib/Target/Sparc/SparcInstrInfo.td | 91 +- .../Target/Sparc/SparcMachineFunctionInfo.h | 12 +- .../lib/Target/Sparc/SparcRegisterInfo.cpp | 2 +- .../lib/Target/Sparc/SparcRegisterInfo.td | 4 +- .../llvm/lib/Target/Sparc/SparcSchedule.td | 2 +- .../llvm/lib/Target/Sparc/SparcSubtarget.cpp | 2 +- .../lib/Target/Sparc/SparcTargetMachine.cpp | 3 +- .../Target/Sparc/SparcTargetObjectFile.cpp | 2 +- .../SystemZ/AsmParser/SystemZAsmParser.cpp | 386 +- .../llvm/lib/Target/SystemZ/CMakeLists.txt | 1 + .../MCTargetDesc/SystemZInstPrinter.cpp | 3 +- .../SystemZ/MCTargetDesc/SystemZInstPrinter.h | 11 +- .../MCTargetDesc/SystemZMCAsmBackend.cpp | 4 - .../SystemZ/MCTargetDesc/SystemZMCAsmInfo.cpp | 2 - .../MCTargetDesc/SystemZMCTargetDesc.cpp | 7 +- gnu/llvm/llvm/lib/Target/SystemZ/SystemZ.h | 1 + .../lib/Target/SystemZ/SystemZAsmPrinter.cpp | 48 +- .../lib/Target/SystemZ/SystemZAsmPrinter.h | 6 +- .../lib/Target/SystemZ/SystemZCallingConv.h | 2 +- .../SystemZ/SystemZConstantPoolValue.cpp | 7 +- .../Target/SystemZ/SystemZConstantPoolValue.h | 2 +- .../Target/SystemZ/SystemZCopyPhysRegs.cpp | 120 + .../lib/Target/SystemZ/SystemZFeatures.td | 87 +- .../Target/SystemZ/SystemZFrameLowering.cpp | 323 +- .../lib/Target/SystemZ/SystemZFrameLowering.h | 25 +- .../Target/SystemZ/SystemZISelDAGToDAG.cpp | 3 +- .../Target/SystemZ/SystemZISelLowering.cpp | 650 +- .../lib/Target/SystemZ/SystemZISelLowering.h | 35 +- .../lib/Target/SystemZ/SystemZInstrBuilder.h | 3 +- .../llvm/lib/Target/SystemZ/SystemZInstrFP.td | 24 +- .../lib/Target/SystemZ/SystemZInstrFormats.td | 198 +- .../lib/Target/SystemZ/SystemZInstrInfo.cpp | 318 +- .../lib/Target/SystemZ/SystemZInstrInfo.h | 41 +- .../lib/Target/SystemZ/SystemZInstrInfo.td | 21 +- .../lib/Target/SystemZ/SystemZInstrVector.td | 418 +- .../SystemZ/SystemZMachineFunctionInfo.h | 16 +- .../lib/Target/SystemZ/SystemZOperands.td | 60 +- .../lib/Target/SystemZ/SystemZOperators.td | 8 +- .../lib/Target/SystemZ/SystemZPatterns.td | 6 +- .../lib/Target/SystemZ/SystemZProcessors.td | 2 +- .../Target/SystemZ/SystemZRegisterInfo.cpp | 21 +- .../lib/Target/SystemZ/SystemZRegisterInfo.h | 9 +- .../lib/Target/SystemZ/SystemZRegisterInfo.td | 6 +- .../SystemZ/SystemZSelectionDAGInfo.cpp | 16 +- .../Target/SystemZ/SystemZSelectionDAGInfo.h | 7 +- .../lib/Target/SystemZ/SystemZShortenInst.cpp | 45 +- .../lib/Target/SystemZ/SystemZSubtarget.cpp | 19 +- .../lib/Target/SystemZ/SystemZSubtarget.h | 4 + .../llvm/lib/Target/SystemZ/SystemZTDC.cpp | 14 + .../Target/SystemZ/SystemZTargetMachine.cpp | 52 +- .../lib/Target/SystemZ/SystemZTargetMachine.h | 13 +- .../SystemZ/SystemZTargetTransformInfo.cpp | 421 +- .../SystemZ/SystemZTargetTransformInfo.h | 51 +- gnu/llvm/llvm/lib/Target/Target.cpp | 8 +- .../lib/Target/TargetLoweringObjectFile.cpp | 38 +- gnu/llvm/llvm/lib/Target/TargetMachine.cpp | 32 +- gnu/llvm/llvm/lib/Target/TargetMachineC.cpp | 4 +- .../lib/Target/VE/AsmParser/CMakeLists.txt | 3 + .../lib/Target/VE/AsmParser/LLVMBuild.txt | 22 + .../lib/Target/VE/AsmParser/VEAsmParser.cpp | 1454 + gnu/llvm/llvm/lib/Target/VE/CMakeLists.txt | 7 +- .../lib/Target/VE/Disassembler/CMakeLists.txt | 3 + .../lib/Target/VE/Disassembler/LLVMBuild.txt | 22 + .../Target/VE/Disassembler/VEDisassembler.cpp | 560 + gnu/llvm/llvm/lib/Target/VE/LLVMBuild.txt | 8 +- .../lib/Target/VE/MCTargetDesc/CMakeLists.txt | 5 + .../lib/Target/VE/MCTargetDesc/LLVMBuild.txt | 2 +- .../Target/VE/MCTargetDesc/VEAsmBackend.cpp | 224 + .../VE/MCTargetDesc/VEELFObjectWriter.cpp | 135 + .../lib/Target/VE/MCTargetDesc/VEFixupKinds.h | 61 + .../Target/VE/MCTargetDesc/VEInstPrinter.cpp | 227 + .../Target/VE/MCTargetDesc/VEInstPrinter.h | 62 + .../Target/VE/MCTargetDesc/VEMCAsmInfo.cpp | 1 + .../VE/MCTargetDesc/VEMCCodeEmitter.cpp | 165 + .../lib/Target/VE/MCTargetDesc/VEMCExpr.cpp | 225 + .../lib/Target/VE/MCTargetDesc/VEMCExpr.h | 95 + .../Target/VE/MCTargetDesc/VEMCTargetDesc.cpp | 11 +- .../Target/VE/MCTargetDesc/VEMCTargetDesc.h | 10 +- .../VE/MCTargetDesc/VETargetStreamer.cpp | 2 +- .../lib/Target/VE/TargetInfo/VETargetInfo.cpp | 3 +- .../lib/Target/VE/TargetInfo/VETargetInfo.h | 20 + gnu/llvm/llvm/lib/Target/VE/VE.h | 293 +- gnu/llvm/llvm/lib/Target/VE/VE.td | 8 + gnu/llvm/llvm/lib/Target/VE/VEAsmPrinter.cpp | 283 +- gnu/llvm/llvm/lib/Target/VE/VECallingConv.td | 70 + .../llvm/lib/Target/VE/VEFrameLowering.cpp | 185 +- gnu/llvm/llvm/lib/Target/VE/VEFrameLowering.h | 24 +- .../llvm/lib/Target/VE/VEISelDAGToDAG.cpp | 269 + .../llvm/lib/Target/VE/VEISelLowering.cpp | 863 +- gnu/llvm/llvm/lib/Target/VE/VEISelLowering.h | 49 +- gnu/llvm/llvm/lib/Target/VE/VEInstrFormats.td | 176 +- gnu/llvm/llvm/lib/Target/VE/VEInstrInfo.cpp | 494 +- gnu/llvm/llvm/lib/Target/VE/VEInstrInfo.h | 43 +- gnu/llvm/llvm/lib/Target/VE/VEInstrInfo.td | 1991 +- gnu/llvm/llvm/lib/Target/VE/VEMCInstLower.cpp | 17 +- .../lib/Target/VE/VEMachineFunctionInfo.cpp | 13 + .../lib/Target/VE/VEMachineFunctionInfo.h | 48 + .../llvm/lib/Target/VE/VERegisterInfo.cpp | 62 +- gnu/llvm/llvm/lib/Target/VE/VERegisterInfo.h | 2 +- gnu/llvm/llvm/lib/Target/VE/VERegisterInfo.td | 131 +- gnu/llvm/llvm/lib/Target/VE/VESubtarget.cpp | 2 +- gnu/llvm/llvm/lib/Target/VE/VESubtarget.h | 2 +- .../llvm/lib/Target/VE/VETargetMachine.cpp | 8 +- gnu/llvm/llvm/lib/Target/VE/VETargetMachine.h | 2 + .../AsmParser/WebAssemblyAsmParser.cpp | 45 +- .../lib/Target/WebAssembly/CMakeLists.txt | 3 +- .../Disassembler/WebAssemblyDisassembler.cpp | 20 +- .../MCTargetDesc/WebAssemblyAsmBackend.cpp | 4 +- .../MCTargetDesc/WebAssemblyFixupKinds.h | 1 + .../MCTargetDesc/WebAssemblyInstPrinter.cpp | 36 +- .../MCTargetDesc/WebAssemblyInstPrinter.h | 3 +- .../MCTargetDesc/WebAssemblyMCCodeEmitter.cpp | 4 + .../MCTargetDesc/WebAssemblyMCTargetDesc.h | 434 +- .../WebAssemblyTargetStreamer.cpp | 6 +- .../MCTargetDesc/WebAssemblyTargetStreamer.h | 1 - .../WebAssemblyWasmObjectWriter.cpp | 14 +- .../TargetInfo/WebAssemblyTargetInfo.cpp | 6 + .../TargetInfo/WebAssemblyTargetInfo.h | 7 + .../llvm/lib/Target/WebAssembly/WebAssembly.h | 17 +- .../lib/Target/WebAssembly/WebAssembly.td | 7 +- .../WebAssemblyAddMissingPrototypes.cpp | 2 +- .../WebAssembly/WebAssemblyAsmPrinter.cpp | 67 +- .../WebAssembly/WebAssemblyAsmPrinter.h | 19 +- .../Target/WebAssembly/WebAssemblyCFGSort.cpp | 32 +- .../WebAssembly/WebAssemblyCFGStackify.cpp | 155 +- .../WebAssembly/WebAssemblyDebugFixup.cpp | 138 + .../WebAssemblyDebugValueManager.cpp | 8 +- .../WebAssembly/WebAssemblyExceptionInfo.cpp | 23 +- .../WebAssembly/WebAssemblyExceptionInfo.h | 19 +- .../WebAssembly/WebAssemblyExplicitLocals.cpp | 89 +- .../WebAssembly/WebAssemblyFastISel.cpp | 89 +- .../WebAssemblyFixBrTableDefaults.cpp | 155 + .../WebAssemblyFixFunctionBitcasts.cpp | 13 +- .../WebAssemblyFixIrreducibleControlFlow.cpp | 58 +- .../WebAssembly/WebAssemblyFrameLowering.cpp | 128 +- .../WebAssembly/WebAssemblyFrameLowering.h | 11 +- .../lib/Target/WebAssembly/WebAssemblyISD.def | 3 +- .../WebAssembly/WebAssemblyISelDAGToDAG.cpp | 76 +- .../WebAssembly/WebAssemblyISelLowering.cpp | 568 +- .../WebAssembly/WebAssemblyISelLowering.h | 6 +- .../WebAssembly/WebAssemblyInstrAtomics.td | 837 +- .../WebAssembly/WebAssemblyInstrBulkMemory.td | 30 +- .../WebAssembly/WebAssemblyInstrCall.td | 167 +- .../WebAssembly/WebAssemblyInstrControl.td | 33 +- .../WebAssembly/WebAssemblyInstrFormats.td | 16 +- .../WebAssembly/WebAssemblyInstrInfo.cpp | 7 +- .../WebAssembly/WebAssemblyInstrInfo.td | 53 +- .../WebAssembly/WebAssemblyInstrMemory.td | 480 +- .../Target/WebAssembly/WebAssemblyInstrRef.td | 2 +- .../WebAssembly/WebAssemblyInstrSIMD.td | 544 +- .../WebAssembly/WebAssemblyLateEHPrepare.cpp | 34 +- .../WebAssembly/WebAssemblyLowerBrUnless.cpp | 2 +- .../WebAssemblyLowerEmscriptenEHSjLj.cpp | 173 +- .../WebAssemblyLowerGlobalDtors.cpp | 30 +- .../WebAssembly/WebAssemblyMCInstLower.cpp | 29 +- .../WebAssemblyMachineFunctionInfo.cpp | 34 +- .../WebAssemblyMachineFunctionInfo.h | 36 +- .../WebAssemblyMemIntrinsicResults.cpp | 3 +- .../WebAssemblyOptimizeLiveIntervals.cpp | 15 +- .../WebAssemblyOptimizeReturned.cpp | 15 +- .../WebAssembly/WebAssemblyPeephole.cpp | 7 +- .../WebAssembly/WebAssemblyRegColoring.cpp | 3 + .../WebAssembly/WebAssemblyRegNumbering.cpp | 2 +- .../WebAssembly/WebAssemblyRegStackify.cpp | 179 +- .../WebAssembly/WebAssemblyRegisterInfo.cpp | 31 +- .../WebAssemblyReplacePhysRegs.cpp | 14 +- .../WebAssemblyRuntimeLibcallSignatures.cpp | 12 +- .../WebAssemblySelectionDAGInfo.cpp | 28 +- .../WebAssembly/WebAssemblySelectionDAGInfo.h | 15 +- .../WebAssemblySetP2AlignOperands.cpp | 2 +- .../WebAssembly/WebAssemblySubtarget.cpp | 17 +- .../Target/WebAssembly/WebAssemblySubtarget.h | 10 +- .../WebAssembly/WebAssemblyTargetMachine.cpp | 55 +- .../WebAssembly/WebAssemblyTargetMachine.h | 2 +- .../WebAssemblyTargetTransformInfo.cpp | 14 +- .../WebAssemblyTargetTransformInfo.h | 1 + .../WebAssembly/WebAssemblyUtilities.cpp | 19 +- .../Target/WebAssembly/WebAssemblyUtilities.h | 4 + .../WebAssembly/known_gcc_test_failures.txt | 1 - .../lib/Target/X86/AsmParser/X86AsmParser.cpp | 616 +- .../lib/Target/X86/AsmParser/X86Operand.h | 54 +- gnu/llvm/llvm/lib/Target/X86/CMakeLists.txt | 6 +- .../X86/Disassembler/X86Disassembler.cpp | 33 +- .../X86/Disassembler/X86DisassemblerDecoder.h | 15 +- gnu/llvm/llvm/lib/Target/X86/ImmutableGraph.h | 1 - gnu/llvm/llvm/lib/Target/X86/LLVMBuild.txt | 4 +- .../Target/X86/MCTargetDesc/CMakeLists.txt | 1 + .../lib/Target/X86/MCTargetDesc/LLVMBuild.txt | 2 +- .../X86/MCTargetDesc/X86ATTInstPrinter.cpp | 5 +- .../X86/MCTargetDesc/X86ATTInstPrinter.h | 14 +- .../Target/X86/MCTargetDesc/X86AsmBackend.cpp | 1029 +- .../lib/Target/X86/MCTargetDesc/X86BaseInfo.h | 107 +- .../X86/MCTargetDesc/X86ELFObjectWriter.cpp | 4 +- .../X86/MCTargetDesc/X86InstComments.cpp | 195 +- .../X86/MCTargetDesc/X86InstPrinterCommon.cpp | 26 +- .../X86/MCTargetDesc/X86InstPrinterCommon.h | 4 +- .../X86/MCTargetDesc/X86IntelInstPrinter.cpp | 3 +- .../X86/MCTargetDesc/X86IntelInstPrinter.h | 15 +- .../Target/X86/MCTargetDesc/X86MCAsmInfo.cpp | 18 +- .../Target/X86/MCTargetDesc/X86MCAsmInfo.h | 8 +- .../X86/MCTargetDesc/X86MCCodeEmitter.cpp | 696 +- .../X86/MCTargetDesc/X86MCTargetDesc.cpp | 25 +- .../Target/X86/MCTargetDesc/X86MCTargetDesc.h | 13 +- .../X86/MCTargetDesc/X86ShuffleDecode.cpp | 571 + .../X86/MCTargetDesc/X86ShuffleDecode.h | 166 + .../X86/MCTargetDesc/X86WinCOFFStreamer.cpp | 8 +- .../MCTargetDesc/X86WinCOFFTargetStreamer.cpp | 24 +- gnu/llvm/llvm/lib/Target/X86/X86.h | 22 +- gnu/llvm/llvm/lib/Target/X86/X86.td | 60 +- .../llvm/lib/Target/X86/X86AsmPrinter.cpp | 53 +- gnu/llvm/llvm/lib/Target/X86/X86AsmPrinter.h | 23 +- .../X86/X86AvoidStoreForwardingBlocks.cpp | 47 +- .../lib/Target/X86/X86AvoidTrailingCall.cpp | 97 +- .../Target/X86/X86CallFrameOptimization.cpp | 15 +- .../llvm/lib/Target/X86/X86CallLowering.cpp | 34 +- .../llvm/lib/Target/X86/X86CallLowering.h | 2 +- .../llvm/lib/Target/X86/X86CallingConv.cpp | 10 +- .../llvm/lib/Target/X86/X86CallingConv.td | 5 +- .../lib/Target/X86/X86DiscriminateMemOps.cpp | 2 +- .../lib/Target/X86/X86DomainReassignment.cpp | 30 +- gnu/llvm/llvm/lib/Target/X86/X86EvexToVex.cpp | 6 +- .../llvm/lib/Target/X86/X86ExpandPseudo.cpp | 89 +- gnu/llvm/llvm/lib/Target/X86/X86FastISel.cpp | 269 +- .../llvm/lib/Target/X86/X86FixupBWInsts.cpp | 2 +- gnu/llvm/llvm/lib/Target/X86/X86FixupLEAs.cpp | 19 +- .../llvm/lib/Target/X86/X86FixupSetCC.cpp | 8 +- .../lib/Target/X86/X86FlagsCopyLowering.cpp | 155 +- .../llvm/lib/Target/X86/X86FloatingPoint.cpp | 3 + .../llvm/lib/Target/X86/X86FrameLowering.cpp | 722 +- .../llvm/lib/Target/X86/X86FrameLowering.h | 75 +- .../llvm/lib/Target/X86/X86ISelDAGToDAG.cpp | 1217 +- .../llvm/lib/Target/X86/X86ISelLowering.cpp | 10269 +++-- .../llvm/lib/Target/X86/X86ISelLowering.h | 1724 +- .../Target/X86/X86IndirectBranchTracking.cpp | 37 +- .../llvm/lib/Target/X86/X86IndirectThunks.cpp | 102 +- .../llvm/lib/Target/X86/X86InsertPrefetch.cpp | 2 +- .../llvm/lib/Target/X86/X86InsertWait.cpp | 151 + gnu/llvm/llvm/lib/Target/X86/X86InstrAMX.td | 119 + .../llvm/lib/Target/X86/X86InstrAVX512.td | 2614 +- .../llvm/lib/Target/X86/X86InstrArithmetic.td | 179 +- .../llvm/lib/Target/X86/X86InstrBuilder.h | 2 +- .../llvm/lib/Target/X86/X86InstrCompiler.td | 176 +- .../llvm/lib/Target/X86/X86InstrControl.td | 31 +- gnu/llvm/llvm/lib/Target/X86/X86InstrFMA.td | 70 +- .../llvm/lib/Target/X86/X86InstrFMA3Info.cpp | 7 +- .../llvm/lib/Target/X86/X86InstrFMA3Info.h | 4 - .../llvm/lib/Target/X86/X86InstrFPStack.td | 97 +- .../lib/Target/X86/X86InstrFoldTables.cpp | 206 +- .../llvm/lib/Target/X86/X86InstrFoldTables.h | 2 +- .../llvm/lib/Target/X86/X86InstrFormats.td | 47 +- .../lib/Target/X86/X86InstrFragmentsSIMD.td | 199 +- gnu/llvm/llvm/lib/Target/X86/X86InstrInfo.cpp | 1102 +- gnu/llvm/llvm/lib/Target/X86/X86InstrInfo.h | 72 +- gnu/llvm/llvm/lib/Target/X86/X86InstrInfo.td | 203 +- gnu/llvm/llvm/lib/Target/X86/X86InstrMMX.td | 76 +- gnu/llvm/llvm/lib/Target/X86/X86InstrSGX.td | 6 +- gnu/llvm/llvm/lib/Target/X86/X86InstrSSE.td | 444 +- .../lib/Target/X86/X86InstrShiftRotate.td | 104 +- .../llvm/lib/Target/X86/X86InstrSystem.td | 89 +- gnu/llvm/llvm/lib/Target/X86/X86InstrTSX.td | 8 +- gnu/llvm/llvm/lib/Target/X86/X86InstrVMX.td | 2 +- gnu/llvm/llvm/lib/Target/X86/X86InstrXOP.td | 22 +- .../lib/Target/X86/X86InstructionSelector.cpp | 24 +- .../lib/Target/X86/X86InterleavedAccess.cpp | 159 +- .../llvm/lib/Target/X86/X86IntrinsicsInfo.h | 26 +- .../llvm/lib/Target/X86/X86LegalizerInfo.cpp | 8 +- .../llvm/lib/Target/X86/X86LegalizerInfo.h | 4 +- .../X86LoadValueInjectionLoadHardening.cpp | 76 - .../llvm/lib/Target/X86/X86MCInstLower.cpp | 1254 +- .../lib/Target/X86/X86MachineFunctionInfo.h | 58 +- .../llvm/lib/Target/X86/X86MacroFusion.cpp | 2 +- gnu/llvm/llvm/lib/Target/X86/X86MacroFusion.h | 4 +- .../llvm/lib/Target/X86/X86OptimizeLEAs.cpp | 2 +- .../lib/Target/X86/X86PadShortFunction.cpp | 1 + .../lib/Target/X86/X86PartialReduction.cpp | 490 + .../llvm/lib/Target/X86/X86PfmCounters.td | 10 + .../llvm/lib/Target/X86/X86RegisterInfo.cpp | 38 +- .../llvm/lib/Target/X86/X86RegisterInfo.h | 6 +- .../llvm/lib/Target/X86/X86RegisterInfo.td | 23 +- .../llvm/lib/Target/X86/X86SchedBroadwell.td | 57 +- .../llvm/lib/Target/X86/X86SchedHaswell.td | 87 +- .../lib/Target/X86/X86SchedSandyBridge.td | 21 +- .../lib/Target/X86/X86SchedSkylakeClient.td | 65 +- .../lib/Target/X86/X86SchedSkylakeServer.td | 336 +- gnu/llvm/llvm/lib/Target/X86/X86Schedule.td | 17 +- .../llvm/lib/Target/X86/X86ScheduleAtom.td | 7 +- .../llvm/lib/Target/X86/X86ScheduleBdVer2.td | 43 +- .../llvm/lib/Target/X86/X86ScheduleBtVer2.td | 7 +- .../llvm/lib/Target/X86/X86ScheduleSLM.td | 82 +- .../llvm/lib/Target/X86/X86ScheduleZnver1.td | 7 +- .../llvm/lib/Target/X86/X86ScheduleZnver2.td | 96 +- .../lib/Target/X86/X86SelectionDAGInfo.cpp | 51 +- .../llvm/lib/Target/X86/X86SelectionDAGInfo.h | 12 +- .../X86/X86ShuffleDecodeConstantPool.cpp | 19 +- .../Target/X86/X86ShuffleDecodeConstantPool.h | 9 +- ...culativeExecutionSideEffectSuppression.cpp | 181 + .../X86/X86SpeculativeLoadHardening.cpp | 443 +- gnu/llvm/llvm/lib/Target/X86/X86Subtarget.cpp | 17 +- gnu/llvm/llvm/lib/Target/X86/X86Subtarget.h | 55 +- .../llvm/lib/Target/X86/X86TargetMachine.cpp | 54 +- .../llvm/lib/Target/X86/X86TargetMachine.h | 2 - .../lib/Target/X86/X86TargetObjectFile.cpp | 28 +- .../llvm/lib/Target/X86/X86TargetObjectFile.h | 24 - .../lib/Target/X86/X86TargetTransformInfo.cpp | 1766 +- .../lib/Target/X86/X86TargetTransformInfo.h | 119 +- .../llvm/lib/Target/X86/X86VZeroUpper.cpp | 8 + .../lib/Target/X86/X86WinAllocaExpander.cpp | 1 + .../llvm/lib/Target/X86/X86WinEHState.cpp | 99 +- .../XCore/MCTargetDesc/XCoreMCAsmInfo.cpp | 2 + .../XCore/MCTargetDesc/XCoreMCTargetDesc.cpp | 2 +- .../XCore/MCTargetDesc/XCoreMCTargetDesc.h | 6 - gnu/llvm/llvm/lib/Target/XCore/XCore.h | 1 - .../llvm/lib/Target/XCore/XCoreAsmPrinter.cpp | 49 +- .../lib/Target/XCore/XCoreFrameLowering.cpp | 45 +- .../lib/Target/XCore/XCoreFrameLowering.h | 18 +- .../lib/Target/XCore/XCoreISelDAGToDAG.cpp | 2 +- .../lib/Target/XCore/XCoreISelLowering.cpp | 40 +- .../llvm/lib/Target/XCore/XCoreISelLowering.h | 8 +- .../llvm/lib/Target/XCore/XCoreInstrInfo.cpp | 12 +- .../llvm/lib/Target/XCore/XCoreInstrInfo.h | 4 +- .../llvm/lib/Target/XCore/XCoreInstrInfo.td | 13 +- .../llvm/lib/Target/XCore/XCoreMCInstLower.h | 3 +- .../Target/XCore/XCoreMachineFunctionInfo.cpp | 12 +- .../lib/Target/XCore/XCoreRegisterInfo.cpp | 5 - .../llvm/lib/Target/XCore/XCoreRegisterInfo.h | 4 - .../lib/Target/XCore/XCoreRegisterInfo.td | 10 +- .../Target/XCore/XCoreSelectionDAGInfo.cpp | 4 +- .../lib/Target/XCore/XCoreSelectionDAGInfo.h | 4 +- .../lib/Target/XCore/XCoreTargetMachine.cpp | 2 +- .../Target/XCore/XCoreTargetObjectFile.cpp | 7 +- .../lib/Target/XCore/XCoreTargetObjectFile.h | 2 +- gnu/llvm/llvm/lib/TextAPI/CMakeLists.txt | 2 + .../llvm/lib/TextAPI/MachO/Architecture.cpp | 25 +- .../lib/TextAPI/MachO/ArchitectureSet.cpp | 3 +- .../llvm/lib/TextAPI/MachO/InterfaceFile.cpp | 28 +- .../llvm/lib/TextAPI/MachO/TextAPIContext.h | 1 - gnu/llvm/llvm/lib/TextAPI/MachO/TextStub.cpp | 31 +- .../llvm/lib/TextAPI/MachO/TextStubCommon.cpp | 14 +- .../llvm/lib/TextAPI/MachO/TextStubCommon.h | 1 - .../llvm-dlltool/DlltoolDriver.cpp | 2 +- .../lib/ToolDrivers/llvm-lib/LibDriver.cpp | 38 +- .../llvm/lib/ToolDrivers/llvm-lib/Options.td | 3 + .../AggressiveInstCombine.cpp | 10 + .../AggressiveInstCombineInternal.h | 15 +- .../TruncInstCombine.cpp | 40 +- .../llvm/lib/Transforms/CFGuard/CFGuard.cpp | 13 +- .../lib/Transforms/Coroutines/CoroCleanup.cpp | 28 +- .../lib/Transforms/Coroutines/CoroEarly.cpp | 67 +- .../lib/Transforms/Coroutines/CoroElide.cpp | 211 +- .../lib/Transforms/Coroutines/CoroFrame.cpp | 515 +- .../lib/Transforms/Coroutines/CoroInstr.h | 17 +- .../lib/Transforms/Coroutines/CoroInternal.h | 42 +- .../lib/Transforms/Coroutines/CoroSplit.cpp | 313 +- .../lib/Transforms/Coroutines/Coroutines.cpp | 7 +- .../llvm/lib/Transforms/IPO/AlwaysInliner.cpp | 33 +- .../lib/Transforms/IPO/ArgumentPromotion.cpp | 136 +- .../llvm/lib/Transforms/IPO/Attributor.cpp | 6860 +--- .../Transforms/IPO/AttributorAttributes.cpp | 7225 ++++ .../lib/Transforms/IPO/BlockExtractor.cpp | 3 +- .../llvm/lib/Transforms/IPO/CMakeLists.txt | 3 + .../Transforms/IPO/CalledValuePropagation.cpp | 31 +- .../llvm/lib/Transforms/IPO/ConstantMerge.cpp | 12 +- .../IPO/DeadArgumentElimination.cpp | 291 +- .../llvm/lib/Transforms/IPO/ExtractGV.cpp | 13 +- .../llvm/lib/Transforms/IPO/FunctionAttrs.cpp | 87 +- .../lib/Transforms/IPO/FunctionImport.cpp | 133 +- .../llvm/lib/Transforms/IPO/GlobalDCE.cpp | 9 + .../llvm/lib/Transforms/IPO/GlobalOpt.cpp | 269 +- .../llvm/lib/Transforms/IPO/GlobalSplit.cpp | 3 + .../lib/Transforms/IPO/HotColdSplitting.cpp | 12 +- .../Transforms/IPO/IPConstantPropagation.cpp | 37 +- gnu/llvm/llvm/lib/Transforms/IPO/IPO.cpp | 2 + .../llvm/lib/Transforms/IPO/InlineSimple.cpp | 15 +- gnu/llvm/llvm/lib/Transforms/IPO/Inliner.cpp | 617 +- .../llvm/lib/Transforms/IPO/LLVMBuild.txt | 2 +- .../llvm/lib/Transforms/IPO/LoopExtractor.cpp | 192 +- .../lib/Transforms/IPO/LowerTypeTests.cpp | 107 +- .../lib/Transforms/IPO/MergeFunctions.cpp | 7 +- .../llvm/lib/Transforms/IPO/OpenMPOpt.cpp | 1501 + .../lib/Transforms/IPO/PartialInlining.cpp | 165 +- .../lib/Transforms/IPO/PassManagerBuilder.cpp | 125 +- gnu/llvm/llvm/lib/Transforms/IPO/PruneEH.cpp | 4 +- .../llvm/lib/Transforms/IPO/SampleProfile.cpp | 186 +- .../llvm/lib/Transforms/IPO/StripSymbols.cpp | 8 +- .../IPO/SyntheticCountsPropagation.cpp | 8 +- .../lib/Transforms/IPO/WholeProgramDevirt.cpp | 422 +- .../lib/Transforms/InstCombine/CMakeLists.txt | 1 + .../InstCombine/InstCombineAddSub.cpp | 330 +- .../InstCombine/InstCombineAndOrXor.cpp | 232 +- .../InstCombine/InstCombineAtomicRMW.cpp | 14 +- .../InstCombine/InstCombineCalls.cpp | 968 +- .../InstCombine/InstCombineCasts.cpp | 484 +- .../InstCombine/InstCombineCompares.cpp | 478 +- .../InstCombine/InstCombineInternal.h | 137 +- .../InstCombineLoadStoreAlloca.cpp | 258 +- .../InstCombine/InstCombineMulDivRem.cpp | 161 +- .../InstCombine/InstCombineNegator.cpp | 474 + .../Transforms/InstCombine/InstCombinePHI.cpp | 18 +- .../InstCombine/InstCombineSelect.cpp | 487 +- .../InstCombine/InstCombineShifts.cpp | 19 +- .../InstCombineSimplifyDemanded.cpp | 323 +- .../InstCombine/InstCombineVectorOps.cpp | 559 +- .../InstCombine/InstructionCombining.cpp | 709 +- .../Instrumentation/AddressSanitizer.cpp | 646 +- .../Instrumentation/BoundsChecking.cpp | 23 +- .../lib/Transforms/Instrumentation/CFGMST.h | 16 +- .../Transforms/Instrumentation/CGProfile.cpp | 120 +- .../ControlHeightReduction.cpp | 143 +- .../Instrumentation/DataFlowSanitizer.cpp | 307 +- .../Instrumentation/GCOVProfiling.cpp | 330 +- .../Instrumentation/HWAddressSanitizer.cpp | 207 +- .../Instrumentation/IndirectCallPromotion.cpp | 64 +- .../Instrumentation/InstrOrderFile.cpp | 1 - .../Instrumentation/InstrProfiling.cpp | 102 +- .../Instrumentation/Instrumentation.cpp | 7 +- .../Instrumentation/MemorySanitizer.cpp | 840 +- .../Instrumentation/PGOInstrumentation.cpp | 111 +- .../Instrumentation/PGOMemOPSizeOpt.cpp | 192 +- .../Instrumentation/PoisonChecking.cpp | 73 +- .../Instrumentation/SanitizerCoverage.cpp | 124 +- .../Instrumentation/ThreadSanitizer.cpp | 82 +- .../Instrumentation/ValueProfileCollector.cpp | 10 +- .../Instrumentation/ValueProfileCollector.h | 3 +- .../Instrumentation/ValueProfilePlugins.inc | 30 +- .../ObjCARC/ARCRuntimeEntryPoints.h | 6 +- .../Transforms/ObjCARC/DependencyAnalysis.cpp | 5 +- .../llvm/lib/Transforms/ObjCARC/ObjCARC.h | 12 - .../lib/Transforms/ObjCARC/ObjCARCAPElim.cpp | 15 +- .../Transforms/ObjCARC/ObjCARCContract.cpp | 40 +- .../lib/Transforms/ObjCARC/ObjCARCExpand.cpp | 2 - .../lib/Transforms/ObjCARC/ObjCARCOpts.cpp | 73 +- gnu/llvm/llvm/lib/Transforms/Scalar/ADCE.cpp | 22 +- .../Scalar/AlignmentFromAssumptions.cpp | 124 +- gnu/llvm/llvm/lib/Transforms/Scalar/BDCE.cpp | 26 +- .../Transforms/Scalar/CallSiteSplitting.cpp | 156 +- .../Transforms/Scalar/ConstantHoisting.cpp | 20 +- .../Scalar/CorrelatedValuePropagation.cpp | 47 +- gnu/llvm/llvm/lib/Transforms/Scalar/DCE.cpp | 2 + .../Scalar/DeadStoreElimination.cpp | 1230 +- .../lib/Transforms/Scalar/DivRemPairs.cpp | 27 + .../llvm/lib/Transforms/Scalar/EarlyCSE.cpp | 193 +- .../llvm/lib/Transforms/Scalar/Float2Int.cpp | 11 +- gnu/llvm/llvm/lib/Transforms/Scalar/GVN.cpp | 101 +- .../llvm/lib/Transforms/Scalar/GVNHoist.cpp | 14 +- .../llvm/lib/Transforms/Scalar/GVNSink.cpp | 15 +- .../lib/Transforms/Scalar/IndVarSimplify.cpp | 621 +- .../Scalar/InductiveRangeCheckElimination.cpp | 120 +- .../Transforms/Scalar/InferAddressSpaces.cpp | 206 +- .../Transforms/Scalar/InstSimplifyPass.cpp | 2 +- .../lib/Transforms/Scalar/JumpThreading.cpp | 459 +- gnu/llvm/llvm/lib/Transforms/Scalar/LICM.cpp | 225 +- .../Transforms/Scalar/LoopDataPrefetch.cpp | 209 +- .../lib/Transforms/Scalar/LoopDeletion.cpp | 44 +- .../lib/Transforms/Scalar/LoopDistribute.cpp | 21 +- .../llvm/lib/Transforms/Scalar/LoopFuse.cpp | 109 +- .../Transforms/Scalar/LoopIdiomRecognize.cpp | 141 +- .../Transforms/Scalar/LoopInstSimplify.cpp | 2 +- .../lib/Transforms/Scalar/LoopInterchange.cpp | 65 +- .../Transforms/Scalar/LoopLoadElimination.cpp | 29 +- .../lib/Transforms/Scalar/LoopPassManager.cpp | 13 +- .../lib/Transforms/Scalar/LoopPredication.cpp | 57 +- .../lib/Transforms/Scalar/LoopRerollPass.cpp | 10 +- .../lib/Transforms/Scalar/LoopRotation.cpp | 2 +- .../lib/Transforms/Scalar/LoopSimplifyCFG.cpp | 10 +- .../Transforms/Scalar/LoopStrengthReduce.cpp | 206 +- .../Scalar/LoopUnrollAndJamPass.cpp | 96 +- .../lib/Transforms/Scalar/LoopUnrollPass.cpp | 181 +- .../lib/Transforms/Scalar/LoopUnswitch.cpp | 328 +- .../Transforms/Scalar/LoopVersioningLICM.cpp | 1 - .../lib/Transforms/Scalar/LowerAtomic.cpp | 13 +- .../Scalar/LowerConstantIntrinsics.cpp | 16 +- .../Scalar/LowerExpectIntrinsic.cpp | 77 +- .../Scalar/LowerMatrixIntrinsics.cpp | 1531 +- .../lib/Transforms/Scalar/MemCpyOptimizer.cpp | 136 +- .../Scalar/MergedLoadStoreMotion.cpp | 10 +- .../lib/Transforms/Scalar/NaryReassociate.cpp | 2 +- .../llvm/lib/Transforms/Scalar/NewGVN.cpp | 18 +- .../lib/Transforms/Scalar/PlaceSafepoints.cpp | 5 +- .../lib/Transforms/Scalar/Reassociate.cpp | 40 +- .../Scalar/RewriteStatepointsForGC.cpp | 193 +- gnu/llvm/llvm/lib/Transforms/Scalar/SCCP.cpp | 1367 +- gnu/llvm/llvm/lib/Transforms/Scalar/SROA.cpp | 558 +- .../llvm/lib/Transforms/Scalar/Scalarizer.cpp | 250 +- .../Scalar/SeparateConstOffsetFromGEP.cpp | 62 +- .../Transforms/Scalar/SimpleLoopUnswitch.cpp | 58 +- .../lib/Transforms/Scalar/SimplifyCFGPass.cpp | 8 + gnu/llvm/llvm/lib/Transforms/Scalar/Sink.cpp | 4 +- .../Transforms/Scalar/SpeculateAroundPHIs.cpp | 18 +- .../Scalar/SpeculativeExecution.cpp | 40 +- .../lib/Transforms/Scalar/StructurizeCFG.cpp | 246 +- .../Scalar/TailRecursionElimination.cpp | 585 +- .../Scalar/WarnMissedTransforms.cpp | 1 + .../lib/Transforms/Utils/AMDGPUEmitPrintf.cpp | 246 + .../Transforms/Utils/AssumeBundleBuilder.cpp | 618 + .../lib/Transforms/Utils/BasicBlockUtils.cpp | 292 +- .../Transforms/Utils/BreakCriticalEdges.cpp | 90 +- .../lib/Transforms/Utils/BuildLibCalls.cpp | 201 +- .../Transforms/Utils/BypassSlowDivision.cpp | 12 +- .../llvm/lib/Transforms/Utils/CMakeLists.txt | 10 +- .../lib/Transforms/Utils/CallGraphUpdater.cpp | 167 + .../Transforms/Utils/CallPromotionUtils.cpp | 231 +- .../Utils/CanonicalizeFreezeInLoops.cpp | 250 + .../lib/Transforms/Utils/CloneFunction.cpp | 29 +- .../lib/Transforms/Utils/CodeExtractor.cpp | 227 +- .../lib/Transforms/Utils/CodeMoverUtils.cpp | 281 +- .../llvm/lib/Transforms/Utils/Debugify.cpp | 135 +- .../Utils/EntryExitInstrumenter.cpp | 1 + .../lib/Transforms/Utils/EscapeEnumerator.cpp | 5 +- .../llvm/lib/Transforms/Utils/Evaluator.cpp | 49 +- .../lib/Transforms/Utils/FixIrreducible.cpp | 337 + .../llvm/lib/Transforms/Utils/FlattenCFG.cpp | 128 +- .../Transforms/Utils/FunctionComparator.cpp | 107 +- .../Transforms/Utils/FunctionImportUtils.cpp | 25 +- .../lib/Transforms/Utils/GlobalStatus.cpp | 5 +- .../Transforms/Utils/InjectTLIMappings.cpp | 52 +- .../lib/Transforms/Utils/InlineFunction.cpp | 432 +- .../lib/Transforms/Utils/InstructionNamer.cpp | 2 +- gnu/llvm/llvm/lib/Transforms/Utils/LCSSA.cpp | 14 +- gnu/llvm/llvm/lib/Transforms/Utils/Local.cpp | 307 +- .../Transforms/Utils/LoopRotationUtils.cpp | 649 +- .../lib/Transforms/Utils/LoopSimplify.cpp | 28 +- .../llvm/lib/Transforms/Utils/LoopUnroll.cpp | 312 +- .../lib/Transforms/Utils/LoopUnrollAndJam.cpp | 533 +- .../lib/Transforms/Utils/LoopUnrollPeel.cpp | 47 +- .../Transforms/Utils/LoopUnrollRuntime.cpp | 21 +- .../llvm/lib/Transforms/Utils/LoopUtils.cpp | 773 +- .../lib/Transforms/Utils/LoopVersioning.cpp | 15 +- .../llvm/lib/Transforms/Utils/LowerInvoke.cpp | 2 +- .../Transforms/Utils/LowerMemIntrinsics.cpp | 166 +- .../llvm/lib/Transforms/Utils/LowerSwitch.cpp | 7 - .../llvm/lib/Transforms/Utils/ModuleUtils.cpp | 25 +- .../lib/Transforms/Utils/NameAnonGlobals.cpp | 2 +- .../lib/Transforms/Utils/PredicateInfo.cpp | 171 +- .../Utils/PromoteMemoryToRegister.cpp | 5 - .../llvm/lib/Transforms/Utils/SSAUpdater.cpp | 7 +- .../Utils/ScalarEvolutionExpander.cpp | 2569 ++ .../llvm/lib/Transforms/Utils/SimplifyCFG.cpp | 361 +- .../lib/Transforms/Utils/SimplifyIndVar.cpp | 34 +- .../lib/Transforms/Utils/SimplifyLibCalls.cpp | 422 +- .../llvm/lib/Transforms/Utils/SizeOpts.cpp | 33 +- .../lib/Transforms/Utils/StripGCRelocates.cpp | 2 +- .../lib/Transforms/Utils/SymbolRewriter.cpp | 30 +- .../lib/Transforms/Utils/UnifyLoopExits.cpp | 220 + .../Utils/UniqueInternalLinkageNames.cpp | 97 + gnu/llvm/llvm/lib/Transforms/Utils/Utils.cpp | 6 + .../llvm/lib/Transforms/Utils/VNCoercion.cpp | 205 +- .../llvm/lib/Transforms/Utils/ValueMapper.cpp | 13 +- .../lib/Transforms/Vectorize/CMakeLists.txt | 2 + .../Vectorize/LoadStoreVectorizer.cpp | 144 +- .../Vectorize/LoopVectorizationLegality.cpp | 74 +- .../Vectorize/LoopVectorizationPlanner.h | 16 +- .../Transforms/Vectorize/LoopVectorize.cpp | 1289 +- .../Transforms/Vectorize/SLPVectorizer.cpp | 714 +- .../Transforms/Vectorize/VPRecipeBuilder.h | 95 +- .../llvm/lib/Transforms/Vectorize/VPlan.cpp | 301 +- .../llvm/lib/Transforms/Vectorize/VPlan.h | 372 +- .../Transforms/Vectorize/VPlanDominatorTree.h | 3 +- .../Transforms/Vectorize/VPlanTransforms.cpp | 31 +- .../Transforms/Vectorize/VPlanTransforms.h | 6 +- .../lib/Transforms/Vectorize/VPlanValue.h | 55 +- .../Transforms/Vectorize/VPlanVerifier.cpp | 1 + .../lib/Transforms/Vectorize/VPlanVerifier.h | 8 +- .../Transforms/Vectorize/VectorCombine.cpp | 699 + .../lib/Transforms/Vectorize/Vectorize.cpp | 4 +- gnu/llvm/llvm/lib/XRay/FDRTraceExpander.cpp | 6 +- gnu/llvm/llvm/lib/XRay/FDRTraceWriter.cpp | 14 +- gnu/llvm/llvm/lib/XRay/InstrumentationMap.cpp | 76 +- gnu/llvm/llvm/lib/XRay/Trace.cpp | 1 + gnu/llvm/llvm/runtimes/CMakeLists.txt | 53 +- gnu/llvm/llvm/tools/CMakeLists.txt | 3 +- gnu/llvm/llvm/tools/bugpoint/CMakeLists.txt | 2 +- .../llvm/tools/bugpoint/CrashDebugger.cpp | 13 +- .../llvm/tools/bugpoint/ExecutionDriver.cpp | 4 +- .../llvm/tools/bugpoint/Miscompilation.cpp | 30 +- .../llvm/tools/bugpoint/OptimizerDriver.cpp | 2 +- gnu/llvm/llvm/tools/bugpoint/ToolRunner.cpp | 4 +- gnu/llvm/llvm/tools/bugpoint/ToolRunner.h | 2 +- gnu/llvm/llvm/tools/bugpoint/bugpoint.cpp | 4 +- gnu/llvm/llvm/tools/dsymutil/BinaryHolder.cpp | 22 +- gnu/llvm/llvm/tools/dsymutil/BinaryHolder.h | 14 +- gnu/llvm/llvm/tools/dsymutil/CFBundle.cpp | 5 +- gnu/llvm/llvm/tools/dsymutil/CMakeLists.txt | 7 +- gnu/llvm/llvm/tools/dsymutil/DebugMap.cpp | 23 +- gnu/llvm/llvm/tools/dsymutil/DebugMap.h | 6 +- .../tools/dsymutil/DwarfLinkerForBinary.cpp | 3053 +- .../tools/dsymutil/DwarfLinkerForBinary.h | 391 +- gnu/llvm/llvm/tools/dsymutil/LinkUtils.h | 25 +- .../tools/dsymutil/MachODebugMapParser.cpp | 37 +- gnu/llvm/llvm/tools/dsymutil/MachOUtils.cpp | 15 +- gnu/llvm/llvm/tools/dsymutil/MachOUtils.h | 6 +- gnu/llvm/llvm/tools/dsymutil/Options.td | 41 +- gnu/llvm/llvm/tools/dsymutil/Reproducer.cpp | 85 + gnu/llvm/llvm/tools/dsymutil/Reproducer.h | 77 + gnu/llvm/llvm/tools/dsymutil/SymbolMap.cpp | 2 +- gnu/llvm/llvm/tools/dsymutil/dsymutil.cpp | 85 +- gnu/llvm/llvm/tools/dsymutil/dsymutil.h | 8 +- gnu/llvm/llvm/tools/gold/gold-plugin.cpp | 133 +- gnu/llvm/llvm/tools/llc/CMakeLists.txt | 4 +- gnu/llvm/llvm/tools/llc/llc.cpp | 192 +- gnu/llvm/llvm/tools/lli/CMakeLists.txt | 1 + gnu/llvm/llvm/tools/lli/lli.cpp | 236 +- gnu/llvm/llvm/tools/llvm-ar/llvm-ar.cpp | 184 +- .../tools/llvm-as-fuzzer/llvm-as-fuzzer.cpp | 3 +- gnu/llvm/llvm/tools/llvm-as/llvm-as.cpp | 25 +- gnu/llvm/llvm/tools/llvm-c-test/debuginfo.c | 6 +- gnu/llvm/llvm/tools/llvm-c-test/echo.cpp | 86 +- gnu/llvm/llvm/tools/llvm-c-test/main.c | 9 +- .../llvm/tools/llvm-cfi-verify/CMakeLists.txt | 1 - .../tools/llvm-cfi-verify/lib/CMakeLists.txt | 20 +- .../llvm-cfi-verify/lib/FileAnalysis.cpp | 11 +- .../llvm/tools/llvm-config/llvm-config.cpp | 22 +- gnu/llvm/llvm/tools/llvm-cov/CodeCoverage.cpp | 36 +- .../tools/llvm-cov/CoverageExporterJson.cpp | 19 +- .../tools/llvm-cov/CoverageExporterLcov.cpp | 14 +- .../llvm/tools/llvm-cov/CoverageFilters.cpp | 1 + .../llvm/tools/llvm-cov/CoverageFilters.h | 10 +- .../llvm/tools/llvm-cov/CoverageReport.cpp | 16 +- .../tools/llvm-cov/CoverageSummaryInfo.cpp | 2 +- .../tools/llvm-cov/SourceCoverageView.cpp | 4 +- .../tools/llvm-cov/SourceCoverageViewHTML.cpp | 11 +- gnu/llvm/llvm/tools/llvm-cov/gcov.cpp | 28 +- .../llvm/tools/llvm-cxxfilt/llvm-cxxfilt.cpp | 4 +- .../llvm/tools/llvm-diff/DiffConsumer.cpp | 12 +- .../llvm/tools/llvm-diff/DifferenceEngine.cpp | 30 +- .../llvm/tools/llvm-dwarfdump/CMakeLists.txt | 1 + .../tools/llvm-dwarfdump/SectionSizes.cpp | 124 + .../llvm/tools/llvm-dwarfdump/Statistics.cpp | 407 +- .../tools/llvm-dwarfdump/llvm-dwarfdump.cpp | 136 +- .../tools/llvm-dwarfdump/llvm-dwarfdump.h | 43 + gnu/llvm/llvm/tools/llvm-dwp/DWPStringPool.h | 2 +- gnu/llvm/llvm/tools/llvm-dwp/llvm-dwp.cpp | 126 +- .../llvm/tools/llvm-elfabi/ELFObjHandler.cpp | 6 +- .../llvm/tools/llvm-exegesis/CMakeLists.txt | 1 + .../llvm-exegesis/lib/AArch64/Target.cpp | 1 - .../llvm/tools/llvm-exegesis/lib/Analysis.cpp | 8 +- .../tools/llvm-exegesis/lib/Assembler.cpp | 18 +- .../llvm/tools/llvm-exegesis/lib/Assembler.h | 11 +- .../tools/llvm-exegesis/lib/BenchmarkResult.h | 8 +- .../llvm-exegesis/lib/BenchmarkRunner.cpp | 232 +- .../tools/llvm-exegesis/lib/BenchmarkRunner.h | 13 +- .../tools/llvm-exegesis/lib/CMakeLists.txt | 7 +- .../tools/llvm-exegesis/lib/Clustering.cpp | 13 +- .../tools/llvm-exegesis/lib/CodeTemplate.h | 5 + .../llvm/tools/llvm-exegesis/lib/Error.cpp | 31 + gnu/llvm/llvm/tools/llvm-exegesis/lib/Error.h | 29 + .../lib/LatencyBenchmarkRunner.cpp | 143 + .../lib/LatencyBenchmarkRunner.h | 38 + .../tools/llvm-exegesis/lib/LlvmState.cpp | 1 + .../llvm-exegesis/lib/MCInstrDescView.cpp | 6 +- .../tools/llvm-exegesis/lib/Mips/Target.cpp | 54 +- .../lib/ParallelSnippetGenerator.cpp | 223 + .../lib/ParallelSnippetGenerator.h | 65 + .../tools/llvm-exegesis/lib/PerfHelper.cpp | 43 +- .../llvm/tools/llvm-exegesis/lib/PerfHelper.h | 48 +- .../llvm-exegesis/lib/PowerPC/Target.cpp | 1 - .../llvm-exegesis/lib/RegisterAliasing.cpp | 9 + .../llvm-exegesis/lib/RegisterAliasing.h | 3 + .../lib/SerialSnippetGenerator.cpp | 181 + .../lib/SerialSnippetGenerator.h | 37 + .../tools/llvm-exegesis/lib/SnippetFile.cpp | 10 +- .../llvm-exegesis/lib/SnippetGenerator.cpp | 103 +- .../llvm-exegesis/lib/SnippetGenerator.h | 141 +- .../llvm-exegesis/lib/SnippetRepetitor.cpp | 2 + .../llvm/tools/llvm-exegesis/lib/Target.cpp | 91 +- .../llvm/tools/llvm-exegesis/lib/Target.h | 56 +- .../llvm-exegesis/lib/UopsBenchmarkRunner.cpp | 46 + .../llvm-exegesis/lib/UopsBenchmarkRunner.h | 38 + .../tools/llvm-exegesis/lib/X86/Target.cpp | 253 +- .../tools/llvm-exegesis/llvm-exegesis.cpp | 148 +- .../llvm/tools/llvm-extract/llvm-extract.cpp | 56 +- .../llvm/tools/llvm-gsymutil/CMakeLists.txt | 14 + .../tools/llvm-gsymutil/llvm-gsymutil.cpp | 503 + gnu/llvm/llvm/tools/llvm-ifs/llvm-ifs.cpp | 43 +- .../llvm-isel-fuzzer/llvm-isel-fuzzer.cpp | 18 +- .../llvm/tools/llvm-jitlink/CMakeLists.txt | 1 + .../tools/llvm-jitlink/llvm-jitlink-elf.cpp | 100 + .../tools/llvm-jitlink/llvm-jitlink-macho.cpp | 7 +- .../llvm/tools/llvm-jitlink/llvm-jitlink.cpp | 111 +- .../llvm/tools/llvm-jitlink/llvm-jitlink.h | 12 +- gnu/llvm/llvm/tools/llvm-link/llvm-link.cpp | 83 +- gnu/llvm/llvm/tools/llvm-lipo/llvm-lipo.cpp | 8 +- gnu/llvm/llvm/tools/llvm-lto/CMakeLists.txt | 5 +- gnu/llvm/llvm/tools/llvm-lto/llvm-lto.cpp | 65 +- gnu/llvm/llvm/tools/llvm-lto2/CMakeLists.txt | 2 + gnu/llvm/llvm/tools/llvm-lto2/llvm-lto2.cpp | 53 +- .../llvm-mc-assemble-fuzzer/CMakeLists.txt | 2 +- .../llvm-mc-assemble-fuzzer.cpp | 13 +- .../llvm-mc-disassemble-fuzzer/CMakeLists.txt | 1 - .../llvm-mc-disassemble-fuzzer.cpp | 1 + gnu/llvm/llvm/tools/llvm-mc/CMakeLists.txt | 2 +- gnu/llvm/llvm/tools/llvm-mc/Disassembler.cpp | 2 +- gnu/llvm/llvm/tools/llvm-mc/llvm-mc.cpp | 36 +- gnu/llvm/llvm/tools/llvm-mca/CMakeLists.txt | 1 - gnu/llvm/llvm/tools/llvm-mca/CodeRegion.h | 2 + .../tools/llvm-mca/CodeRegionGenerator.cpp | 12 +- gnu/llvm/llvm/tools/llvm-mca/llvm-mca.cpp | 10 +- .../llvm-microsoft-demangle-fuzzer.cpp | 2 +- gnu/llvm/llvm/tools/llvm-ml/CMakeLists.txt | 14 + gnu/llvm/llvm/tools/llvm-ml/Disassembler.cpp | 203 + gnu/llvm/llvm/tools/llvm-ml/Disassembler.h | 37 + gnu/llvm/llvm/tools/llvm-ml/llvm-ml.cpp | 382 + gnu/llvm/llvm/tools/llvm-nm/llvm-nm.cpp | 156 +- .../llvm/tools/llvm-objcopy/CMakeLists.txt | 4 + .../tools/llvm-objcopy/COFF/COFFObjcopy.cpp | 53 +- .../llvm/tools/llvm-objcopy/COFF/Reader.cpp | 19 +- .../llvm/tools/llvm-objcopy/COFF/Writer.cpp | 25 +- .../llvm/tools/llvm-objcopy/COFF/Writer.h | 1 + .../llvm/tools/llvm-objcopy/CopyConfig.cpp | 114 +- gnu/llvm/llvm/tools/llvm-objcopy/CopyConfig.h | 11 +- .../tools/llvm-objcopy/ELF/ELFObjcopy.cpp | 55 +- .../llvm/tools/llvm-objcopy/ELF/Object.cpp | 154 +- gnu/llvm/llvm/tools/llvm-objcopy/ELF/Object.h | 7 + .../tools/llvm-objcopy/InstallNameToolOpts.td | 12 + .../llvm-objcopy/MachO/MachOLayoutBuilder.cpp | 103 +- .../tools/llvm-objcopy/MachO/MachOObjcopy.cpp | 248 +- .../tools/llvm-objcopy/MachO/MachOReader.cpp | 120 +- .../tools/llvm-objcopy/MachO/MachOReader.h | 3 + .../tools/llvm-objcopy/MachO/MachOWriter.cpp | 100 +- .../tools/llvm-objcopy/MachO/MachOWriter.h | 2 + .../llvm/tools/llvm-objcopy/MachO/Object.cpp | 94 +- .../llvm/tools/llvm-objcopy/MachO/Object.h | 56 +- gnu/llvm/llvm/tools/llvm-objcopy/StripOpts.td | 3 + .../llvm/tools/llvm-objcopy/llvm-objcopy.cpp | 7 +- .../llvm/tools/llvm-objcopy/wasm/Object.cpp | 36 + .../llvm/tools/llvm-objcopy/wasm/Object.h | 47 + .../llvm/tools/llvm-objcopy/wasm/Reader.cpp | 33 + .../llvm/tools/llvm-objcopy/wasm/Reader.h | 31 + .../tools/llvm-objcopy/wasm/WasmObjcopy.cpp | 114 + .../tools/llvm-objcopy/wasm/WasmObjcopy.h | 31 + .../llvm/tools/llvm-objcopy/wasm/Writer.cpp | 78 + .../llvm/tools/llvm-objcopy/wasm/Writer.h | 50 + .../llvm/tools/llvm-objdump/CMakeLists.txt | 2 +- gnu/llvm/llvm/tools/llvm-objdump/COFFDump.cpp | 72 +- gnu/llvm/llvm/tools/llvm-objdump/COFFDump.h | 37 + gnu/llvm/llvm/tools/llvm-objdump/ELFDump.cpp | 68 +- gnu/llvm/llvm/tools/llvm-objdump/ELFDump.h | 39 + .../llvm/tools/llvm-objdump/MachODump.cpp | 234 +- gnu/llvm/llvm/tools/llvm-objdump/MachODump.h | 66 + gnu/llvm/llvm/tools/llvm-objdump/WasmDump.cpp | 13 +- gnu/llvm/llvm/tools/llvm-objdump/WasmDump.h | 35 + .../llvm/tools/llvm-objdump/XCOFFDump.cpp | 88 + gnu/llvm/llvm/tools/llvm-objdump/XCOFFDump.h | 33 + .../llvm/tools/llvm-objdump/llvm-objdump.cpp | 1505 +- .../llvm/tools/llvm-objdump/llvm-objdump.h | 78 +- .../tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp | 17 +- .../llvm/tools/llvm-opt-report/OptReport.cpp | 9 +- .../tools/llvm-pdbutil/DumpOutputStyle.cpp | 15 +- .../llvm/tools/llvm-pdbutil/FormatUtil.cpp | 12 +- gnu/llvm/llvm/tools/llvm-pdbutil/FormatUtil.h | 3 +- .../llvm-pdbutil/MinimalSymbolDumper.cpp | 4 +- .../tools/llvm-pdbutil/MinimalTypeDumper.cpp | 5 +- .../llvm/tools/llvm-pdbutil/StreamUtil.cpp | 6 +- .../llvm/tools/llvm-pdbutil/llvm-pdbutil.cpp | 6 +- .../llvm/tools/llvm-pdbutil/llvm-pdbutil.h | 1 + .../tools/llvm-profdata/llvm-profdata.cpp | 274 +- gnu/llvm/llvm/tools/llvm-rc/Opts.td | 2 +- .../llvm/tools/llvm-rc/ResourceFileWriter.cpp | 25 +- .../llvm/tools/llvm-rc/ResourceFileWriter.h | 5 +- .../tools/llvm-rc/ResourceScriptParser.cpp | 8 +- .../llvm/tools/llvm-rc/ResourceScriptStmt.cpp | 8 +- .../llvm/tools/llvm-rc/ResourceScriptStmt.h | 6 +- .../tools/llvm-rc/ResourceScriptToken.cpp | 3 +- gnu/llvm/llvm/tools/llvm-rc/llvm-rc.cpp | 13 +- .../llvm/tools/llvm-readobj/COFFDumper.cpp | 265 +- .../tools/llvm-readobj/DwarfCFIEHPrinter.h | 171 +- .../llvm/tools/llvm-readobj/ELFDumper.cpp | 2020 +- .../llvm/tools/llvm-readobj/ObjDumper.cpp | 4 +- gnu/llvm/llvm/tools/llvm-readobj/ObjDumper.h | 4 +- .../llvm/tools/llvm-readobj/WasmDumper.cpp | 26 +- .../llvm/tools/llvm-readobj/XCOFFDumper.cpp | 13 +- .../llvm/tools/llvm-readobj/llvm-readobj.cpp | 38 +- .../llvm/tools/llvm-reduce/CMakeLists.txt | 10 +- .../llvm/tools/llvm-reduce/DeltaManager.h | 6 +- .../llvm/tools/llvm-reduce/deltas/Delta.cpp | 2 +- .../llvm/tools/llvm-reduce/deltas/Delta.h | 38 +- .../llvm-reduce/deltas/ReduceArguments.cpp | 22 +- .../llvm-reduce/deltas/ReduceAttributes.cpp | 200 + .../llvm-reduce/deltas/ReduceAttributes.h | 20 + .../llvm-reduce/deltas/ReduceBasicBlocks.cpp | 11 +- .../llvm-reduce/deltas/ReduceFunctions.cpp | 12 +- .../llvm-reduce/deltas/ReduceGlobalVars.cpp | 21 +- .../llvm-reduce/deltas/ReduceInstructions.cpp | 11 +- .../llvm-reduce/deltas/ReduceMetadata.cpp | 31 +- .../deltas/ReduceOperandBundles.cpp | 124 + .../llvm-reduce/deltas/ReduceOperandBundles.h | 20 + .../llvm/tools/llvm-rtdyld/llvm-rtdyld.cpp | 6 +- gnu/llvm/llvm/tools/llvm-shlib/CMakeLists.txt | 26 +- gnu/llvm/llvm/tools/llvm-size/llvm-size.cpp | 36 +- gnu/llvm/llvm/tools/llvm-split/llvm-split.cpp | 6 +- .../llvm/tools/llvm-stress/CMakeLists.txt | 1 - .../llvm/tools/llvm-stress/llvm-stress.cpp | 13 +- .../tools/llvm-symbolizer/llvm-symbolizer.cpp | 72 +- .../llvm/tools/llvm-undname/llvm-undname.cpp | 15 +- gnu/llvm/llvm/tools/llvm-xray/trie-node.h | 2 +- .../tools/llvm-xray/xray-color-helper.cpp | 4 +- .../llvm/tools/llvm-xray/xray-extract.cpp | 16 +- .../llvm/tools/llvm-xray/xray-graph-diff.cpp | 12 +- gnu/llvm/llvm/tools/llvm-xray/xray-graph.cpp | 29 +- gnu/llvm/llvm/tools/llvm-xray/xray-stacks.cpp | 9 +- gnu/llvm/llvm/tools/lto/CMakeLists.txt | 4 +- gnu/llvm/llvm/tools/lto/lto.cpp | 65 +- gnu/llvm/llvm/tools/lto/lto.exports | 1 + gnu/llvm/llvm/tools/obj2yaml/coff2yaml.cpp | 15 +- gnu/llvm/llvm/tools/obj2yaml/dwarf2yaml.cpp | 107 +- gnu/llvm/llvm/tools/obj2yaml/elf2yaml.cpp | 496 +- gnu/llvm/llvm/tools/obj2yaml/macho2yaml.cpp | 122 +- gnu/llvm/llvm/tools/obj2yaml/obj2yaml.cpp | 2 +- gnu/llvm/llvm/tools/obj2yaml/obj2yaml.h | 4 +- gnu/llvm/llvm/tools/obj2yaml/wasm2yaml.cpp | 24 +- gnu/llvm/llvm/tools/opt-viewer/opt-viewer.py | 27 +- gnu/llvm/llvm/tools/opt-viewer/optrecord.py | 7 +- gnu/llvm/llvm/tools/opt/AnalysisWrappers.cpp | 9 +- gnu/llvm/llvm/tools/opt/CMakeLists.txt | 3 +- gnu/llvm/llvm/tools/opt/NewPMDriver.cpp | 135 +- gnu/llvm/llvm/tools/opt/NewPMDriver.h | 8 +- gnu/llvm/llvm/tools/opt/PassPrinters.cpp | 82 +- gnu/llvm/llvm/tools/opt/PassPrinters.h | 17 +- gnu/llvm/llvm/tools/opt/PrintSCC.cpp | 11 +- gnu/llvm/llvm/tools/opt/opt.cpp | 170 +- gnu/llvm/llvm/tools/sancov/CMakeLists.txt | 1 - .../tools/sancov/coverage-report-server.py | 6 +- gnu/llvm/llvm/tools/sancov/sancov.cpp | 23 +- .../vfabi-demangle-fuzzer/CMakeLists.txt | 2 + .../vfabi-demangler-fuzzer.cpp | 17 +- gnu/llvm/llvm/tools/yaml2obj/yaml2obj.cpp | 95 +- gnu/llvm/llvm/unittests/ADT/APFloatTest.cpp | 1214 +- gnu/llvm/llvm/unittests/ADT/APIntTest.cpp | 90 +- gnu/llvm/llvm/unittests/ADT/APSIntTest.cpp | 23 + gnu/llvm/llvm/unittests/ADT/BitFieldsTest.cpp | 256 + gnu/llvm/llvm/unittests/ADT/BitVectorTest.cpp | 110 + gnu/llvm/llvm/unittests/ADT/CMakeLists.txt | 6 +- .../unittests/ADT/CoalescingBitVectorTest.cpp | 561 + gnu/llvm/llvm/unittests/ADT/DenseMapTest.cpp | 24 + gnu/llvm/llvm/unittests/ADT/DenseSetTest.cpp | 11 +- .../llvm/unittests/ADT/FloatingPointMode.cpp | 121 +- .../llvm/unittests/ADT/FunctionExtrasTest.cpp | 38 + .../llvm/unittests/ADT/FunctionRefTest.cpp | 12 +- .../llvm/unittests/ADT/ImmutableMapTest.cpp | 41 + .../llvm/unittests/ADT/IntervalMapTest.cpp | 10 + gnu/llvm/llvm/unittests/ADT/MapVectorTest.cpp | 2 +- .../unittests/ADT/PointerEmbeddedIntTest.cpp | 4 +- .../llvm/unittests/ADT/PointerIntPairTest.cpp | 32 +- gnu/llvm/llvm/unittests/ADT/STLExtrasTest.cpp | 82 +- .../llvm/unittests/ADT/SimpleIListTest.cpp | 26 +- .../llvm/unittests/ADT/SmallPtrSetTest.cpp | 34 +- .../llvm/unittests/ADT/SmallStringTest.cpp | 14 + .../llvm/unittests/ADT/StringExtrasTest.cpp | 93 + gnu/llvm/llvm/unittests/ADT/StringMapTest.cpp | 80 +- gnu/llvm/llvm/unittests/ADT/StringRefTest.cpp | 10 + gnu/llvm/llvm/unittests/ADT/StringSetTest.cpp | 18 +- gnu/llvm/llvm/unittests/ADT/TripleTest.cpp | 64 +- .../llvm/unittests/ADT/TypeSwitchTest.cpp | 88 + .../llvm/unittests/ADT/TypeTraitsTest.cpp | 79 + .../llvm/unittests/ADT/WaymarkingTest.cpp | 142 + .../unittests/Analysis/AliasAnalysisTest.cpp | 9 +- .../Analysis/AliasSetTrackerTest.cpp | 3 +- .../Analysis/AssumeBundleQueriesTest.cpp | 548 + .../Analysis/CGSCCPassManagerTest.cpp | 662 +- .../llvm/unittests/Analysis/CMakeLists.txt | 20 +- .../Analysis/CaptureTrackingTest.cpp | 8 +- gnu/llvm/llvm/unittests/Analysis/DDGTest.cpp | 129 + .../unittests/Analysis/GlobalsModRefTest.cpp | 2 + .../Analysis/InlineFeaturesAnalysisTest.cpp | 77 + .../InlineSizeEstimatorAnalysisTest.cpp | 101 + .../ir2native_x86_64_model/saved_model.pbtxt | 10596 +++++ .../variables/variables.data-00000-of-00001 | Bin 0 -> 88424 bytes .../variables/variables.index | Bin 0 -> 398 bytes .../unittests/Analysis/LazyCallGraphTest.cpp | 106 +- .../llvm/unittests/Analysis/LoadsTest.cpp | 61 + .../llvm/unittests/Analysis/LoopNestTest.cpp | 195 + .../Analysis/ProfileSummaryInfoTest.cpp | 231 +- .../Analysis/ScalarEvolutionTest.cpp | 837 +- .../unittests/Analysis/SparsePropagation.cpp | 12 +- .../llvm/unittests/Analysis/TFUtilsTest.cpp | 98 + .../Analysis/TargetLibraryInfoTest.cpp | 12 + .../unittests/Analysis/UnrollAnalyzerTest.cpp | 1 + .../unittests/Analysis/ValueLatticeTest.cpp | 22 +- .../unittests/Analysis/ValueTrackingTest.cpp | 488 +- .../Analysis/VectorFunctionABITest.cpp | 321 +- .../unittests/Analysis/VectorUtilsTest.cpp | 213 +- .../unittests/AsmParser/AsmParserTest.cpp | 8 +- .../llvm/unittests/BinaryFormat/DwarfTest.cpp | 2 + .../llvm/unittests/BinaryFormat/MachOTest.cpp | 72 + .../BinaryFormat/MsgPackDocumentTest.cpp | 168 +- .../llvm/unittests/Bitcode/BitReaderTest.cpp | 65 + .../CodeGen/AArch64SelectionDAGTest.cpp | 339 +- .../llvm/unittests/CodeGen/CMakeLists.txt | 1 + .../CodeGen/GlobalISel/CMakeLists.txt | 1 + .../unittests/CodeGen/GlobalISel/CSETest.cpp | 41 +- .../GlobalISel/ConstantFoldingTest.cpp | 118 +- .../CodeGen/GlobalISel/GISelMITest.cpp | 76 + .../CodeGen/GlobalISel/GISelMITest.h | 66 +- .../CodeGen/GlobalISel/GISelUtilsTest.cpp | 117 + .../CodeGen/GlobalISel/KnownBitsTest.cpp | 270 +- .../GlobalISel/LegalizerHelperTest.cpp | 1961 +- .../CodeGen/GlobalISel/LegalizerInfoTest.cpp | 1 + .../CodeGen/GlobalISel/LegalizerTest.cpp | 30 +- .../GlobalISel/MachineIRBuilderTest.cpp | 80 +- .../CodeGen/GlobalISel/PatternMatchTest.cpp | 162 +- .../unittests/CodeGen/LexicalScopesTest.cpp | 459 + .../unittests/CodeGen/LowLevelTypeTest.cpp | 49 +- gnu/llvm/llvm/unittests/CodeGen/MFCommon.inc | 135 + .../unittests/CodeGen/MachineInstrTest.cpp | 199 +- .../CodeGen/ScalableVectorMVTsTest.cpp | 2 +- .../CodeView/RandomAccessVisitorTest.cpp | 1 + .../unittests/DebugInfo/DWARF/CMakeLists.txt | 7 + .../DWARF/DWARFAcceleratorTableTest.cpp | 49 + .../DWARF/DWARFDataExtractorTest.cpp | 227 + .../DWARF/DWARFDebugArangeSetTest.cpp | 244 + .../DebugInfo/DWARF/DWARFDebugFrameTest.cpp | 325 + .../DebugInfo/DWARF/DWARFDebugInfoTest.cpp | 179 +- .../DebugInfo/DWARF/DWARFDebugLineTest.cpp | 2570 +- .../DebugInfo/DWARF/DWARFDieTest.cpp | 12 +- .../DWARFExpressionCompactPrinterTest.cpp | 115 + .../DebugInfo/DWARF/DWARFFormValueTest.cpp | 275 + .../DebugInfo/DWARF/DWARFListTableTest.cpp | 76 + .../DebugInfo/DWARF/DwarfGenerator.cpp | 78 +- .../DebugInfo/DWARF/DwarfGenerator.h | 7 +- .../unittests/DebugInfo/GSYM/CMakeLists.txt | 2 + .../unittests/DebugInfo/GSYM/GSYMTest.cpp | 1180 +- .../unittests/DebugInfo/PDB/CMakeLists.txt | 1 + .../DebugInfo/PDB/Inputs/SimpleTest.cpp | 4 + .../DebugInfo/PDB/Inputs/SimpleTest.pdb | Bin 0 -> 94208 bytes .../DebugInfo/PDB/NativeSessionTest.cpp | 99 + .../unittests/DebugInfo/PDB/PDBApiTest.cpp | 12 +- .../ExecutionEngine/Orc/CoreAPIsTest.cpp | 99 +- .../Orc/LazyCallThroughAndReexportsTest.cpp | 10 +- .../Orc/LegacyAPIInteropTest.cpp | 2 +- .../LegacyRTDyldObjectLinkingLayerTest.cpp | 12 +- .../ExecutionEngine/Orc/OrcTestCommon.h | 6 +- .../Orc/RTDyldObjectLinkingLayerTest.cpp | 16 +- .../Orc/RemoteObjectLayerTest.cpp | 27 +- .../llvm/unittests/Frontend/CMakeLists.txt | 4 + .../unittests/Frontend/OpenMPContextTest.cpp | 309 + .../Frontend/OpenMPIRBuilderTest.cpp | 221 +- .../unittests/FuzzMutate/OperationsTest.cpp | 6 +- .../unittests/IR/AbstractCallSiteTest.cpp | 55 + gnu/llvm/llvm/unittests/IR/AttributesTest.cpp | 1 + gnu/llvm/llvm/unittests/IR/BasicBlockTest.cpp | 127 + gnu/llvm/llvm/unittests/IR/CFGBuilder.cpp | 4 +- gnu/llvm/llvm/unittests/IR/CMakeLists.txt | 4 +- .../llvm/unittests/IR/ConstantRangeTest.cpp | 16 + gnu/llvm/llvm/unittests/IR/ConstantsTest.cpp | 57 +- gnu/llvm/llvm/unittests/IR/DebugInfoTest.cpp | 106 + .../unittests/IR/DebugTypeODRUniquingTest.cpp | 45 +- .../llvm/unittests/IR/DominatorTreeTest.cpp | 84 +- gnu/llvm/llvm/unittests/IR/FunctionTest.cpp | 4 +- gnu/llvm/llvm/unittests/IR/IRBuilderTest.cpp | 62 +- .../llvm/unittests/IR/InstructionsTest.cpp | 111 +- .../unittests/IR/LegacyPassManagerTest.cpp | 137 +- gnu/llvm/llvm/unittests/IR/ManglerTest.cpp | 20 + gnu/llvm/llvm/unittests/IR/MetadataTest.cpp | 302 +- gnu/llvm/llvm/unittests/IR/ModuleTest.cpp | 89 +- .../unittests/IR/PassBuilderCallbacksTest.cpp | 6 +- .../llvm/unittests/IR/PassManagerTest.cpp | 60 +- gnu/llvm/llvm/unittests/IR/PatternMatch.cpp | 331 +- .../llvm/unittests/IR/VPIntrinsicTest.cpp | 158 + .../llvm/unittests/IR/ValueHandleTest.cpp | 24 + .../llvm/unittests/IR/VectorTypesTest.cpp | 268 +- gnu/llvm/llvm/unittests/IR/VerifierTest.cpp | 2 +- .../llvm/unittests/MC/AMDGPU/CMakeLists.txt | 11 + .../unittests/MC/AMDGPU/DwarfRegMappings.cpp | 77 + gnu/llvm/llvm/unittests/MC/CMakeLists.txt | 8 + .../llvm/unittests/MC/MCDisassemblerTest.cpp | 49 + .../llvm/unittests/MI/LiveIntervalTest.cpp | 160 +- .../llvm/unittests/Object/ArchiveTest.cpp | 93 + gnu/llvm/llvm/unittests/Object/CMakeLists.txt | 4 + .../unittests/Object/ELFObjectFileTest.cpp | 127 + gnu/llvm/llvm/unittests/Object/ELFTest.cpp | 56 + .../llvm/unittests/Object/ELFTypesTest.cpp | 63 + .../llvm/unittests/ObjectYAML/CMakeLists.txt | 2 + .../unittests/ObjectYAML/DWARFYAMLTest.cpp | 203 + .../llvm/unittests/ObjectYAML/ELFYAMLTest.cpp | 134 + gnu/llvm/llvm/unittests/Passes/CMakeLists.txt | 42 +- .../llvm/unittests/Passes/PluginsTest.cpp | 2 +- .../ProfileData/CoverageMappingTest.cpp | 25 + .../unittests/ProfileData/SampleProfTest.cpp | 143 +- .../unittests/Support/ARMAttributeParser.cpp | 22 +- .../llvm/unittests/Support/AlignmentTest.cpp | 44 +- .../llvm/unittests/Support/AllocatorTest.cpp | 50 +- .../llvm/unittests/Support/Base64Test.cpp | 52 + .../unittests/Support/BinaryStreamTest.cpp | 1 + .../llvm/unittests/Support/CMakeLists.txt | 10 +- .../unittests/Support/CommandLineTest.cpp | 84 +- .../unittests/Support/DataExtractorTest.cpp | 104 +- .../DynamicLibrary/DynamicLibraryTest.cpp | 2 +- .../Support/ELFAttributeParserTest.cpp | 63 + gnu/llvm/llvm/unittests/Support/ErrorTest.cpp | 63 +- .../unittests/Support/ExtensibleRTTITest.cpp | 86 + .../llvm/unittests/Support/FileCheckTest.cpp | 1613 +- .../unittests/Support/FileCollectorTest.cpp | 47 +- .../Support/FileOutputBufferTest.cpp | 15 + .../unittests/Support/FileUtilitiesTest.cpp | 5 +- .../unittests/Support/FormatVariadicTest.cpp | 8 +- gnu/llvm/llvm/unittests/Support/Host.cpp | 36 +- .../unittests/Support/IndexedAccessorTest.cpp | 49 + gnu/llvm/llvm/unittests/Support/JSONTest.cpp | 6 +- .../llvm/unittests/Support/KnownBitsTest.cpp | 45 + .../llvm/unittests/Support/LEB128Test.cpp | 6 + .../llvm/unittests/Support/MathExtrasTest.cpp | 10 - .../unittests/Support/MemoryBufferTest.cpp | 36 + .../Support/OptimizedStructLayoutTest.cpp | 132 + .../llvm/unittests/Support/ParallelTest.cpp | 6 +- gnu/llvm/llvm/unittests/Support/Path.cpp | 412 +- .../llvm/unittests/Support/ProcessTest.cpp | 10 + .../llvm/unittests/Support/ProgramTest.cpp | 25 + .../Support/RISCVAttributeParserTest.cpp | 70 + .../unittests/Support/SpecialCaseListTest.cpp | 4 +- .../llvm/unittests/Support/SuffixTreeTest.cpp | 143 + .../unittests/Support/SwapByteOrderTest.cpp | 10 + .../llvm/unittests/Support/TarWriterTest.cpp | 20 +- .../unittests/Support/TargetParserTest.cpp | 122 +- .../llvm/unittests/Support/TaskQueueTest.cpp | 6 +- .../llvm/unittests/Support/ThreadPool.cpp | 60 +- gnu/llvm/llvm/unittests/Support/Threading.cpp | 3 +- .../unittests/Support/ToolOutputFileTest.cpp | 22 + .../Support/VirtualFileSystemTest.cpp | 199 +- .../llvm/unittests/Support/WithColorTest.cpp | 43 + .../llvm/unittests/Support/YAMLIOTest.cpp | 7 +- .../Support/formatted_raw_ostream_test.cpp | 139 + .../unittests/Support/raw_ostream_test.cpp | 108 +- .../llvm/unittests/TableGen/CMakeLists.txt | 2 +- .../unittests/Target/AArch64/InstSizes.cpp | 5 +- .../unittests/Target/AMDGPU/CMakeLists.txt | 16 + .../Target/AMDGPU/DwarfRegMappings.cpp | 89 + .../unittests/Target/ARM/MachineInstrTest.cpp | 624 +- .../Target/PowerPC/AIXRelocModelTest.cpp | 39 + .../unittests/Target/PowerPC/CMakeLists.txt | 17 + .../llvm/unittests/TextAPI/TextStubHelpers.h | 43 + .../unittests/TextAPI/TextStubV1Tests.cpp | 350 +- .../unittests/TextAPI/TextStubV2Tests.cpp | 348 +- .../unittests/TextAPI/TextStubV3Tests.cpp | 730 +- .../unittests/TextAPI/TextStubV4Tests.cpp | 739 +- .../Transforms/IPO/AttributorTest.cpp | 59 + .../Transforms/IPO/AttributorTestBase.h | 47 + .../unittests/Transforms/IPO/CMakeLists.txt | 6 +- .../Transforms/Scalar/LoopPassManagerTest.cpp | 7 +- .../Transforms/Utils/BasicBlockUtilsTest.cpp | 138 + .../unittests/Transforms/Utils/CMakeLists.txt | 3 + .../Utils/CallPromotionUtilsTest.cpp | 370 + .../Transforms/Utils/CloningTest.cpp | 60 + .../Transforms/Utils/CodeExtractorTest.cpp | 2 +- .../Transforms/Utils/CodeMoverUtilsTest.cpp | 612 +- .../unittests/Transforms/Utils/LocalTest.cpp | 62 +- .../Utils/LoopRotationUtilsTest.cpp | 166 + .../Transforms/Utils/LoopUtilsTest.cpp | 5 + .../Utils/ScalarEvolutionExpanderTest.cpp | 915 + .../Transforms/Utils/UnrollLoopTest.cpp | 5 +- .../Transforms/Vectorize/VPlanHCFGTest.cpp | 71 +- .../Vectorize/VPlanPredicatorTest.cpp | 7 + .../Transforms/Vectorize/VPlanTest.cpp | 161 + .../Transforms/Vectorize/VPlanTestBase.h | 2 + gnu/llvm/llvm/unittests/XRay/GraphTest.cpp | 2 +- .../tools/llvm-cfi-verify/CMakeLists.txt | 1 - .../tools/llvm-exegesis/CMakeLists.txt | 1 + .../llvm-exegesis/Common/AssemblerUtils.h | 4 +- .../Mips/BenchmarkResultTest.cpp | 15 +- .../tools/llvm-exegesis/Mips/CMakeLists.txt | 1 + .../Mips/RegisterAliasingTest.cpp | 74 + .../Mips/SnippetGeneratorTest.cpp | 71 +- .../tools/llvm-exegesis/Mips/TargetTest.cpp | 19 +- .../tools/llvm-exegesis/Mips/TestBase.h | 42 + .../tools/llvm-exegesis/PerfHelperTest.cpp | 23 +- .../llvm-exegesis/SnippetGeneratorTest.cpp | 175 + .../X86/SnippetGeneratorTest.cpp | 77 +- .../X86/SnippetRepetitorTest.cpp | 5 +- .../tools/llvm-exegesis/X86/TargetTest.cpp | 7 + .../tools/llvm-exegesis/X86/TestBase.h | 2 +- gnu/llvm/llvm/utils/FileCheck/FileCheck.cpp | 413 +- .../llvm/utils/LLVMVisualizers/llvm.natvis | 47 + .../llvm/utils/TableGen/AsmMatcherEmitter.cpp | 41 +- .../llvm/utils/TableGen/AsmWriterEmitter.cpp | 123 +- .../llvm/utils/TableGen/AsmWriterInst.cpp | 6 +- gnu/llvm/llvm/utils/TableGen/AsmWriterInst.h | 10 +- gnu/llvm/llvm/utils/TableGen/Attributes.cpp | 124 +- gnu/llvm/llvm/utils/TableGen/CMakeLists.txt | 1 + .../utils/TableGen/CallingConvEmitter.cpp | 15 +- .../llvm/utils/TableGen/CodeEmitterGen.cpp | 4 +- .../utils/TableGen/CodeGenDAGPatterns.cpp | 45 +- .../llvm/utils/TableGen/CodeGenDAGPatterns.h | 7 +- .../llvm/utils/TableGen/CodeGenHwModes.cpp | 2 +- gnu/llvm/llvm/utils/TableGen/CodeGenHwModes.h | 1 + .../utils/TableGen/CodeGenInstruction.cpp | 62 +- .../llvm/utils/TableGen/CodeGenInstruction.h | 1 + .../llvm/utils/TableGen/CodeGenIntrinsics.h | 27 +- .../llvm/utils/TableGen/CodeGenMapTable.cpp | 2 +- .../llvm/utils/TableGen/CodeGenRegisters.cpp | 68 +- .../llvm/utils/TableGen/CodeGenRegisters.h | 17 +- .../llvm/utils/TableGen/CodeGenSchedule.cpp | 40 +- .../llvm/utils/TableGen/CodeGenSchedule.h | 2 +- .../llvm/utils/TableGen/CodeGenTarget.cpp | 70 +- .../utils/TableGen/DAGISelMatcherEmitter.cpp | 35 +- .../llvm/utils/TableGen/DAGISelMatcherGen.cpp | 30 +- gnu/llvm/llvm/utils/TableGen/DFAEmitter.cpp | 10 +- gnu/llvm/llvm/utils/TableGen/DFAEmitter.h | 8 +- .../utils/TableGen/DFAPacketizerEmitter.cpp | 17 +- .../llvm/utils/TableGen/DirectiveEmitter.cpp | 524 + .../utils/TableGen/DisassemblerEmitter.cpp | 8 +- .../llvm/utils/TableGen/ExegesisEmitter.cpp | 2 +- .../llvm/utils/TableGen/FastISelEmitter.cpp | 28 +- .../utils/TableGen/FixedLenDecoderEmitter.cpp | 101 +- .../llvm/utils/TableGen/GICombinerEmitter.cpp | 124 +- .../utils/TableGen/GlobalISel/CMakeLists.txt | 1 + .../utils/TableGen/GlobalISel/GIMatchTree.cpp | 29 +- .../llvm/utils/TableGen/GlobalISelEmitter.cpp | 250 +- .../llvm/utils/TableGen/InstrDocsEmitter.cpp | 2 +- .../llvm/utils/TableGen/InstrInfoEmitter.cpp | 108 +- .../llvm/utils/TableGen/IntrinsicEmitter.cpp | 70 +- .../llvm/utils/TableGen/OptParserEmitter.cpp | 269 +- .../llvm/utils/TableGen/OptRSTEmitter.cpp | 1 + .../TableGen/RISCVCompressInstEmitter.cpp | 87 +- .../utils/TableGen/RegisterBankEmitter.cpp | 31 +- .../utils/TableGen/RegisterInfoEmitter.cpp | 42 +- .../utils/TableGen/SearchableTableEmitter.cpp | 39 +- .../utils/TableGen/SequenceToOffsetTable.h | 100 +- .../llvm/utils/TableGen/SubtargetEmitter.cpp | 13 +- .../utils/TableGen/SubtargetFeatureInfo.cpp | 54 +- gnu/llvm/llvm/utils/TableGen/TableGen.cpp | 26 +- .../llvm/utils/TableGen/TableGenBackends.h | 3 + .../utils/TableGen/X86DisassemblerTables.cpp | 33 +- .../llvm/utils/TableGen/X86ModRMFilters.cpp | 2 + .../llvm/utils/TableGen/X86ModRMFilters.h | 23 + .../utils/TableGen/X86RecognizableInstr.cpp | 53 +- .../utils/TableGen/X86RecognizableInstr.h | 38 +- gnu/llvm/llvm/utils/UpdateTestChecks/asm.py | 23 +- .../llvm/utils/UpdateTestChecks/common.py | 158 +- gnu/llvm/llvm/utils/benchmark/README.LLVM | 6 + .../benchmark/include/benchmark/benchmark.h | 3 +- .../llvm/utils/benchmark/src/cycleclock.h | 44 +- gnu/llvm/llvm/utils/benchmark/src/sysinfo.cc | 5 +- gnu/llvm/llvm/utils/check_ninja_deps.py | 191 + gnu/llvm/llvm/utils/chunk-print-before-all.py | 13 +- .../llvm/utils/clang-parse-diagnostics-file | 4 + .../scripts/llvm_checksum/project_tree.py | 2 +- gnu/llvm/llvm/utils/extract_symbols.py | 11 +- .../llvm/utils/gdb-scripts/prettyprinters.py | 124 + gnu/llvm/llvm/utils/git/arcfilter.sh | 7 + gnu/llvm/llvm/utils/git/pre-push.py | 221 + gnu/llvm/llvm/utils/gn/build/BUILD.gn | 63 + .../llvm/utils/gn/build/libs/zlib/BUILD.gn | 9 +- .../llvm/utils/gn/build/libs/zlib/enable.gni | 9 +- .../llvm/utils/gn/build/symlink_or_copy.gni | 4 +- .../gn/build/sync_source_lists_from_cmake.py | 12 +- .../llvm/utils/gn/build/toolchain/BUILD.gn | 117 +- .../utils/gn/build/write_cmake_config.gni | 8 +- .../llvm/utils/gn/build/write_cmake_config.py | 7 +- .../llvm/utils/gn/build/write_vcsrevision.gni | 16 +- .../llvm/utils/gn/build/write_vcsrevision.py | 53 +- gnu/llvm/llvm/utils/gn/docs/deterministic.md | 18 + gnu/llvm/llvm/utils/gn/get.py | 21 +- gnu/llvm/llvm/utils/gn/gn.py | 4 +- gnu/llvm/llvm/utils/gn/secondary/BUILD.gn | 50 +- .../clang-apply-replacements/BUILD.gn | 1 + .../clang-apply-replacements/tool/BUILD.gn | 1 + .../clang-change-namespace/BUILD.gn | 1 + .../clang-change-namespace/tool/BUILD.gn | 1 + .../clang-tools-extra/clang-doc/tool/BUILD.gn | 1 + .../find-all-symbols/tool/BUILD.gn | 1 + .../clang-include-fixer/plugin/BUILD.gn | 1 + .../clang-include-fixer/tool/BUILD.gn | 1 + .../clang-move/tool/BUILD.gn | 1 + .../clang-query/tool/BUILD.gn | 1 + .../clang-reorder-fields/BUILD.gn | 1 + .../clang-reorder-fields/tool/BUILD.gn | 1 + .../clang-tools-extra/clang-tidy/BUILD.gn | 1 + .../clang-tidy/abseil/BUILD.gn | 1 + .../clang-tidy/bugprone/BUILD.gn | 5 + .../clang-tidy/cert/BUILD.gn | 1 + .../clang-tidy/cppcoreguidelines/BUILD.gn | 1 + .../clang-tidy/fuchsia/BUILD.gn | 1 - .../clang-tidy/llvmlibc/BUILD.gn | 20 + .../clang-tidy/misc/BUILD.gn | 1 + .../clang-tidy/modernize/BUILD.gn | 1 + .../clang-tidy/objc/BUILD.gn | 2 + .../clang-tidy/plugin/BUILD.gn | 1 + .../clang-tidy/portability/BUILD.gn | 1 + .../clang-tidy/readability/BUILD.gn | 1 + .../clang-tidy/tool/BUILD.gn | 2 + .../clang-tidy/utils/BUILD.gn | 4 +- .../clang-tools-extra/clangd/BUILD.gn | 15 +- .../clangd/index/dex/dexp/BUILD.gn | 3 + .../clangd/index/remote/BUILD.gn | 16 + .../index/remote/unimplemented/BUILD.gn | 13 + .../clang-tools-extra/clangd/indexer/BUILD.gn | 1 + .../clangd/refactor/tweaks/BUILD.gn | 2 + .../clang-tools-extra/clangd/support/BUILD.gn | 21 + .../clang-tools-extra/clangd/test/BUILD.gn | 13 +- .../clang-tools-extra/clangd/tool/BUILD.gn | 1 + .../clangd/unittests/BUILD.gn | 21 +- .../clangd/unittests/xpc/BUILD.gn | 1 + .../clang-tools-extra/clangd/xpc/BUILD.gn | 4 + .../clangd/xpc/framework/BUILD.gn | 65 +- .../clangd/xpc/test-client/BUILD.gn | 1 + .../secondary/clang-tools-extra/test/BUILD.gn | 24 +- .../clang-apply-replacements/BUILD.gn | 1 + .../unittests/clang-change-namespace/BUILD.gn | 1 + .../find-all-symbols/BUILD.gn | 1 + .../unittests/clang-move/BUILD.gn | 1 + .../clang/include/clang/Basic/BUILD.gn | 42 +- .../clang/include/clang/Config/BUILD.gn | 3 +- .../utils/gn/secondary/clang/lib/AST/BUILD.gn | 4 +- .../secondary/clang/lib/ASTMatchers/BUILD.gn | 1 + .../clang/lib/ASTMatchers/Dynamic/BUILD.gn | 1 + .../gn/secondary/clang/lib/Basic/BUILD.gn | 10 +- .../gn/secondary/clang/lib/CodeGen/BUILD.gn | 2 + .../gn/secondary/clang/lib/CrossTU/BUILD.gn | 1 + .../gn/secondary/clang/lib/Driver/BUILD.gn | 2 + .../secondary/clang/lib/FrontendTool/BUILD.gn | 1 + .../gn/secondary/clang/lib/Headers/BUILD.gn | 132 +- .../gn/secondary/clang/lib/Sema/BUILD.gn | 5 + .../lib/StaticAnalyzer/Checkers/BUILD.gn | 11 + .../clang/lib/StaticAnalyzer/Core/BUILD.gn | 4 +- .../lib/StaticAnalyzer/Frontend/BUILD.gn | 3 +- .../gn/secondary/clang/lib/Testing/BUILD.gn | 11 + .../clang/lib/Tooling/ASTDiff/BUILD.gn | 1 + .../clang/lib/Tooling/Transformer/BUILD.gn | 1 + .../utils/gn/secondary/clang/test/BUILD.gn | 43 +- .../secondary/clang/tools/arcmt-test/BUILD.gn | 1 + .../clang/tools/c-arcmt-test/BUILD.gn | 5 +- .../clang/tools/clang-check/BUILD.gn | 1 + .../secondary/clang/tools/clang-diff/BUILD.gn | 1 + .../clang/tools/clang-extdef-mapping/BUILD.gn | 1 + .../clang/tools/clang-format/BUILD.gn | 1 + .../clang/tools/clang-import-test/BUILD.gn | 1 + .../tools/clang-offload-bundler/BUILD.gn | 1 + .../tools/clang-offload-wrapper/BUILD.gn | 1 + .../clang/tools/clang-rename/BUILD.gn | 1 + .../clang/tools/clang-scan-deps/BUILD.gn | 1 + .../gn/secondary/clang/tools/driver/BUILD.gn | 11 +- .../secondary/clang/tools/libclang/BUILD.gn | 10 +- .../libclang/include_clang_tools_extra.gni | 5 + .../secondary/clang/tools/scan-build/BUILD.gn | 45 + .../gn/secondary/clang/unittests/AST/BUILD.gn | 6 +- .../clang/unittests/ASTMatchers/BUILD.gn | 2 + .../unittests/ASTMatchers/Dynamic/BUILD.gn | 1 + .../clang/unittests/CrossTU/BUILD.gn | 1 + .../clang/unittests/Frontend/BUILD.gn | 1 + .../secondary/clang/unittests/Index/BUILD.gn | 1 + .../secondary/clang/unittests/Sema/BUILD.gn | 1 + .../clang/unittests/Serialization/BUILD.gn | 1 + .../clang/unittests/StaticAnalyzer/BUILD.gn | 6 +- .../clang/unittests/Tooling/BUILD.gn | 1 + .../clang/unittests/Tooling/Syntax/BUILD.gn | 1 + .../clang/unittests/libclang/BUILD.gn | 5 +- .../unittests/libclang/CrashTests/BUILD.gn | 5 +- .../secondary/clang/utils/TableGen/BUILD.gn | 1 + .../secondary/clang/utils/hmaptool/BUILD.gn | 8 +- .../gn/secondary/compiler-rt/include/BUILD.gn | 4 +- .../gn/secondary/compiler-rt/lib/BUILD.gn | 1 + .../secondary/compiler-rt/lib/asan/BUILD.gn | 203 + .../compiler-rt/lib/builtins/BUILD.gn | 21 +- .../gn/secondary/compiler-rt/lib/cfi/BUILD.gn | 9 +- .../secondary/compiler-rt/lib/hwasan/BUILD.gn | 27 +- .../compiler-rt/lib/interception/BUILD.gn | 4 +- .../secondary/compiler-rt/lib/lsan/BUILD.gn | 42 + .../compiler-rt/lib/profile/BUILD.gn | 2 + .../compiler-rt/lib/sanitizer_common/BUILD.gn | 12 +- .../secondary/compiler-rt/lib/scudo/BUILD.gn | 2 +- .../compiler-rt/lib/scudo/standalone/BUILD.gn | 22 +- .../lib/scudo/standalone/benchmarks/BUILD.gn | 1 + .../lib/scudo/standalone/tests/BUILD.gn | 11 +- .../gn/secondary/compiler-rt/test/BUILD.gn | 2 +- .../compiler-rt/test/hwasan/BUILD.gn | 9 +- .../gn/secondary/libcxx/include/BUILD.gn | 39 +- .../utils/gn/secondary/libcxx/src/BUILD.gn | 30 +- .../utils/gn/secondary/libcxxabi/BUILD.gn | 4 +- .../gn/secondary/libcxxabi/include/BUILD.gn | 4 +- .../utils/gn/secondary/libcxxabi/src/BUILD.gn | 10 +- .../utils/gn/secondary/libunwind/BUILD.gn | 4 +- .../utils/gn/secondary/libunwind/src/BUILD.gn | 34 +- .../llvm/utils/gn/secondary/lld/COFF/BUILD.gn | 1 + .../utils/gn/secondary/lld/Common/BUILD.gn | 20 +- .../utils/gn/secondary/lld/MachO/BUILD.gn | 36 + .../utils/gn/secondary/lld/MinGW/BUILD.gn | 1 + .../secondary/lld/include/lld/Common/BUILD.gn | 10 +- .../gn/secondary/lld/lib/Driver/BUILD.gn | 1 + .../secondary/lld/lib/ReaderWriter/BUILD.gn | 1 + .../lld/lib/ReaderWriter/YAML/BUILD.gn | 1 + .../llvm/utils/gn/secondary/lld/test/BUILD.gn | 17 +- .../utils/gn/secondary/lld/tools/lld/BUILD.gn | 6 +- .../lld/unittests/DriverTests/BUILD.gn | 1 + .../llvm/include/llvm/Config/BUILD.gn | 27 +- .../include/llvm/Frontend/OpenMP/BUILD.gn | 18 + .../llvm/include/llvm/Support/BUILD.gn | 5 +- .../gn/secondary/llvm/lib/Analysis/BUILD.gn | 12 +- .../secondary/llvm/lib/BinaryFormat/BUILD.gn | 5 +- .../llvm/lib/Bitstream/Reader/BUILD.gn | 5 +- .../gn/secondary/llvm/lib/CodeGen/BUILD.gn | 11 +- .../llvm/lib/CodeGen/GlobalISel/BUILD.gn | 2 + .../secondary/llvm/lib/DWARFLinker/BUILD.gn | 1 + .../llvm/lib/DebugInfo/GSYM/BUILD.gn | 2 + .../secondary/llvm/lib/DebugInfo/MSF/BUILD.gn | 4 +- .../secondary/llvm/lib/DebugInfo/PDB/BUILD.gn | 5 + .../llvm/lib/DebugInfo/PDB/enable_dia.gni | 2 +- .../llvm/lib/ExecutionEngine/JITLink/BUILD.gn | 2 + .../llvm/lib/ExecutionEngine/MCJIT/BUILD.gn | 1 + .../llvm/lib/ExecutionEngine/Orc/BUILD.gn | 3 + .../lib/ExecutionEngine/OrcError/BUILD.gn | 4 +- .../gn/secondary/llvm/lib/Extensions/BUILD.gn | 7 + .../llvm/lib/Frontend/OpenMP/BUILD.gn | 17 +- .../utils/gn/secondary/llvm/lib/IR/BUILD.gn | 8 +- .../gn/secondary/llvm/lib/IRReader/BUILD.gn | 1 + .../utils/gn/secondary/llvm/lib/LTO/BUILD.gn | 1 + .../gn/secondary/llvm/lib/LineEditor/BUILD.gn | 1 + .../utils/gn/secondary/llvm/lib/MC/BUILD.gn | 3 + .../secondary/llvm/lib/MC/MCParser/BUILD.gn | 2 + .../gn/secondary/llvm/lib/Option/BUILD.gn | 4 +- .../gn/secondary/llvm/lib/Passes/BUILD.gn | 1 + .../gn/secondary/llvm/lib/Remarks/BUILD.gn | 1 + .../gn/secondary/llvm/lib/Support/BUILD.gn | 10 +- .../gn/secondary/llvm/lib/TableGen/BUILD.gn | 4 +- .../lib/Target/AArch64/AsmParser/BUILD.gn | 1 + .../llvm/lib/Target/AArch64/BUILD.gn | 34 +- .../lib/Target/AArch64/MCTargetDesc/BUILD.gn | 4 +- .../lib/Target/AArch64/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/AArch64/Utils/BUILD.gn | 5 +- .../llvm/lib/Target/AMDGPU/AsmParser/BUILD.gn | 1 + .../secondary/llvm/lib/Target/AMDGPU/BUILD.gn | 38 +- .../lib/Target/AMDGPU/Disassembler/BUILD.gn | 1 + .../lib/Target/AMDGPU/MCTargetDesc/BUILD.gn | 4 +- .../lib/Target/AMDGPU/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/AMDGPU/Utils/BUILD.gn | 4 +- .../llvm/lib/Target/ARM/AsmParser/BUILD.gn | 1 + .../gn/secondary/llvm/lib/Target/ARM/BUILD.gn | 1 + .../llvm/lib/Target/ARM/Disassembler/BUILD.gn | 1 + .../llvm/lib/Target/ARM/MCTargetDesc/BUILD.gn | 4 +- .../llvm/lib/Target/ARM/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/ARM/Utils/BUILD.gn | 5 +- .../llvm/lib/Target/AVR/AsmParser/BUILD.gn | 1 + .../llvm/lib/Target/AVR/Disassembler/BUILD.gn | 1 + .../llvm/lib/Target/AVR/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/BPF/AsmParser/BUILD.gn | 1 + .../gn/secondary/llvm/lib/Target/BPF/BUILD.gn | 1 + .../llvm/lib/Target/BPF/Disassembler/BUILD.gn | 1 + .../llvm/lib/Target/BPF/TargetInfo/BUILD.gn | 5 +- .../gn/secondary/llvm/lib/Target/BUILD.gn | 4 +- .../lib/Target/Hexagon/AsmParser/BUILD.gn | 1 + .../llvm/lib/Target/Hexagon/BUILD.gn | 3 - .../lib/Target/Hexagon/Disassembler/BUILD.gn | 1 + .../lib/Target/Hexagon/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/Lanai/AsmParser/BUILD.gn | 1 + .../lib/Target/Lanai/Disassembler/BUILD.gn | 1 + .../llvm/lib/Target/Lanai/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/Mips/AsmParser/BUILD.gn | 1 + .../lib/Target/Mips/Disassembler/BUILD.gn | 1 + .../lib/Target/Mips/MCTargetDesc/BUILD.gn | 4 +- .../llvm/lib/Target/Mips/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/NVPTX/TargetInfo/BUILD.gn | 5 +- .../lib/Target/PowerPC/AsmParser/BUILD.gn | 1 + .../llvm/lib/Target/PowerPC/BUILD.gn | 1 + .../lib/Target/PowerPC/Disassembler/BUILD.gn | 1 + .../lib/Target/PowerPC/MCTargetDesc/BUILD.gn | 2 +- .../lib/Target/PowerPC/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/RISCV/AsmParser/BUILD.gn | 1 + .../secondary/llvm/lib/Target/RISCV/BUILD.gn | 1 + .../lib/Target/RISCV/Disassembler/BUILD.gn | 1 + .../lib/Target/RISCV/MCTargetDesc/BUILD.gn | 4 +- .../llvm/lib/Target/RISCV/TargetInfo/BUILD.gn | 5 +- .../llvm/lib/Target/RISCV/Utils/BUILD.gn | 4 +- .../llvm/lib/Target/Sparc/AsmParser/BUILD.gn | 1 + .../lib/Target/Sparc/Disassembler/BUILD.gn | 1 + .../llvm/lib/Target/Sparc/TargetInfo/BUILD.gn | 5 +- .../lib/Target/SystemZ/AsmParser/BUILD.gn | 1 + .../llvm/lib/Target/SystemZ/BUILD.gn | 1 + .../lib/Target/SystemZ/Disassembler/BUILD.gn | 1 + .../lib/Target/SystemZ/TargetInfo/BUILD.gn | 5 +- .../lib/Target/WebAssembly/AsmParser/BUILD.gn | 1 + .../llvm/lib/Target/WebAssembly/BUILD.gn | 3 +- .../Target/WebAssembly/Disassembler/BUILD.gn | 1 + .../Target/WebAssembly/MCTargetDesc/BUILD.gn | 7 - .../Target/WebAssembly/TargetInfo/BUILD.gn | 18 +- .../llvm/lib/Target/X86/AsmParser/BUILD.gn | 1 + .../gn/secondary/llvm/lib/Target/X86/BUILD.gn | 9 +- .../llvm/lib/Target/X86/Disassembler/BUILD.gn | 1 + .../llvm/lib/Target/X86/MCTargetDesc/BUILD.gn | 2 +- .../llvm/lib/Target/X86/TargetInfo/BUILD.gn | 5 +- .../gn/secondary/llvm/lib/Target/targets.gni | 9 +- .../lib/ToolDrivers/llvm-dlltool/BUILD.gn | 1 + .../llvm/lib/ToolDrivers/llvm-lib/BUILD.gn | 1 + .../llvm/lib/Transforms/CFGuard/BUILD.gn | 1 + .../llvm/lib/Transforms/Hello/BUILD.gn | 1 + .../llvm/lib/Transforms/IPO/BUILD.gn | 3 + .../llvm/lib/Transforms/InstCombine/BUILD.gn | 1 + .../llvm/lib/Transforms/Utils/BUILD.gn | 8 + .../llvm/lib/Transforms/Vectorize/BUILD.gn | 1 + .../llvm/lib/WindowsManifest/BUILD.gn | 1 + .../utils/gn/secondary/llvm/test/BUILD.gn | 39 +- .../llvm/tools/bugpoint-passes/BUILD.gn | 1 + .../gn/secondary/llvm/tools/dsymutil/BUILD.gn | 2 +- .../gn/secondary/llvm/tools/llc/BUILD.gn | 1 + .../gn/secondary/llvm/tools/lli/BUILD.gn | 1 + .../llvm/tools/lli/ChildTarget/BUILD.gn | 1 + .../gn/secondary/llvm/tools/llvm-ar/BUILD.gn | 5 +- .../gn/secondary/llvm/tools/llvm-as/BUILD.gn | 1 + .../llvm/tools/llvm-bcanalyzer/BUILD.gn | 1 + .../gn/secondary/llvm/tools/llvm-cat/BUILD.gn | 1 + .../llvm/tools/llvm-cfi-verify/BUILD.gn | 1 + .../secondary/llvm/tools/llvm-config/BUILD.gn | 247 +- .../write_extension_dependencies.py | 30 + .../secondary/llvm/tools/llvm-cvtres/BUILD.gn | 1 + .../llvm/tools/llvm-cxxfilt/BUILD.gn | 9 +- .../secondary/llvm/tools/llvm-cxxmap/BUILD.gn | 1 + .../gn/secondary/llvm/tools/llvm-dis/BUILD.gn | 1 + .../llvm/tools/llvm-dwarfdump/BUILD.gn | 1 + .../gn/secondary/llvm/tools/llvm-dwp/BUILD.gn | 8 +- .../llvm/tools/llvm-exegesis/BUILD.gn | 1 + .../tools/llvm-exegesis/lib/AArch64/BUILD.gn | 1 + .../llvm/tools/llvm-exegesis/lib/BUILD.gn | 7 +- .../tools/llvm-exegesis/lib/Mips/BUILD.gn | 1 + .../tools/llvm-exegesis/lib/PowerPC/BUILD.gn | 1 + .../llvm/tools/llvm-exegesis/lib/X86/BUILD.gn | 1 + .../llvm/tools/llvm-extract/BUILD.gn | 1 + .../llvm/tools/llvm-gsymutil/BUILD.gn | 14 + .../gn/secondary/llvm/tools/llvm-ifs/BUILD.gn | 1 + .../llvm/tools/llvm-isel-fuzzer/BUILD.gn | 1 + .../llvm/tools/llvm-jitlink/BUILD.gn | 1 + .../secondary/llvm/tools/llvm-link/BUILD.gn | 1 + .../secondary/llvm/tools/llvm-lipo/BUILD.gn | 1 + .../gn/secondary/llvm/tools/llvm-lto/BUILD.gn | 1 + .../secondary/llvm/tools/llvm-lto2/BUILD.gn | 1 + .../gn/secondary/llvm/tools/llvm-mc/BUILD.gn | 5 +- .../gn/secondary/llvm/tools/llvm-ml/BUILD.gn | 12 + .../llvm/tools/llvm-modextract/BUILD.gn | 1 + .../gn/secondary/llvm/tools/llvm-mt/BUILD.gn | 1 + .../gn/secondary/llvm/tools/llvm-nm/BUILD.gn | 9 +- .../llvm/tools/llvm-objcopy/BUILD.gn | 8 +- .../llvm/tools/llvm-objdump/BUILD.gn | 9 +- .../llvm/tools/llvm-opt-fuzzer/BUILD.gn | 1 + .../llvm/tools/llvm-opt-report/BUILD.gn | 1 + .../llvm/tools/llvm-profdata/BUILD.gn | 1 + .../llvm/tools/llvm-readobj/BUILD.gn | 4 +- .../secondary/llvm/tools/llvm-reduce/BUILD.gn | 2 + .../secondary/llvm/tools/llvm-rtdyld/BUILD.gn | 1 + .../secondary/llvm/tools/llvm-size/BUILD.gn | 9 +- .../secondary/llvm/tools/llvm-split/BUILD.gn | 1 + .../llvm/tools/llvm-strings/BUILD.gn | 9 +- .../llvm/tools/llvm-symbolizer/BUILD.gn | 5 +- .../llvm/tools/llvm-undname/BUILD.gn | 1 + .../gn/secondary/llvm/tools/sancov/BUILD.gn | 1 + .../gn/secondary/llvm/tools/sanstats/BUILD.gn | 1 + .../llvm/tools/verify-uselistorder/BUILD.gn | 1 + .../gn/secondary/llvm/tools/yaml2obj/BUILD.gn | 1 + .../llvm/utils/gn/secondary/llvm/triples.gni | 2 + .../gn/secondary/llvm/unittests/ADT/BUILD.gn | 6 +- .../llvm/unittests/Analysis/BUILD.gn | 9 +- .../llvm/unittests/AsmParser/BUILD.gn | 1 + .../gn/secondary/llvm/unittests/BUILD.gn | 11 +- .../llvm/unittests/BinaryFormat/BUILD.gn | 4 +- .../llvm/unittests/Bitstream/BUILD.gn | 4 +- .../secondary/llvm/unittests/CodeGen/BUILD.gn | 1 + .../unittests/CodeGen/GlobalISel/BUILD.gn | 3 +- .../llvm/unittests/DebugInfo/DWARF/BUILD.gn | 6 + .../llvm/unittests/DebugInfo/GSYM/BUILD.gn | 1 + .../llvm/unittests/DebugInfo/PDB/BUILD.gn | 1 + .../llvm/unittests/Demangle/BUILD.gn | 4 +- .../llvm/unittests/ExecutionEngine/BUILD.gn | 1 + .../ExecutionEngine/JITLink/BUILD.gn | 1 + .../llvm/unittests/Frontend/BUILD.gn | 5 +- .../gn/secondary/llvm/unittests/IR/BUILD.gn | 4 +- .../llvm/unittests/LineEditor/BUILD.gn | 1 + .../secondary/llvm/unittests/Linker/BUILD.gn | 1 + .../llvm/unittests/MC/AMDGPU/BUILD.gn | 15 + .../gn/secondary/llvm/unittests/MC/BUILD.gn | 1 + .../gn/secondary/llvm/unittests/MI/BUILD.gn | 1 + .../secondary/llvm/unittests/Object/BUILD.gn | 4 + .../llvm/unittests/ObjectYAML/BUILD.gn | 2 + .../secondary/llvm/unittests/Option/BUILD.gn | 1 + .../secondary/llvm/unittests/Passes/BUILD.gn | 2 + .../secondary/llvm/unittests/Support/BUILD.gn | 10 +- .../unittests/Support/DynamicLibrary/BUILD.gn | 1 + .../llvm/unittests/Target/AMDGPU/BUILD.gn | 17 + .../llvm/unittests/Target/ARM/BUILD.gn | 1 + .../llvm/unittests/Target/PowerPC/BUILD.gn | 15 + .../unittests/Target/WebAssembly/BUILD.gn | 1 + .../llvm/unittests/Target/X86/BUILD.gn | 1 + .../llvm/unittests/Transforms/IPO/BUILD.gn | 1 + .../llvm/unittests/Transforms/Utils/BUILD.gn | 3 + .../tools/llvm-exegesis/AArch64/BUILD.gn | 1 + .../tools/llvm-exegesis/ARM/BUILD.gn | 1 + .../unittests/tools/llvm-exegesis/BUILD.gn | 1 + .../tools/llvm-exegesis/Mips/BUILD.gn | 1 + .../secondary/llvm/utils/FileCheck/BUILD.gn | 5 +- .../gn/secondary/llvm/utils/TableGen/BUILD.gn | 1 + .../llvm/utils/TableGen/GlobalISel/BUILD.gn | 4 +- .../llvm/utils/TableGen/tablegen.gni | 12 +- .../gn/secondary/llvm/utils/count/BUILD.gn | 1 + .../gn/secondary/llvm/utils/llvm-lit/BUILD.gn | 94 +- .../llvm/utils/llvm-lit/lit_path_function.gni | 4 + .../gn/secondary/llvm/utils/not/BUILD.gn | 5 +- .../gn/secondary/llvm/utils/unittest/BUILD.gn | 4 +- .../llvm/utils/unittest/UnitTestMain/BUILD.gn | 13 +- .../secondary/llvm/utils/yaml-bench/BUILD.gn | 5 +- .../llvm/utils/gn/secondary/llvm/version.gni | 6 +- gnu/llvm/llvm/utils/lint/cpp_lint.py | 2 +- .../llvm/utils/lit/lit/BooleanExpression.py | 11 +- gnu/llvm/llvm/utils/lit/lit/Test.py | 123 +- gnu/llvm/llvm/utils/lit/lit/TestRunner.py | 221 +- gnu/llvm/llvm/utils/lit/lit/TestingConfig.py | 22 +- gnu/llvm/llvm/utils/lit/lit/__init__.py | 3 +- gnu/llvm/llvm/utils/lit/lit/cl_arguments.py | 53 +- gnu/llvm/llvm/utils/lit/lit/display.py | 5 +- .../llvm/utils/lit/lit/formats/googletest.py | 10 +- gnu/llvm/llvm/utils/lit/lit/formats/shtest.py | 9 +- gnu/llvm/llvm/utils/lit/lit/llvm/config.py | 7 +- gnu/llvm/llvm/utils/lit/lit/main.py | 353 +- gnu/llvm/llvm/utils/lit/lit/reports.py | 139 + gnu/llvm/llvm/utils/lit/lit/run.py | 143 +- gnu/llvm/llvm/utils/lit/lit/util.py | 28 +- gnu/llvm/llvm/utils/lit/lit/worker.py | 75 +- gnu/llvm/llvm/utils/lit/setup.py | 2 +- .../does-not-succeed-within-limit.py | 3 + .../lit/tests/Inputs/allow-retries/lit.cfg | 9 + .../more-than-one-allow-retries-lines.py | 4 + .../allow-retries/not-a-valid-integer.py | 3 + .../allow-retries/succeeds-within-limit.py | 24 + .../Inputs/custom-result-category/format.py | 15 + .../Inputs/custom-result-category/lit.cfg | 10 + .../Inputs/custom-result-category/test1.txt | 1 + .../Inputs/custom-result-category/test2.txt | 1 + .../utils/lit/tests/Inputs/discovery/lit.cfg | 6 + .../googletest-discovery-failed/lit.cfg | 3 + .../subdir/OneTest.py | 3 + .../lit/tests/Inputs/max-failures/fail1.txt | 1 + .../lit/tests/Inputs/max-failures/fail2.txt | 1 + .../lit/tests/Inputs/max-failures/fail3.txt | 1 + .../lit/tests/Inputs/max-failures/lit.cfg | 8 +- .../utils/lit/tests/Inputs/max-time/fast.txt | 1 + .../utils/lit/tests/Inputs/max-time/lit.cfg | 7 + .../utils/lit/tests/Inputs/max-time/slow.py | 7 + .../tests/Inputs/parallelism-groups/lit.cfg | 4 + .../tests/Inputs/show-result-codes/fail.txt | 1 + .../tests/Inputs/show-result-codes/lit.cfg | 6 + .../tests/Inputs/show-result-codes/pass.txt | 1 + .../Inputs/show-result-codes/unsupported.txt | 2 + .../tests/Inputs/show-result-codes/xfail.txt | 2 + .../tests/Inputs/show-used-features/lit.cfg | 6 + .../tests/Inputs/show-used-features/mixed.txt | 4 + .../Inputs/show-used-features/requires.txt | 2 + .../Inputs/show-used-features/unsupported.txt | 2 + .../tests/Inputs/show-used-features/xfail.txt | 2 + .../Inputs/shtest-format-argv0/argv0.txt | 6 + .../tests/Inputs/shtest-format-argv0/lit.cfg | 7 + .../lit/tests/Inputs/shtest-inject/lit.cfg | 12 + .../tests/Inputs/shtest-inject/test-empty.txt | 3 + .../tests/Inputs/shtest-inject/test-many.txt | 7 + .../tests/Inputs/shtest-inject/test-one.txt | 5 + .../shtest-keyword-parse-errors/empty.txt | 0 .../shtest-keyword-parse-errors/lit.cfg | 4 + .../multiple-allow-retries.txt | 3 + .../unterminated-run.txt | 3 + .../does-not-substitute-no-limit/lit.cfg | 10 + .../does-not-substitute-no-limit/test.py | 1 + .../does-not-substitute-within-limit/lit.cfg | 12 + .../does-not-substitute-within-limit/test.py | 1 + .../negative-integer/lit.cfg | 8 + .../negative-integer/test.py | 1 + .../not-an-integer/lit.cfg | 8 + .../not-an-integer/test.py | 1 + .../set-to-none/lit.cfg | 8 + .../set-to-none/test.py | 1 + .../substitutes-within-limit/lit.cfg | 12 + .../substitutes-within-limit/test.py | 1 + .../tests/Inputs/test_retry_attempts/lit.cfg | 10 + .../tests/Inputs/test_retry_attempts/test.py | 22 + .../Inputs/testrunner-custom-parsers/test.txt | 3 + .../Inputs/unparsed-requirements/test.py | 4 + .../tests/Inputs/xunit-output/dummy_format.py | 5 + .../tests/Inputs/xunit-output/excluded.ini | 5 + .../Inputs/xunit-output/missing_feature.ini | 7 + .../lit/tests/Inputs/xunit-output/pass.ini | 5 + .../tests/Inputs/xunit-output/unsupported.ini | 5 + .../llvm/utils/lit/tests/allow-retries.py | 41 + .../utils/lit/tests/custom-result-category.py | 15 + gnu/llvm/llvm/utils/lit/tests/discovery.py | 5 + .../lit/tests/googletest-discovery-failed.py | 10 + .../llvm/utils/lit/tests/googletest-format.py | 6 +- .../utils/lit/tests/googletest-timeout.py | 4 +- .../lit/tests/googletest-upstream-format.py | 6 +- gnu/llvm/llvm/utils/lit/tests/lit-opts.py | 4 +- gnu/llvm/llvm/utils/lit/tests/lit.cfg | 4 +- gnu/llvm/llvm/utils/lit/tests/max-failures.py | 26 +- gnu/llvm/llvm/utils/lit/tests/max-time.py | 9 + .../utils/lit/tests/parallelism-groups.py | 5 +- gnu/llvm/llvm/utils/lit/tests/selecting.py | 5 +- .../llvm/utils/lit/tests/show-result-codes.py | 21 + .../utils/lit/tests/show-used-features.py | 6 + gnu/llvm/llvm/utils/lit/tests/shtest-env.py | 4 +- .../utils/lit/tests/shtest-format-argv0.py | 13 + .../llvm/utils/lit/tests/shtest-format.py | 37 +- .../llvm/utils/lit/tests/shtest-inject.py | 48 + .../lit/tests/shtest-keyword-parse-errors.py | 15 + gnu/llvm/llvm/utils/lit/tests/shtest-not.py | 4 +- .../tests/shtest-recursive-substitution.py | 23 + gnu/llvm/llvm/utils/lit/tests/shtest-shell.py | 24 +- .../llvm/utils/lit/tests/shtest-timeout.py | 8 +- .../llvm/utils/lit/tests/unit/TestRunner.py | 122 +- .../utils/lit/tests/unparsed-requirements.py | 25 + gnu/llvm/llvm/utils/lit/tests/usage.py | 9 +- gnu/llvm/llvm/utils/lit/tests/xunit-output.py | 25 +- gnu/llvm/llvm/utils/lldbDataFormatters.py | 4 +- .../llvm/utils/llvm-build/llvmbuild/main.py | 11 +- gnu/llvm/llvm/utils/llvm-gisel-cov.py | 8 +- gnu/llvm/llvm/utils/llvm-lit/CMakeLists.txt | 25 +- gnu/llvm/llvm/utils/llvm-lit/llvm-lit.in | 13 +- .../llvm/utils/llvm-locstats/llvm-locstats.py | 176 +- .../llvm/utils/release/build_llvm_package.bat | 6 +- gnu/llvm/llvm/utils/release/export.sh | 34 +- gnu/llvm/llvm/utils/release/test-release.sh | 15 +- .../googlemock/include/gmock/gmock-matchers.h | 20 +- .../gtest/internal/custom/raw-ostream.h | 3 +- .../include/gtest/internal/gtest-port.h | 2 +- .../llvm/utils/update_analyze_test_checks.py | 6 +- gnu/llvm/llvm/utils/update_cc_test_checks.py | 118 +- gnu/llvm/llvm/utils/update_llc_test_checks.py | 68 +- gnu/llvm/llvm/utils/update_test_checks.py | 80 +- gnu/llvm/llvm/utils/vim/syntax/llvm.vim | 5 +- gnu/llvm/llvm/utils/vim/syntax/tablegen.vim | 2 +- gnu/llvm/llvm/utils/vim/vimrc | 2 +- gnu/llvm/llvm/utils/vscode/README | 20 +- gnu/llvm/llvm/utils/vscode/llvm/.vscodeignore | 7 + gnu/llvm/llvm/utils/vscode/llvm/CHANGELOG.md | 9 + gnu/llvm/llvm/utils/vscode/llvm/README.md | 46 + .../llvm/language-configuration-tablegen.json | 30 + .../vscode/llvm/language-configuration.json | 26 + .../llvm/utils/vscode/llvm/package-lock.json | 323 + gnu/llvm/llvm/utils/vscode/llvm/package.json | 122 + .../llvm/utils/vscode/llvm/src/extension.ts | 15 + .../utils/vscode/llvm/src/litTaskProvider.ts | 79 + .../vscode/llvm/syntaxes/TableGen.tmLanguage | 132 + .../vscode/llvm/syntaxes/ll.tmLanguage.yaml | 331 + gnu/llvm/llvm/utils/vscode/llvm/tsconfig.json | 20 + .../vscode/llvm/vsc-extension-quickstart.md | 29 + 4212 files changed, 380316 insertions(+), 132370 deletions(-) create mode 100644 gnu/llvm/llvm/.gitattributes create mode 100644 gnu/llvm/llvm/.gitignore create mode 100644 gnu/llvm/llvm/cmake/modules/FindGRPC.cmake create mode 100644 gnu/llvm/llvm/cmake/modules/TensorFlowCompile.cmake create mode 100644 gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX1011.rst create mode 100644 gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_0.rst create mode 100644 gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_1.rst create mode 100644 gnu/llvm/llvm/docs/AMDGPU/gfx1011_type_dev.rst create mode 100644 gnu/llvm/llvm/docs/AMDGPU/gfx1011_vdst32_0.rst create mode 100644 gnu/llvm/llvm/docs/AMDGPU/gfx1011_vsrc32_0.rst create mode 100644 gnu/llvm/llvm/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.rst create mode 100644 gnu/llvm/llvm/docs/CodeReview.rst create mode 100644 gnu/llvm/llvm/docs/CommandGuide/locstats-compare.png create mode 100644 gnu/llvm/llvm/docs/GitBisecting.rst create mode 100644 gnu/llvm/llvm/docs/HowToUpdateDebugInfo.rst create mode 100644 gnu/llvm/llvm/docs/Proposals/VectorPredication.rst create mode 100644 gnu/llvm/llvm/docs/Security.rst create mode 100644 gnu/llvm/llvm/docs/loop-terminology-guarded-loop.png create mode 100644 gnu/llvm/llvm/docs/loop-terminology-initial-loop.png create mode 100644 gnu/llvm/llvm/docs/loop-terminology-rotated-loop.png create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/ExampleModules.h create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITDumpObjects/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITDumpObjects/LLJITDumpObjects.cpp create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer/LLJITWithCustomObjectLinkingLayer.cpp create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener/LLJITWithGDBRegistrationListener.cpp create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithInitializers/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithInitializers/LLJITWithInitializers.cpp create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithLazyReexports/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithLazyReexports/LLJITWithLazyReexports.cpp create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectCache/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectCache/LLJITWithObjectCache.cpp create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/OrcV2CBindingsAddObjectFile.c create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/OrcV2CBindingsBasicUsage.c create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/OrcV2CBindingsReflectProcessSymbols.c create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/CMakeLists.txt create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.cpp create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.h create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.cpp create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.h create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoJIT.cpp create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoJIT.h create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoModuleIndex.cpp create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoModuleIndex.h create mode 100755 gnu/llvm/llvm/examples/ThinLtoJIT/bench create mode 100644 gnu/llvm/llvm/examples/ThinLtoJIT/main.cpp create mode 100644 gnu/llvm/llvm/include/llvm-c/Orc.h create mode 100644 gnu/llvm/llvm/include/llvm/ADT/Bitfields.h create mode 100644 gnu/llvm/llvm/include/llvm/ADT/CoalescingBitVector.h create mode 100644 gnu/llvm/llvm/include/llvm/ADT/StringMapEntry.h create mode 100644 gnu/llvm/llvm/include/llvm/ADT/TypeSwitch.h create mode 100644 gnu/llvm/llvm/include/llvm/ADT/Waymarking.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/AssumeBundleQueries.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/HeatUtils.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/InlineAdvisor.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/InlineFeaturesAnalysis.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/InlineModelFeatureMaps.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/InlineSizeEstimatorAnalysis.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/LoopNestAnalysis.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/MLInlineAdvisor.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/MLModelRunner.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/ScalarEvolutionDivision.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/StackLifetime.h create mode 100644 gnu/llvm/llvm/include/llvm/Analysis/Utils/TFUtils.h create mode 100644 gnu/llvm/llvm/include/llvm/BinaryFormat/ELFRelocs/VE.def create mode 100644 gnu/llvm/llvm/include/llvm/CodeGen/AntiDepBreaker.h create mode 100644 gnu/llvm/llvm/include/llvm/CodeGen/CommandFlags.h create mode 100644 gnu/llvm/llvm/include/llvm/CodeGen/GlobalISel/InlineAsmLowering.h create mode 100644 gnu/llvm/llvm/include/llvm/CodeGen/GlobalISel/LostDebugLocObserver.h create mode 100644 gnu/llvm/llvm/include/llvm/CodeGen/IndirectThunks.h create mode 100644 gnu/llvm/llvm/include/llvm/CodeGen/LiveIntervalCalc.h create mode 100644 gnu/llvm/llvm/include/llvm/CodeGen/MBFIWrapper.h create mode 100644 gnu/llvm/llvm/include/llvm/CodeGen/Spiller.h create mode 100644 gnu/llvm/llvm/include/llvm/DWARFLinker/DWARFStreamer.h create mode 100644 gnu/llvm/llvm/include/llvm/DebugInfo/GSYM/DwarfTransformer.h create mode 100644 gnu/llvm/llvm/include/llvm/DebugInfo/GSYM/ObjectFileTransformer.h create mode 100644 gnu/llvm/llvm/include/llvm/DebugInfo/PDB/Native/NativeEnumLineNumbers.h create mode 100644 gnu/llvm/llvm/include/llvm/DebugInfo/PDB/Native/NativeFunctionSymbol.h create mode 100644 gnu/llvm/llvm/include/llvm/DebugInfo/PDB/Native/NativeLineNumber.h create mode 100644 gnu/llvm/llvm/include/llvm/DebugInfo/PDB/Native/NativePublicSymbol.h create mode 100644 gnu/llvm/llvm/include/llvm/DebugInfo/PDB/Native/NativeSourceFile.h create mode 100644 gnu/llvm/llvm/include/llvm/ExecutionEngine/JITLink/ELF.h create mode 100644 gnu/llvm/llvm/include/llvm/ExecutionEngine/JITLink/ELF_x86_64.h create mode 100644 gnu/llvm/llvm/include/llvm/ExecutionEngine/Orc/MachOPlatform.h create mode 100644 gnu/llvm/llvm/include/llvm/ExecutionEngine/Orc/Mangling.h create mode 100644 gnu/llvm/llvm/include/llvm/Frontend/CMakeLists.txt create mode 100644 gnu/llvm/llvm/include/llvm/Frontend/Directive/DirectiveBase.td create mode 100644 gnu/llvm/llvm/include/llvm/Frontend/OpenACC/ACC.td create mode 100644 gnu/llvm/llvm/include/llvm/Frontend/OpenACC/CMakeLists.txt create mode 100644 gnu/llvm/llvm/include/llvm/Frontend/OpenMP/CMakeLists.txt create mode 100644 gnu/llvm/llvm/include/llvm/Frontend/OpenMP/OMP.td create mode 100644 gnu/llvm/llvm/include/llvm/Frontend/OpenMP/OMPContext.h create mode 100644 gnu/llvm/llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h create mode 100644 gnu/llvm/llvm/include/llvm/IR/AbstractCallSite.h create mode 100644 gnu/llvm/llvm/include/llvm/IR/IRBuilderFolder.h create mode 100644 gnu/llvm/llvm/include/llvm/IR/IntrinsicsHexagonDep.td create mode 100644 gnu/llvm/llvm/include/llvm/IR/LLVMRemarkStreamer.h create mode 100644 gnu/llvm/llvm/include/llvm/IR/MatrixBuilder.h create mode 100644 gnu/llvm/llvm/include/llvm/IR/PassManagerImpl.h create mode 100644 gnu/llvm/llvm/include/llvm/IR/VPIntrinsics.def create mode 100644 gnu/llvm/llvm/include/llvm/MC/MCTargetOptionsCommandFlags.h create mode 100644 gnu/llvm/llvm/include/llvm/Remarks/RemarkStreamer.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/AllocatorBase.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/Base64.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/CFGDiff.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/ELFAttributeParser.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/ELFAttributes.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/ExtensibleRTTI.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/OptimizedStructLayout.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/RISCVAttributeParser.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/RISCVAttributes.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/RISCVTargetParser.def create mode 100644 gnu/llvm/llvm/include/llvm/Support/SuffixTree.h create mode 100644 gnu/llvm/llvm/include/llvm/Support/X86TargetParser.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Coroutines/CoroCleanup.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Coroutines/CoroEarly.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Coroutines/CoroElide.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Coroutines/CoroSplit.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/IPO/OpenMPOpt.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Instrumentation/AddressSanitizerCommon.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Utils/AMDGPUEmitPrintf.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Utils/AssumeBundleBuilder.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Utils/CallGraphUpdater.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Utils/CanonicalizeFreezeInLoops.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Utils/ScalarEvolutionExpander.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Utils/UniqueInternalLinkageNames.h create mode 100644 gnu/llvm/llvm/include/llvm/Transforms/Vectorize/VectorCombine.h create mode 100644 gnu/llvm/llvm/lib/Analysis/AssumeBundleQueries.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/HeatUtils.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/InlineAdvisor.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/InlineFeaturesAnalysis.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/InlineSizeEstimatorAnalysis.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/LoopNestAnalysis.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/MLInlineAdvisor.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/ReleaseModeModelRunner.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/ScalarEvolutionDivision.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/StackLifetime.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/TFUtils.cpp create mode 100644 gnu/llvm/llvm/lib/Analysis/models/inliner/saved_model.pbtxt create mode 100644 gnu/llvm/llvm/lib/Analysis/models/inliner/variables/variables.data-00000-of-00001 create mode 100644 gnu/llvm/llvm/lib/Analysis/models/inliner/variables/variables.index create mode 100644 gnu/llvm/llvm/lib/BinaryFormat/MachO.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/BBSectionsPrepare.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/CommandFlags.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/FixupStatepointCallerSaved.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/GlobalISel/InlineAsmLowering.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/GlobalISel/LostDebugLocObserver.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/LiveIntervalCalc.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/MBFIWrapper.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/MachineDebugify.cpp create mode 100644 gnu/llvm/llvm/lib/CodeGen/MachineStripDebug.cpp create mode 100644 gnu/llvm/llvm/lib/DWARFLinker/DWARFStreamer.cpp create mode 100644 gnu/llvm/llvm/lib/DebugInfo/GSYM/DwarfTransformer.cpp create mode 100644 gnu/llvm/llvm/lib/DebugInfo/GSYM/ObjectFileTransformer.cpp create mode 100644 gnu/llvm/llvm/lib/DebugInfo/PDB/Native/NativeEnumLineNumbers.cpp create mode 100644 gnu/llvm/llvm/lib/DebugInfo/PDB/Native/NativeFunctionSymbol.cpp create mode 100644 gnu/llvm/llvm/lib/DebugInfo/PDB/Native/NativeLineNumber.cpp create mode 100644 gnu/llvm/llvm/lib/DebugInfo/PDB/Native/NativePublicSymbol.cpp create mode 100644 gnu/llvm/llvm/lib/DebugInfo/PDB/Native/NativeSourceFile.cpp create mode 100644 gnu/llvm/llvm/lib/ExecutionEngine/JITLink/ELF.cpp create mode 100644 gnu/llvm/llvm/lib/ExecutionEngine/JITLink/ELF_x86_64.cpp create mode 100644 gnu/llvm/llvm/lib/ExecutionEngine/Orc/MachOPlatform.cpp create mode 100644 gnu/llvm/llvm/lib/ExecutionEngine/Orc/Mangling.cpp create mode 100644 gnu/llvm/llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp create mode 100644 gnu/llvm/llvm/lib/Frontend/OpenACC/CMakeLists.txt create mode 100644 gnu/llvm/llvm/lib/Frontend/OpenMP/OMPContext.cpp create mode 100644 gnu/llvm/llvm/lib/IR/LLVMRemarkStreamer.cpp create mode 100644 gnu/llvm/llvm/lib/MC/MCInstrInfo.cpp create mode 100644 gnu/llvm/llvm/lib/MC/MCParser/COFFMasmParser.cpp create mode 100644 gnu/llvm/llvm/lib/MC/MCParser/MasmParser.cpp create mode 100644 gnu/llvm/llvm/lib/MC/MCSymbolXCOFF.cpp create mode 100644 gnu/llvm/llvm/lib/MC/MCTargetOptionsCommandFlags.cpp create mode 100644 gnu/llvm/llvm/lib/Remarks/RemarkStreamer.cpp create mode 100644 gnu/llvm/llvm/lib/Support/ELFAttributeParser.cpp create mode 100644 gnu/llvm/llvm/lib/Support/ELFAttributes.cpp create mode 100644 gnu/llvm/llvm/lib/Support/ExtensibleRTTI.cpp create mode 100644 gnu/llvm/llvm/lib/Support/MemAlloc.cpp create mode 100644 gnu/llvm/llvm/lib/Support/OptimizedStructLayout.cpp create mode 100644 gnu/llvm/llvm/lib/Support/RISCVAttributeParser.cpp create mode 100644 gnu/llvm/llvm/lib/Support/RISCVAttributes.cpp create mode 100644 gnu/llvm/llvm/lib/Support/SuffixTree.cpp create mode 100644 gnu/llvm/llvm/lib/Support/X86TargetParser.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/AArch64InstrGISel.td create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/AArch64MachineFunctionInfo.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/AArch64SLSHardening.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64CallLowering.h create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64InstructionSelector.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.h create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64PostLegalizerCombiner.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64PreLegalizerCombiner.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.h create mode 100644 gnu/llvm/llvm/lib/Target/AArch64/SVEIntrinsicOpts.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/AMDGPUCombine.td create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/AMDGPUExportClustering.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/AMDGPUExportClustering.h create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/AMDGPUPostLegalizerCombiner.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/AMDGPUPreLegalizerCombiner.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/AMDGPURegBankCombiner.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/SIInsertHardClauses.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/SIPostRABundler.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/SIPreEmitPeephole.cpp create mode 100644 gnu/llvm/llvm/lib/Target/AMDGPU/SIRemoveShortExecBranches.cpp create mode 100644 gnu/llvm/llvm/lib/Target/ARM/ARMInstrCDE.td create mode 100644 gnu/llvm/llvm/lib/Target/ARM/MVEVPTOptimisationsPass.cpp create mode 100644 gnu/llvm/llvm/lib/Target/BPF/BPFPreserveDIType.cpp create mode 100644 gnu/llvm/llvm/lib/Target/Hexagon/HexagonArch.h create mode 100644 gnu/llvm/llvm/lib/Target/Hexagon/HexagonDepMask.h create mode 100644 gnu/llvm/llvm/lib/Target/Hexagon/HexagonScheduleV67.td create mode 100644 gnu/llvm/llvm/lib/Target/Hexagon/HexagonScheduleV67T.td create mode 100644 gnu/llvm/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFStreamer.cpp create mode 100644 gnu/llvm/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFStreamer.h create mode 100644 gnu/llvm/llvm/lib/Target/PowerPC/PPCInstrPrefix.td create mode 100644 gnu/llvm/llvm/lib/Target/PowerPC/PPCMacroFusion.cpp create mode 100644 gnu/llvm/llvm/lib/Target/PowerPC/PPCMacroFusion.def create mode 100644 gnu/llvm/llvm/lib/Target/PowerPC/PPCMacroFusion.h create mode 100644 gnu/llvm/llvm/lib/Target/RISCV/RISCVExpandAtomicPseudoInsts.cpp create mode 100644 gnu/llvm/llvm/lib/Target/RISCV/RISCVISelDAGToDAG.h create mode 100644 gnu/llvm/llvm/lib/Target/RISCV/RISCVInstrFormatsV.td create mode 100644 gnu/llvm/llvm/lib/Target/RISCV/RISCVInstrInfoB.td create mode 100644 gnu/llvm/llvm/lib/Target/RISCV/RISCVInstrInfoV.td create mode 100644 gnu/llvm/llvm/lib/Target/SystemZ/SystemZCopyPhysRegs.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/AsmParser/CMakeLists.txt create mode 100644 gnu/llvm/llvm/lib/Target/VE/AsmParser/LLVMBuild.txt create mode 100644 gnu/llvm/llvm/lib/Target/VE/AsmParser/VEAsmParser.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/Disassembler/CMakeLists.txt create mode 100644 gnu/llvm/llvm/lib/Target/VE/Disassembler/LLVMBuild.txt create mode 100644 gnu/llvm/llvm/lib/Target/VE/Disassembler/VEDisassembler.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/MCTargetDesc/VEAsmBackend.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/MCTargetDesc/VEELFObjectWriter.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/MCTargetDesc/VEFixupKinds.h create mode 100644 gnu/llvm/llvm/lib/Target/VE/MCTargetDesc/VEInstPrinter.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/MCTargetDesc/VEInstPrinter.h create mode 100644 gnu/llvm/llvm/lib/Target/VE/MCTargetDesc/VEMCCodeEmitter.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/MCTargetDesc/VEMCExpr.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/MCTargetDesc/VEMCExpr.h create mode 100644 gnu/llvm/llvm/lib/Target/VE/TargetInfo/VETargetInfo.h create mode 100644 gnu/llvm/llvm/lib/Target/VE/VEMachineFunctionInfo.cpp create mode 100644 gnu/llvm/llvm/lib/Target/VE/VEMachineFunctionInfo.h create mode 100644 gnu/llvm/llvm/lib/Target/WebAssembly/WebAssemblyDebugFixup.cpp create mode 100644 gnu/llvm/llvm/lib/Target/WebAssembly/WebAssemblyFixBrTableDefaults.cpp create mode 100644 gnu/llvm/llvm/lib/Target/X86/MCTargetDesc/X86ShuffleDecode.cpp create mode 100644 gnu/llvm/llvm/lib/Target/X86/MCTargetDesc/X86ShuffleDecode.h create mode 100644 gnu/llvm/llvm/lib/Target/X86/X86InsertWait.cpp create mode 100644 gnu/llvm/llvm/lib/Target/X86/X86InstrAMX.td create mode 100644 gnu/llvm/llvm/lib/Target/X86/X86PartialReduction.cpp create mode 100644 gnu/llvm/llvm/lib/Target/X86/X86SpeculativeExecutionSideEffectSuppression.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/IPO/AttributorAttributes.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/IPO/OpenMPOpt.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/InstCombine/InstCombineNegator.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Utils/AMDGPUEmitPrintf.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Utils/AssumeBundleBuilder.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Utils/CallGraphUpdater.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Utils/CanonicalizeFreezeInLoops.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Utils/FixIrreducible.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Utils/UnifyLoopExits.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp create mode 100644 gnu/llvm/llvm/lib/Transforms/Vectorize/VectorCombine.cpp create mode 100644 gnu/llvm/llvm/tools/dsymutil/Reproducer.cpp create mode 100644 gnu/llvm/llvm/tools/dsymutil/Reproducer.h create mode 100644 gnu/llvm/llvm/tools/llvm-dwarfdump/SectionSizes.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.h create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/Error.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/LatencyBenchmarkRunner.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/LatencyBenchmarkRunner.h create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/ParallelSnippetGenerator.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/ParallelSnippetGenerator.h create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/SerialSnippetGenerator.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/SerialSnippetGenerator.h create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/UopsBenchmarkRunner.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-exegesis/lib/UopsBenchmarkRunner.h create mode 100644 gnu/llvm/llvm/tools/llvm-gsymutil/CMakeLists.txt create mode 100644 gnu/llvm/llvm/tools/llvm-gsymutil/llvm-gsymutil.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-jitlink/llvm-jitlink-elf.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-ml/CMakeLists.txt create mode 100644 gnu/llvm/llvm/tools/llvm-ml/Disassembler.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-ml/Disassembler.h create mode 100644 gnu/llvm/llvm/tools/llvm-ml/llvm-ml.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-objcopy/wasm/Object.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-objcopy/wasm/Object.h create mode 100644 gnu/llvm/llvm/tools/llvm-objcopy/wasm/Reader.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-objcopy/wasm/Reader.h create mode 100644 gnu/llvm/llvm/tools/llvm-objcopy/wasm/WasmObjcopy.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-objcopy/wasm/WasmObjcopy.h create mode 100644 gnu/llvm/llvm/tools/llvm-objcopy/wasm/Writer.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-objcopy/wasm/Writer.h create mode 100644 gnu/llvm/llvm/tools/llvm-objdump/COFFDump.h create mode 100644 gnu/llvm/llvm/tools/llvm-objdump/ELFDump.h create mode 100644 gnu/llvm/llvm/tools/llvm-objdump/MachODump.h create mode 100644 gnu/llvm/llvm/tools/llvm-objdump/WasmDump.h create mode 100644 gnu/llvm/llvm/tools/llvm-objdump/XCOFFDump.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-objdump/XCOFFDump.h create mode 100644 gnu/llvm/llvm/tools/llvm-reduce/deltas/ReduceAttributes.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-reduce/deltas/ReduceAttributes.h create mode 100644 gnu/llvm/llvm/tools/llvm-reduce/deltas/ReduceOperandBundles.cpp create mode 100644 gnu/llvm/llvm/tools/llvm-reduce/deltas/ReduceOperandBundles.h create mode 100644 gnu/llvm/llvm/unittests/ADT/BitFieldsTest.cpp create mode 100644 gnu/llvm/llvm/unittests/ADT/CoalescingBitVectorTest.cpp create mode 100644 gnu/llvm/llvm/unittests/ADT/TypeSwitchTest.cpp create mode 100644 gnu/llvm/llvm/unittests/ADT/TypeTraitsTest.cpp create mode 100644 gnu/llvm/llvm/unittests/ADT/WaymarkingTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Analysis/AssumeBundleQueriesTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Analysis/DDGTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Analysis/InlineFeaturesAnalysisTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Analysis/InlineSizeEstimatorAnalysisTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Analysis/Inputs/ir2native_x86_64_model/saved_model.pbtxt create mode 100644 gnu/llvm/llvm/unittests/Analysis/Inputs/ir2native_x86_64_model/variables/variables.data-00000-of-00001 create mode 100644 gnu/llvm/llvm/unittests/Analysis/Inputs/ir2native_x86_64_model/variables/variables.index create mode 100644 gnu/llvm/llvm/unittests/Analysis/LoadsTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Analysis/LoopNestTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Analysis/TFUtilsTest.cpp create mode 100644 gnu/llvm/llvm/unittests/CodeGen/GlobalISel/GISelUtilsTest.cpp create mode 100644 gnu/llvm/llvm/unittests/CodeGen/LexicalScopesTest.cpp create mode 100644 gnu/llvm/llvm/unittests/CodeGen/MFCommon.inc create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/DWARF/DWARFAcceleratorTableTest.cpp create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/DWARF/DWARFDataExtractorTest.cpp create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/DWARF/DWARFDebugArangeSetTest.cpp create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/DWARF/DWARFDebugFrameTest.cpp create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/DWARF/DWARFExpressionCompactPrinterTest.cpp create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/DWARF/DWARFListTableTest.cpp create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/PDB/Inputs/SimpleTest.cpp create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/PDB/Inputs/SimpleTest.pdb create mode 100644 gnu/llvm/llvm/unittests/DebugInfo/PDB/NativeSessionTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Frontend/OpenMPContextTest.cpp create mode 100644 gnu/llvm/llvm/unittests/IR/AbstractCallSiteTest.cpp create mode 100644 gnu/llvm/llvm/unittests/IR/VPIntrinsicTest.cpp create mode 100644 gnu/llvm/llvm/unittests/MC/AMDGPU/CMakeLists.txt create mode 100644 gnu/llvm/llvm/unittests/MC/AMDGPU/DwarfRegMappings.cpp create mode 100644 gnu/llvm/llvm/unittests/MC/MCDisassemblerTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Object/ArchiveTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Object/ELFObjectFileTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Object/ELFTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Object/ELFTypesTest.cpp create mode 100644 gnu/llvm/llvm/unittests/ObjectYAML/DWARFYAMLTest.cpp create mode 100644 gnu/llvm/llvm/unittests/ObjectYAML/ELFYAMLTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/Base64Test.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/ELFAttributeParserTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/ExtensibleRTTITest.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/IndexedAccessorTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/OptimizedStructLayoutTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/RISCVAttributeParserTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/SuffixTreeTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/ToolOutputFileTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Support/WithColorTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Target/AMDGPU/CMakeLists.txt create mode 100644 gnu/llvm/llvm/unittests/Target/AMDGPU/DwarfRegMappings.cpp create mode 100644 gnu/llvm/llvm/unittests/Target/PowerPC/AIXRelocModelTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Target/PowerPC/CMakeLists.txt create mode 100644 gnu/llvm/llvm/unittests/TextAPI/TextStubHelpers.h create mode 100644 gnu/llvm/llvm/unittests/Transforms/IPO/AttributorTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Transforms/IPO/AttributorTestBase.h create mode 100644 gnu/llvm/llvm/unittests/Transforms/Utils/CallPromotionUtilsTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Transforms/Utils/LoopRotationUtilsTest.cpp create mode 100644 gnu/llvm/llvm/unittests/Transforms/Utils/ScalarEvolutionExpanderTest.cpp create mode 100644 gnu/llvm/llvm/unittests/tools/llvm-exegesis/Mips/RegisterAliasingTest.cpp create mode 100644 gnu/llvm/llvm/unittests/tools/llvm-exegesis/Mips/TestBase.h create mode 100644 gnu/llvm/llvm/unittests/tools/llvm-exegesis/SnippetGeneratorTest.cpp create mode 100644 gnu/llvm/llvm/utils/TableGen/DirectiveEmitter.cpp create mode 100755 gnu/llvm/llvm/utils/check_ninja_deps.py create mode 100755 gnu/llvm/llvm/utils/git/arcfilter.sh create mode 100755 gnu/llvm/llvm/utils/git/pre-push.py create mode 100644 gnu/llvm/llvm/utils/gn/docs/deterministic.md create mode 100644 gnu/llvm/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/llvmlibc/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/clang-tools-extra/clangd/index/remote/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/clang-tools-extra/clangd/index/remote/unimplemented/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/clang-tools-extra/clangd/support/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/clang/lib/Testing/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/clang/tools/libclang/include_clang_tools_extra.gni create mode 100644 gnu/llvm/llvm/utils/gn/secondary/clang/tools/scan-build/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/compiler-rt/lib/asan/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/compiler-rt/lib/lsan/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/lld/MachO/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/include/llvm/Frontend/OpenMP/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/lib/Extensions/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/tools/llvm-config/write_extension_dependencies.py create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/tools/llvm-gsymutil/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/tools/llvm-ml/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/unittests/MC/AMDGPU/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/unittests/Target/AMDGPU/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/unittests/Target/PowerPC/BUILD.gn create mode 100644 gnu/llvm/llvm/utils/gn/secondary/llvm/utils/llvm-lit/lit_path_function.gni create mode 100755 gnu/llvm/llvm/utils/lit/lit/reports.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/allow-retries/does-not-succeed-within-limit.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/allow-retries/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/allow-retries/more-than-one-allow-retries-lines.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/allow-retries/not-a-valid-integer.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/allow-retries/succeeds-within-limit.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/custom-result-category/format.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/custom-result-category/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/custom-result-category/test1.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/custom-result-category/test2.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/googletest-discovery-failed/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/googletest-discovery-failed/subdir/OneTest.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/max-failures/fail1.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/max-failures/fail2.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/max-failures/fail3.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/max-time/fast.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/max-time/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/max-time/slow.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-result-codes/fail.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-result-codes/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-result-codes/pass.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-result-codes/unsupported.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-result-codes/xfail.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-used-features/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-used-features/mixed.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-used-features/requires.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-used-features/unsupported.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/show-used-features/xfail.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-format-argv0/argv0.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-format-argv0/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-inject/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-inject/test-empty.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-inject/test-many.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-inject/test-one.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-keyword-parse-errors/empty.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-keyword-parse-errors/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-keyword-parse-errors/multiple-allow-retries.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-keyword-parse-errors/unterminated-run.txt create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/does-not-substitute-no-limit/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/does-not-substitute-no-limit/test.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/does-not-substitute-within-limit/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/does-not-substitute-within-limit/test.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/negative-integer/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/negative-integer/test.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/not-an-integer/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/not-an-integer/test.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/set-to-none/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/set-to-none/test.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/substitutes-within-limit/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/shtest-recursive-substitution/substitutes-within-limit/test.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/test_retry_attempts/lit.cfg create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/test_retry_attempts/test.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/unparsed-requirements/test.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/xunit-output/excluded.ini create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/xunit-output/missing_feature.ini create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/xunit-output/pass.ini create mode 100644 gnu/llvm/llvm/utils/lit/tests/Inputs/xunit-output/unsupported.ini create mode 100644 gnu/llvm/llvm/utils/lit/tests/allow-retries.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/custom-result-category.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/googletest-discovery-failed.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/max-time.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/show-result-codes.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/show-used-features.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/shtest-format-argv0.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/shtest-inject.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/shtest-keyword-parse-errors.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/shtest-recursive-substitution.py create mode 100644 gnu/llvm/llvm/utils/lit/tests/unparsed-requirements.py create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/.vscodeignore create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/CHANGELOG.md create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/README.md create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/language-configuration-tablegen.json create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/language-configuration.json create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/package-lock.json create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/package.json create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/src/extension.ts create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/src/litTaskProvider.ts create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/syntaxes/TableGen.tmLanguage create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/tsconfig.json create mode 100644 gnu/llvm/llvm/utils/vscode/llvm/vsc-extension-quickstart.md diff --git a/gnu/llvm/llvm/.clang-tidy b/gnu/llvm/llvm/.clang-tidy index 3f407e0160e..e7e0830cfec 100644 --- a/gnu/llvm/llvm/.clang-tidy +++ b/gnu/llvm/llvm/.clang-tidy @@ -14,4 +14,6 @@ CheckOptions: value: CamelCase - key: readability-identifier-naming.VariableCase value: CamelCase + - key: readability-identifier-naming.IgnoreMainLikeFunctions + value: 1 diff --git a/gnu/llvm/llvm/.gitattributes b/gnu/llvm/llvm/.gitattributes new file mode 100644 index 00000000000..48ddf2f02d1 --- /dev/null +++ b/gnu/llvm/llvm/.gitattributes @@ -0,0 +1,19 @@ +# binary files +test/Object/Inputs/*.a-* binary +test/tools/dsymutil/Inputs/*.o binary +test/tools/dsymutil/Inputs/*.a binary +test/tools/dsymutil/Inputs/*.i386 binary +test/tools/dsymutil/Inputs/*.x86_64 binary +test/tools/dsymutil/Inputs/*.armv7m binary +test/tools/dsymutil/Inputs/*.dylib binary +test/tools/llvm-ar/Inputs/*.lib binary +test/tools/llvm-objdump/Inputs/*.a binary +test/tools/llvm-rc/Inputs/* binary +test/tools/llvm-strings/Inputs/numbers binary +test/MC/AsmParser/incbin_abcd binary +test/YAMLParser/spec-09-02.test binary + +# This file must have CRLF line endings, therefore git should treat it as +# binary and not autoconvert line endings (for example, when core.autocrlf is +# on). +test/MC/AsmParser/preserve-comments-crlf.s binary diff --git a/gnu/llvm/llvm/.gitignore b/gnu/llvm/llvm/.gitignore new file mode 100644 index 00000000000..d6021ff18e1 --- /dev/null +++ b/gnu/llvm/llvm/.gitignore @@ -0,0 +1,83 @@ +#==============================================================================# +# This file specifies intentionally untracked files that git should ignore. +# See: http://www.kernel.org/pub/software/scm/git/docs/gitignore.html +# +# This file is intentionally different from the output of `git svn show-ignore`, +# as most of those are useless. +#==============================================================================# + +#==============================================================================# +# Nested build directory. +#==============================================================================# +/build + +#==============================================================================# +# Explicit files to ignore (only matches one). +#==============================================================================# +# Various tag programs +/tags +/TAGS +/GPATH +/GRTAGS +/GSYMS +/GTAGS +.gitusers +autom4te.cache +cscope.files +cscope.out +autoconf/aclocal.m4 +autoconf/autom4te.cache +/compile_commands.json +# Visual Studio built-in CMake configuration +/CMakeSettings.json +# CLion project configuration +/.idea +# Qt Creator project configuration +/CMakeLists.txt.user + +#==============================================================================# +# Directories to ignore (do not add trailing '/'s, they skip symlinks). +#==============================================================================# +# External projects that are tracked independently. +projects/* +!projects/*.* +!projects/Makefile +runtimes/* +!runtimes/*.* +# Clang, which is tracked independently. +tools/clang +# LLDB, which is tracked independently. +tools/lldb +# lld, which is tracked independently. +tools/lld +# Polly, which is tracked independently. +tools/polly +# avrlit, which is tracked independently. +tools/avrlit +# Sphinx build tree, if building in-source dir. +docs/_build +# VS2017 and VSCode config files. +.vscode +.vs + +#==============================================================================# +# Files created in tree by the Go bindings. +#==============================================================================# +bindings/go/llvm/llvm_config.go +bindings/go/llvm/workdir + +#==============================================================================# +# File extensions to be ignored anywhere in the tree. +# Placed at the end to override any previous ! patterns. +#==============================================================================# +# Temp files created by most text editors. +*~ +# Merge files created by git. +*.orig +# Byte compiled python modules. +*.pyc +# vim swap files +.*.sw? +.sw? +#OS X specific files. +.DS_store diff --git a/gnu/llvm/llvm/CMakeLists.txt b/gnu/llvm/llvm/CMakeLists.txt index 0e85afa82c7..247ad36d384 100644 --- a/gnu/llvm/llvm/CMakeLists.txt +++ b/gnu/llvm/llvm/CMakeLists.txt @@ -2,6 +2,14 @@ cmake_minimum_required(VERSION 3.4.3) +if ("${CMAKE_VERSION}" VERSION_LESS "3.13.4") + message(WARNING + "Your CMake version is ${CMAKE_VERSION}. Starting with LLVM 12.0.0, the " + "minimum version of CMake required to build LLVM will become 3.13.4, and " + "using an older CMake will become an error. Please upgrade your CMake to " + "at least 3.13.4 now to avoid issues in the future!") +endif() + if(POLICY CMP0068) cmake_policy(SET CMP0068 NEW) set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON) @@ -16,13 +24,13 @@ if(POLICY CMP0077) endif() if(NOT DEFINED LLVM_VERSION_MAJOR) - set(LLVM_VERSION_MAJOR 10) + set(LLVM_VERSION_MAJOR 11) endif() if(NOT DEFINED LLVM_VERSION_MINOR) - set(LLVM_VERSION_MINOR 0) + set(LLVM_VERSION_MINOR 1) endif() if(NOT DEFINED LLVM_VERSION_PATCH) - set(LLVM_VERSION_PATCH 1) + set(LLVM_VERSION_PATCH 0) endif() if(NOT DEFINED LLVM_VERSION_SUFFIX) set(LLVM_VERSION_SUFFIX "") @@ -63,12 +71,20 @@ endif() # LLVM_EXTERNAL_${project}_SOURCE_DIR using LLVM_ALL_PROJECTS # This allows an easy way of setting up a build directory for llvm and another # one for llvm+clang+... using the same sources. -set(LLVM_ALL_PROJECTS "clang;clang-tools-extra;compiler-rt;debuginfo-tests;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;llgo;mlir;openmp;parallel-libs;polly;pstl") +set(LLVM_ALL_PROJECTS "clang;clang-tools-extra;compiler-rt;debuginfo-tests;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;parallel-libs;polly;pstl") +# The flang project is not yet part of "all" projects (see C++ requirements) +set(LLVM_EXTRA_PROJECTS "flang") +# List of all known projects in the mono repo +set(LLVM_KNOWN_PROJECTS "${LLVM_ALL_PROJECTS};${LLVM_EXTRA_PROJECTS}") set(LLVM_ENABLE_PROJECTS "" CACHE STRING - "Semicolon-separated list of projects to build (${LLVM_ALL_PROJECTS}), or \"all\".") + "Semicolon-separated list of projects to build (${LLVM_KNOWN_PROJECTS}), or \"all\".") if( LLVM_ENABLE_PROJECTS STREQUAL "all" ) set( LLVM_ENABLE_PROJECTS ${LLVM_ALL_PROJECTS}) endif() +if ("flang" IN_LIST LLVM_ENABLE_PROJECTS AND NOT "mlir" IN_LIST LLVM_ENABLE_PROJECTS) + message(STATUS "Enabling MLIR as a dependency to flang") + list(APPEND LLVM_ENABLE_PROJECTS "mlir") +endif() # LLVM_ENABLE_PROJECTS_USED is `ON` if the user has ever used the # `LLVM_ENABLE_PROJECTS` CMake cache variable. This exists for @@ -89,7 +105,7 @@ mark_as_advanced(LLVM_ENABLE_PROJECTS_USED) if (LLVM_ENABLE_PROJECTS_USED OR NOT LLVM_ENABLE_PROJECTS STREQUAL "") set(LLVM_ENABLE_PROJECTS_USED ON CACHE BOOL "" FORCE) - foreach(proj ${LLVM_ALL_PROJECTS} ${LLVM_EXTERNAL_PROJECTS}) + foreach(proj ${LLVM_KNOWN_PROJECTS} ${LLVM_EXTERNAL_PROJECTS}) string(TOUPPER "${proj}" upper_proj) string(REGEX REPLACE "-" "_" upper_proj ${upper_proj}) if ("${proj}" IN_LIST LLVM_ENABLE_PROJECTS) @@ -289,6 +305,7 @@ set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM + AVR BPF Hexagon Lanai @@ -347,26 +364,24 @@ option(LLVM_ENABLE_LIBPFM "Use libpfm for performance counters if available." ON option(LLVM_ENABLE_THREADS "Use threads if available." ON) -option(LLVM_ENABLE_ZLIB "Use zlib for compression/decompression if available." ON) +set(LLVM_ENABLE_ZLIB "ON" CACHE STRING "Use zlib for compression/decompression if available. Can be ON, OFF, or FORCE_ON") set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3 solver.") -find_package(Z3 4.7.1) - -if (LLVM_Z3_INSTALL_DIR) - if (NOT Z3_FOUND) - message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.") - endif() -endif() - -set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}") - option(LLVM_ENABLE_Z3_SOLVER "Enable Support for the Z3 constraint solver in LLVM." ${LLVM_ENABLE_Z3_SOLVER_DEFAULT} ) if (LLVM_ENABLE_Z3_SOLVER) + find_package(Z3 4.7.1) + + if (LLVM_Z3_INSTALL_DIR) + if (NOT Z3_FOUND) + message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.") + endif() + endif() + if (NOT Z3_FOUND) message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is not available.") endif() @@ -374,6 +389,9 @@ if (LLVM_ENABLE_Z3_SOLVER) set(LLVM_WITH_Z3 1) endif() +set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}") + + if( LLVM_TARGETS_TO_BUILD STREQUAL "all" ) set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} ) endif() @@ -388,11 +406,10 @@ option(LLVM_ENABLE_WARNINGS "Enable compiler warnings." ON) option(LLVM_ENABLE_MODULES "Compile with C++ modules enabled." OFF) if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin") option(LLVM_ENABLE_MODULE_DEBUGGING "Compile with -gmodules." ON) - option(LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY "Compile with -fmodules-local-submodule-visibility." OFF) else() option(LLVM_ENABLE_MODULE_DEBUGGING "Compile with -gmodules." OFF) - option(LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY "Compile with -fmodules-local-submodule-visibility." ON) endif() +option(LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY "Compile with -fmodules-local-submodule-visibility." ON) option(LLVM_ENABLE_LIBCXX "Use libc++ if available." OFF) option(LLVM_STATIC_LINK_CXX_STDLIB "Statically link the standard library." OFF) option(LLVM_ENABLE_LLD "Use lld as C and C++ linker." OFF) @@ -409,12 +426,27 @@ endif() option(LLVM_ENABLE_EXPENSIVE_CHECKS "Enable expensive checks" OFF) +# While adding scalable vector support to LLVM, we temporarily want to +# allow an implicit conversion of TypeSize to uint64_t, and to allow +# code to get the fixed number of elements from a possibly scalable vector. +# This CMake flag enables a more strict mode where it asserts that the type +# is not a scalable vector type. +# +# Enabling this flag makes it easier to find cases where the compiler makes +# assumptions on the size being 'fixed size', when building tests for +# SVE/SVE2 or other scalable vector architectures. +option(LLVM_ENABLE_STRICT_FIXED_SIZE_VECTORS + "Enable assertions that type is not scalable in implicit conversion from TypeSize to uint64_t and calls to getNumElements" OFF) + set(LLVM_ABI_BREAKING_CHECKS "WITH_ASSERTS" CACHE STRING "Enable abi-breaking checks. Can be WITH_ASSERTS, FORCE_ON or FORCE_OFF.") option(LLVM_FORCE_USE_OLD_TOOLCHAIN "Set to ON to force using an old, unsupported host toolchain." OFF) +set(LLVM_LOCAL_RPATH "" CACHE FILEPATH + "If set, an absolute path added as rpath on binaries that do not already contain an executable-relative rpath.") + option(LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN "Set to ON to only warn when using a toolchain which is about to be deprecated, instead of emitting an error." OFF) @@ -467,7 +499,7 @@ option(LLVM_USE_SPLIT_DWARF # Define an option controlling whether we should build for 32-bit on 64-bit # platforms, where supported. -if( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 ) +if( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT (WIN32 OR ${CMAKE_SYSTEM_NAME} MATCHES "AIX")) # TODO: support other platforms and toolchains. option(LLVM_BUILD_32_BITS "Build 32 bits executables and libraries." OFF) endif() @@ -647,16 +679,38 @@ option(LLVM_ENABLE_PLUGINS "Enable plugin support" ${LLVM_ENABLE_PLUGINS_default include(HandleLLVMOptions) -include(FindPythonInterp) -if( NOT PYTHONINTERP_FOUND ) - message(FATAL_ERROR -"Unable to find Python interpreter, required for builds and testing. +if(CMAKE_VERSION VERSION_LESS 3.12) + include(FindPythonInterp) + if( NOT PYTHONINTERP_FOUND ) + message(FATAL_ERROR + "Unable to find Python interpreter, required for builds and testing. -Please install Python or specify the PYTHON_EXECUTABLE CMake variable.") -endif() + Please install Python or specify the PYTHON_EXECUTABLE CMake variable.") + endif() + + if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 ) + message(FATAL_ERROR "Python 2.7 or newer is required") + endif() -if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 ) - message(FATAL_ERROR "Python 2.7 or newer is required") + add_executable(Python3::Interpreter IMPORTED) + set_target_properties(Python3::Interpreter PROPERTIES + IMPORTED_LOCATION ${PYTHON_EXECUTABLE}) + set(Python3_EXECUTABLE ${PYTHON_EXECUTABLE}) +else() + find_package(Python3 COMPONENTS Interpreter) + if(NOT Python3_Interpreter_FOUND) + message(WARNING "Python3 not found, using python2 as a fallback") + find_package(Python2 COMPONENTS Interpreter REQUIRED) + if(Python2_VERSION VERSION_LESS 2.7) + message(SEND_ERROR "Python 2.7 or newer is required") + endif() + + # Treat python2 as python3 + add_executable(Python3::Interpreter IMPORTED) + set_target_properties(Python3::Interpreter PROPERTIES + IMPORTED_LOCATION ${Python2_EXECUTABLE}) + set(Python3_EXECUTABLE ${Python2_EXECUTABLE}) + endif() endif() ###### @@ -692,7 +746,7 @@ endif (LLVM_USE_PERF) message(STATUS "Constructing LLVMBuild project information") execute_process( - COMMAND ${PYTHON_EXECUTABLE} -B ${LLVMBUILDTOOL} + COMMAND "${Python3_EXECUTABLE}" -B ${LLVMBUILDTOOL} --native-target "${LLVM_NATIVE_ARCH}" --enable-targets "${LLVM_TARGETS_TO_BUILD}" --enable-optional-components "${LLVMOPTIONALCOMPONENTS}" @@ -778,6 +832,26 @@ configure_file( ${LLVM_INCLUDE_DIR}/llvm/Config/Targets.def ) +# They are not referenced. See set_output_directory(). +set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LLVM_BINARY_DIR}/bin ) +set( CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} ) +set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} ) + +# For up-to-date instructions for installing the Tensorflow dependency, refer to +# the bot setup script: https://github.com/google/ml-compiler-opt/blob/master/buildbot/buildbot_init.sh +# In this case, the latest C API library is available for download from +# https://www.tensorflow.org/install/lang_c. +# We will expose the conditional compilation variable, +# LLVM_HAVE_TF_API, through llvm-config.h, so that a user of the LLVM library may +# also leverage the dependency. +set(TENSORFLOW_C_LIB_PATH "" CACHE PATH "Path to TensorFlow C library install") + +if (TENSORFLOW_C_LIB_PATH) + find_library(tensorflow_c_api tensorflow PATHS ${TENSORFLOW_C_LIB_PATH}/lib NO_DEFAULT_PATH REQUIRED) + set(LLVM_HAVE_TF_API "ON" CACHE BOOL "Full Tensorflow API available") + include_directories(${TENSORFLOW_C_LIB_PATH}/include) +endif() + # Configure the three LLVM configuration header files. configure_file( ${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/config.h.cmake @@ -808,12 +882,6 @@ add_custom_target(srpm COMMAND rpmbuild -bs --define '_topdir ${LLVM_SRPM_DIR}' ${LLVM_SRPM_BINARY_SPECFILE}) set_target_properties(srpm PROPERTIES FOLDER "Misc") - -# They are not referenced. See set_output_directory(). -set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LLVM_BINARY_DIR}/bin ) -set( CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} ) -set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} ) - if(APPLE AND DARWIN_LTO_LIBRARY) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-lto_library -Wl,${DARWIN_LTO_LIBRARY}") @@ -828,6 +896,30 @@ endif() if (UNIX AND ${CMAKE_SYSTEM_NAME} MATCHES "AIX") add_definitions("-D_XOPEN_SOURCE=700") add_definitions("-D_LARGE_FILE_API") + + # CMake versions less than 3.16 set default linker flags to include -brtl, as + # well as setting -G when building libraries, so clear them out. Note we only + # try to clear the form that CMake will set as part of its initial + # configuration, it is still possible the user may force it as part of a + # compound option. + if(CMAKE_VERSION VERSION_LESS 3.16) + string(REGEX REPLACE "(^|[ \t]+)-Wl,-brtl([ \t]+|$)" "" CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}") + string(REGEX REPLACE "(^|[ \t]+)-Wl,-brtl([ \t]+|$)" "" CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}") + string(REGEX REPLACE "(^|[ \t]+)-Wl,-brtl([ \t]+|$)" "" CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}") + string(REGEX REPLACE "(^|[ \t]+)(-Wl,)?-G([ \t]+|$)" "" CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS + "${CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS}") + string(REGEX REPLACE "(^|[ \t]+)(-Wl,)?-G([ \t]+|$)" "" CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS + "${CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS}") + string(REGEX REPLACE "(^|[ \t]+)(-Wl,)?-G([ \t]+|$)" "" CMAKE_SHARED_LIBRARY_CREATE_ASM_FLAGS + "${CMAKE_SHARED_LIBRARY_CREATE_ASM_FLAGS}") + endif() + + # Modules should be built with -G, so we can use runtime linking with + # plugins. + string(APPEND CMAKE_MODULE_LINKER_FLAGS " -G") + + # Also set the correct flags for building shared libraries. + string(APPEND CMAKE_SHARED_LINKER_FLAGS " -shared") endif() # Build with _FILE_OFFSET_BITS=64 on Solaris to match g++ >= 9. @@ -884,6 +976,28 @@ if( MINGW AND NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" ) llvm_replace_compiler_option(CMAKE_CXX_FLAGS_RELEASE "-O3" "-O2") endif() +# For up-to-date instructions for installing the Tensorflow dependency, refer to +# the bot setup script: https://github.com/google/ml-compiler-opt/blob/master/buildbot/buildbot_init.sh +# Specifically, assuming python3 is installed: +# python3 -m pip install --upgrade pip && python3 -m pip install --user tf_nightly==2.3.0.dev20200528 +# Then set TENSORFLOW_AOT_PATH to the package install - usually it's ~/.local/lib/python3.7/site-packages/tensorflow +# +set(TENSORFLOW_AOT_PATH "" CACHE PATH "Path to TensorFlow pip install dir") + +if (NOT TENSORFLOW_AOT_PATH STREQUAL "") + set(LLVM_HAVE_TF_AOT "ON" CACHE BOOL "Tensorflow AOT available") + set(TENSORFLOW_AOT_COMPILER + "${TENSORFLOW_AOT_PATH}/../../../../bin/saved_model_cli" + CACHE PATH "Path to the Tensorflow AOT compiler") + # Unlike the LLVM_HAVE_TF_API case, we don't need to expose this through + # llvm-config.h, because it's an internal implementation detail. A user of the llvm library that wants to also + # use the TF AOT compiler may do so through their custom build step. + add_definitions("-DLLVM_HAVE_TF_AOT") + include_directories(${TENSORFLOW_AOT_PATH}/include) + add_subdirectory(${TENSORFLOW_AOT_PATH}/xla_aot_runtime_src + ${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}/tf_runtime) +endif() + # Put this before tblgen. Else we have a circular dependence. add_subdirectory(lib/Demangle) add_subdirectory(lib/Support) @@ -1034,7 +1148,7 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) # Installing the headers needs to depend on generating any public # tablegen'd headers. - add_custom_target(llvm-headers DEPENDS intrinsics_gen) + add_custom_target(llvm-headers DEPENDS intrinsics_gen omp_gen) set_target_properties(llvm-headers PROPERTIES FOLDER "Misc") if (NOT LLVM_ENABLE_IDE) @@ -1060,6 +1174,7 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) add_dependencies(llvm-libraries ${lib}) if (NOT LLVM_ENABLE_IDE) add_dependencies(install-llvm-libraries install-${lib}) + add_dependencies(install-llvm-libraries-stripped install-${lib}-stripped) endif() endforeach() endif() diff --git a/gnu/llvm/llvm/CODE_OWNERS.TXT b/gnu/llvm/llvm/CODE_OWNERS.TXT index 457dabe39f9..cd42a4514ac 100644 --- a/gnu/llvm/llvm/CODE_OWNERS.TXT +++ b/gnu/llvm/llvm/CODE_OWNERS.TXT @@ -9,6 +9,12 @@ beautification by scripts. The fields are: name (N), email (E), web-address (S) and (I) IRC handle. Each entry should contain at least the (N), (E) and (D) fields. +N: Matt Arsenault +E: Matthew.Arsenault@amd.com +E: arsenm2@gmail.com +I: arsenm +D: InferAddressSpaces + N: Simon Atanasyan E: simon@atanasyan.com D: MIPS Backend (lib/Target/Mips/*) @@ -52,8 +58,8 @@ N: Pete Couperus E: petecoup@synopsys.com D: ARC backend (lib/Target/ARC/*) -N: Sanjoy Das -E: sanjoy@playingwithpointers.com +N: Philip Reames +E: listmail@philipreames.com D: IndVar Simplify, Scalar Evolution N: Marshall Clow @@ -62,7 +68,7 @@ D: libc++ N: Peter Collingbourne E: peter@pcc.me.uk -D: llgo, libLTO (lib/LTO/* tools/lto/*), LLVM Bitcode (lib/Bitcode/* include/llvm/Bitcode/*) +D: libLTO (lib/LTO/* tools/lto/*), LLVM Bitcode (lib/Bitcode/* include/llvm/Bitcode/*) N: Quentin Colombet E: quentin.colombet@gmail.com @@ -219,10 +225,6 @@ N: Hans Wennborg E: hans@chromium.org D: Release management (x.y.0 releases) -N: whitequark -E: whitequark@whitequark.org -D: C API, OCaml bindings - N: Jake Ehrlich E: jakehehrlich@google.com D: llvm-objcopy (tools/llvm-objcopy) diff --git a/gnu/llvm/llvm/README.txt b/gnu/llvm/llvm/README.txt index ebbd50fc0b7..b9b71a3b6da 100644 --- a/gnu/llvm/llvm/README.txt +++ b/gnu/llvm/llvm/README.txt @@ -15,4 +15,3 @@ documentation setup. If you are writing a package for LLVM, see docs/Packaging.rst for our suggestions. - diff --git a/gnu/llvm/llvm/bindings/go/llvm/dibuilder.go b/gnu/llvm/llvm/bindings/go/llvm/dibuilder.go index caee85e2958..aeaf49e539b 100644 --- a/gnu/llvm/llvm/bindings/go/llvm/dibuilder.go +++ b/gnu/llvm/llvm/bindings/go/llvm/dibuilder.go @@ -117,6 +117,8 @@ type DICompileUnit struct { Optimized bool Flags string RuntimeVersion int + SysRoot string + SDK string } // CreateCompileUnit creates compile unit debug metadata. @@ -129,6 +131,10 @@ func (d *DIBuilder) CreateCompileUnit(cu DICompileUnit) Metadata { defer C.free(unsafe.Pointer(producer)) flags := C.CString(cu.Flags) defer C.free(unsafe.Pointer(flags)) + sysroot := C.CString(cu.SysRoot) + defer C.free(unsafe.Pointer(sysroot)) + sdk := C.CString(cu.SDK) + defer C.free(unsafe.Pointer(sdk)) result := C.LLVMDIBuilderCreateCompileUnit( d.ref, C.LLVMDWARFSourceLanguage(cu.Language), @@ -142,6 +148,8 @@ func (d *DIBuilder) CreateCompileUnit(cu DICompileUnit) Metadata { /*DWOId=*/ 0, /*SplitDebugInlining*/ C.LLVMBool(boolToCInt(true)), /*DebugInfoForProfiling*/ C.LLVMBool(boolToCInt(false)), + sysroot, C.size_t(len(cu.SysRoot)), + sdk, C.size_t(len(cu.SDK)), ) return Metadata{C: result} } diff --git a/gnu/llvm/llvm/bindings/go/llvm/ir.go b/gnu/llvm/llvm/bindings/go/llvm/ir.go index 1a144eacb4d..bb8896e25d3 100644 --- a/gnu/llvm/llvm/bindings/go/llvm/ir.go +++ b/gnu/llvm/llvm/bindings/go/llvm/ir.go @@ -224,21 +224,22 @@ const ( //------------------------------------------------------------------------- const ( - VoidTypeKind TypeKind = C.LLVMVoidTypeKind - FloatTypeKind TypeKind = C.LLVMFloatTypeKind - DoubleTypeKind TypeKind = C.LLVMDoubleTypeKind - X86_FP80TypeKind TypeKind = C.LLVMX86_FP80TypeKind - FP128TypeKind TypeKind = C.LLVMFP128TypeKind - PPC_FP128TypeKind TypeKind = C.LLVMPPC_FP128TypeKind - LabelTypeKind TypeKind = C.LLVMLabelTypeKind - IntegerTypeKind TypeKind = C.LLVMIntegerTypeKind - FunctionTypeKind TypeKind = C.LLVMFunctionTypeKind - StructTypeKind TypeKind = C.LLVMStructTypeKind - ArrayTypeKind TypeKind = C.LLVMArrayTypeKind - PointerTypeKind TypeKind = C.LLVMPointerTypeKind - VectorTypeKind TypeKind = C.LLVMVectorTypeKind - MetadataTypeKind TypeKind = C.LLVMMetadataTypeKind - TokenTypeKind TypeKind = C.LLVMTokenTypeKind + VoidTypeKind TypeKind = C.LLVMVoidTypeKind + FloatTypeKind TypeKind = C.LLVMFloatTypeKind + DoubleTypeKind TypeKind = C.LLVMDoubleTypeKind + X86_FP80TypeKind TypeKind = C.LLVMX86_FP80TypeKind + FP128TypeKind TypeKind = C.LLVMFP128TypeKind + PPC_FP128TypeKind TypeKind = C.LLVMPPC_FP128TypeKind + LabelTypeKind TypeKind = C.LLVMLabelTypeKind + IntegerTypeKind TypeKind = C.LLVMIntegerTypeKind + FunctionTypeKind TypeKind = C.LLVMFunctionTypeKind + StructTypeKind TypeKind = C.LLVMStructTypeKind + ArrayTypeKind TypeKind = C.LLVMArrayTypeKind + PointerTypeKind TypeKind = C.LLVMPointerTypeKind + MetadataTypeKind TypeKind = C.LLVMMetadataTypeKind + TokenTypeKind TypeKind = C.LLVMTokenTypeKind + VectorTypeKind TypeKind = C.LLVMVectorTypeKind + ScalableVectorTypeKind TypeKind = C.LLVMScalableVectorTypeKind ) //------------------------------------------------------------------------- @@ -1256,6 +1257,7 @@ func (bb BasicBlock) MoveAfter(pos BasicBlock) { C.LLVMMoveBasicBlockAfter(bb.C // Operations on instructions func (v Value) EraseFromParentAsInstruction() { C.LLVMInstructionEraseFromParent(v.C) } +func (v Value) RemoveFromParentAsInstruction() { C.LLVMInstructionRemoveFromParent(v.C) } func (v Value) InstructionParent() (bb BasicBlock) { bb.C = C.LLVMGetInstructionParent(v.C); return } func (v Value) InstructionDebugLoc() (md Metadata) { md.C = C.LLVMInstructionGetDebugLoc(v.C); return } func (v Value) InstructionSetDebugLoc(md Metadata) { C.LLVMInstructionSetDebugLoc(v.C, md.C) } diff --git a/gnu/llvm/llvm/bindings/go/llvm/string.go b/gnu/llvm/llvm/bindings/go/llvm/string.go index bd48d4bc170..7c8bf8da5b3 100644 --- a/gnu/llvm/llvm/bindings/go/llvm/string.go +++ b/gnu/llvm/llvm/bindings/go/llvm/string.go @@ -40,10 +40,12 @@ func (t TypeKind) String() string { return "ArrayTypeKind" case PointerTypeKind: return "PointerTypeKind" - case VectorTypeKind: - return "VectorTypeKind" case MetadataTypeKind: return "MetadataTypeKind" + case VectorTypeKind: + return "VectorTypeKind" + case ScalableVectorTypeKind: + return "ScalableVectorTypeKind" } panic("unreachable") } diff --git a/gnu/llvm/llvm/bindings/go/llvm/transforms_pmbuilder.go b/gnu/llvm/llvm/bindings/go/llvm/transforms_pmbuilder.go index f6b92ed099b..badd148c195 100644 --- a/gnu/llvm/llvm/bindings/go/llvm/transforms_pmbuilder.go +++ b/gnu/llvm/llvm/bindings/go/llvm/transforms_pmbuilder.go @@ -14,6 +14,7 @@ package llvm /* #include "llvm-c/Transforms/PassManagerBuilder.h" +#include "llvm-c/Transforms/Coroutines.h" */ import "C" @@ -65,3 +66,7 @@ func (pmb PassManagerBuilder) SetDisableSimplifyLibCalls(val bool) { func (pmb PassManagerBuilder) UseInlinerWithThreshold(threshold uint) { C.LLVMPassManagerBuilderUseInlinerWithThreshold(pmb.C, C.uint(threshold)) } + +func (pmb PassManagerBuilder) AddCoroutinePassesToExtensionPoints() { + C.LLVMPassManagerBuilderAddCoroutinePassesToExtensionPoints(pmb.C); +} diff --git a/gnu/llvm/llvm/cmake/config-ix.cmake b/gnu/llvm/llvm/cmake/config-ix.cmake index f758366bc79..90e5d327c75 100644 --- a/gnu/llvm/llvm/cmake/config-ix.cmake +++ b/gnu/llvm/llvm/cmake/config-ix.cmake @@ -13,7 +13,7 @@ include(CheckCCompilerFlag) include(CheckCompilerVersion) include(HandleLLVMStdlib) -if( UNIX AND NOT (BEOS OR HAIKU) ) +if( UNIX AND NOT (APPLE OR BEOS OR HAIKU) ) # Used by check_symbol_exists: list(APPEND CMAKE_REQUIRED_LIBRARIES "m") endif() @@ -175,6 +175,10 @@ if (LLVM_ENABLE_LIBXML2 STREQUAL "FORCE_ON" AND NOT LLVM_LIBXML2_ENABLED) message(FATAL_ERROR "Failed to congifure libxml2") endif() +if (LLVM_ENABLE_ZLIB STREQUAL "FORCE_ON" AND NOT HAVE_LIBZ) + message(FATAL_ERROR "Failed to configure zlib") +endif() + check_library_exists(xar xar_open "" HAVE_LIBXAR) if(HAVE_LIBXAR) set(XAR_LIB xar) @@ -270,8 +274,6 @@ if( LLVM_USING_GLIBC ) list(APPEND CMAKE_REQUIRED_DEFINITIONS "-D_GNU_SOURCE") endif() # This check requires _GNU_SOURCE -check_symbol_exists(sched_getaffinity sched.h HAVE_SCHED_GETAFFINITY) -check_symbol_exists(CPU_COUNT sched.h HAVE_CPU_COUNT) if (NOT PURE_WINDOWS) if (LLVM_PTHREAD_LIB) list(APPEND CMAKE_REQUIRED_LIBRARIES ${LLVM_PTHREAD_LIB}) @@ -637,7 +639,7 @@ function(find_python_module module) return() endif() - execute_process(COMMAND "${PYTHON_EXECUTABLE}" "-c" "import ${module}" + execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "import ${module}" RESULT_VARIABLE status ERROR_QUIET) diff --git a/gnu/llvm/llvm/cmake/config.guess b/gnu/llvm/llvm/cmake/config.guess index ccb30f4e75e..9fdfcce8d03 100644 --- a/gnu/llvm/llvm/cmake/config.guess +++ b/gnu/llvm/llvm/cmake/config.guess @@ -973,6 +973,30 @@ EOF ppc:Linux:*:*) echo powerpc-unknown-linux-gnu exit ;; + riscv32:Linux:*:* | riscv64:Linux:*:*) + LIBC=gnu + eval $set_cc_for_build + # Do not check for __GLIBC__ because uclibc defines it too + sed 's/^ //' << EOF >$dummy.c + #include + #if defined(__UCLIBC__) + LIBC=uclibc + #elif defined(__dietlibc__) + LIBC=dietlibc + #endif +EOF + eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^LIBC'` + + # There is no features test macro for musl + # Follow the GNU's config.guess approach of + # checking the output of ldd + if command -v ldd >/dev/null && \ + ldd --version 2>&1 | grep -q ^musl; then + LIBC=musl + fi + + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} + exit ;; s390:Linux:*:* | s390x:Linux:*:*) echo ${UNAME_MACHINE}-ibm-linux exit ;; @@ -1239,6 +1263,23 @@ EOF UNAME_PROCESSOR="x86_64" fi fi ;; + arm) + eval $set_cc_for_build + if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then + if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \ + (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ + grep IS_64BIT_ARCH >/dev/null + then + if (echo '#ifdef __PTRAUTH_INTRINSICS__'; echo HAS_AUTH; echo '#endif') | \ + (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ + grep HAS_AUTH >/dev/null + then + UNAME_PROCESSOR="arm64e" + else + UNAME_PROCESSOR="arm64" + fi + fi + fi ;; unknown) UNAME_PROCESSOR=powerpc ;; esac echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE} diff --git a/gnu/llvm/llvm/cmake/modules/AddLLVM.cmake b/gnu/llvm/llvm/cmake/modules/AddLLVM.cmake index f5a1b0d6f23..b74adc11ade 100644 --- a/gnu/llvm/llvm/cmake/modules/AddLLVM.cmake +++ b/gnu/llvm/llvm/cmake/modules/AddLLVM.cmake @@ -90,6 +90,7 @@ function(add_llvm_symbol_exports target_name export_file) set_property(TARGET ${target_name} APPEND_STRING PROPERTY LINK_FLAGS " -Wl,-exported_symbols_list,\"${CMAKE_CURRENT_BINARY_DIR}/${native_export_file}\"") elseif(${CMAKE_SYSTEM_NAME} MATCHES "AIX") + set(native_export_file "${export_file}") set_property(TARGET ${target_name} APPEND_STRING PROPERTY LINK_FLAGS " -Wl,-bE:${export_file}") elseif(LLVM_HAVE_LINK_VERSION_SCRIPT) @@ -117,7 +118,7 @@ function(add_llvm_symbol_exports target_name export_file) set(native_export_file "${target_name}.def") add_custom_command(OUTPUT ${native_export_file} - COMMAND ${PYTHON_EXECUTABLE} -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))" + COMMAND "${Python3_EXECUTABLE}" -c "import sys;print(''.join(['EXPORTS\\n']+sys.stdin.readlines(),))" < ${export_file} > ${native_export_file} DEPENDS ${export_file} VERBATIM @@ -162,49 +163,54 @@ function(add_llvm_symbol_exports target_name export_file) set(LLVM_COMMON_DEPENDS ${LLVM_COMMON_DEPENDS} PARENT_SCOPE) endfunction(add_llvm_symbol_exports) -if(APPLE) - execute_process( - COMMAND "${CMAKE_LINKER}" -v - ERROR_VARIABLE stderr - ) - set(LLVM_LINKER_DETECTED YES) - if("${stderr}" MATCHES "PROJECT:ld64") - set(LLVM_LINKER_IS_LD64 YES) - message(STATUS "Linker detection: ld64") - else() - set(LLVM_LINKER_DETECTED NO) - message(STATUS "Linker detection: unknown") - endif() -elseif(NOT WIN32) - # Detect what linker we have here - if( LLVM_USE_LINKER ) - set(command ${CMAKE_C_COMPILER} -fuse-ld=${LLVM_USE_LINKER} -Wl,--version) - else() - separate_arguments(flags UNIX_COMMAND "${CMAKE_EXE_LINKER_FLAGS}") - set(command ${CMAKE_C_COMPILER} ${flags} -Wl,--version) - endif() - execute_process( - COMMAND ${command} - OUTPUT_VARIABLE stdout - ERROR_VARIABLE stderr - ) - set(LLVM_LINKER_DETECTED YES) - if("${stdout}" MATCHES "GNU gold") - set(LLVM_LINKER_IS_GOLD YES) - message(STATUS "Linker detection: GNU Gold") - elseif("${stdout}" MATCHES "^LLD") - set(LLVM_LINKER_IS_LLD YES) - message(STATUS "Linker detection: LLD") - elseif("${stdout}" MATCHES "GNU ld") - set(LLVM_LINKER_IS_GNULD YES) - message(STATUS "Linker detection: GNU ld") - elseif("${stderr}" MATCHES "Solaris Link Editors" OR - "${stdout}" MATCHES "Solaris Link Editors") - set(LLVM_LINKER_IS_SOLARISLD YES) - message(STATUS "Linker detection: Solaris ld") - else() - set(LLVM_LINKER_DETECTED NO) - message(STATUS "Linker detection: unknown") +if (NOT DEFINED LLVM_LINKER_DETECTED) + if(APPLE) + execute_process( + COMMAND "${CMAKE_LINKER}" -v + ERROR_VARIABLE stderr + ) + if("${stderr}" MATCHES "PROJECT:ld64") + set(LLVM_LINKER_DETECTED YES CACHE INTERNAL "") + set(LLVM_LINKER_IS_LD64 YES CACHE INTERNAL "") + message(STATUS "Linker detection: ld64") + else() + set(LLVM_LINKER_DETECTED NO CACHE INTERNAL "") + message(STATUS "Linker detection: unknown") + endif() + elseif(NOT WIN32) + # Detect what linker we have here + if( LLVM_USE_LINKER ) + set(command ${CMAKE_C_COMPILER} -fuse-ld=${LLVM_USE_LINKER} -Wl,--version) + else() + separate_arguments(flags UNIX_COMMAND "${CMAKE_EXE_LINKER_FLAGS}") + set(command ${CMAKE_C_COMPILER} ${flags} -Wl,--version) + endif() + execute_process( + COMMAND ${command} + OUTPUT_VARIABLE stdout + ERROR_VARIABLE stderr + ) + if("${stdout}" MATCHES "GNU gold") + set(LLVM_LINKER_DETECTED YES CACHE INTERNAL "") + set(LLVM_LINKER_IS_GOLD YES CACHE INTERNAL "") + message(STATUS "Linker detection: GNU Gold") + elseif("${stdout}" MATCHES "^LLD") + set(LLVM_LINKER_DETECTED YES CACHE INTERNAL "") + set(LLVM_LINKER_IS_LLD YES CACHE INTERNAL "") + message(STATUS "Linker detection: LLD") + elseif("${stdout}" MATCHES "GNU ld") + set(LLVM_LINKER_DETECTED YES CACHE INTERNAL "") + set(LLVM_LINKER_IS_GNULD YES CACHE INTERNAL "") + message(STATUS "Linker detection: GNU ld") + elseif("${stderr}" MATCHES "Solaris Link Editors" OR + "${stdout}" MATCHES "Solaris Link Editors") + set(LLVM_LINKER_DETECTED YES CACHE INTERNAL "") + set(LLVM_LINKER_IS_SOLARISLD YES CACHE INTERNAL "") + message(STATUS "Linker detection: Solaris ld") + else() + set(LLVM_LINKER_DETECTED NO CACHE INTERNAL "") + message(STATUS "Linker detection: unknown") + endif() endif() endif() @@ -234,8 +240,14 @@ function(add_link_opts target_name) set_property(TARGET ${target_name} APPEND_STRING PROPERTY LINK_FLAGS " -Wl,-dead_strip") elseif(${CMAKE_SYSTEM_NAME} MATCHES "SunOS") - set_property(TARGET ${target_name} APPEND_STRING PROPERTY - LINK_FLAGS " -Wl,-z -Wl,discard-unused=sections") + # Support for ld -z discard-unused=sections was only added in + # Solaris 11.4. + include(CheckLinkerFlag) + check_linker_flag("-Wl,-z,discard-unused=sections" LINKER_SUPPORTS_Z_DISCARD_UNUSED) + if (LINKER_SUPPORTS_Z_DISCARD_UNUSED) + set_property(TARGET ${target_name} APPEND_STRING PROPERTY + LINK_FLAGS " -Wl,-z,discard-unused=sections") + endif() elseif(NOT WIN32 AND NOT LLVM_LINKER_IS_GOLD AND NOT ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD|AIX") # Object files are compiled with -ffunction-data-sections. @@ -252,6 +264,11 @@ function(add_link_opts target_name) endif() endif() endif() + + if(ARG_SUPPORT_PLUGINS AND ${CMAKE_SYSTEM_NAME} MATCHES "AIX") + set_property(TARGET ${target_name} APPEND_STRING PROPERTY + LINK_FLAGS " -Wl,-brtl") + endif() endfunction(add_link_opts) # Set each output directory according to ${CMAKE_CONFIGURATION_TYPES}. @@ -462,6 +479,26 @@ function(llvm_add_library name) if(ARG_DEPENDS) add_dependencies(${obj_name} ${ARG_DEPENDS}) endif() + # Treat link libraries like PUBLIC dependencies. LINK_LIBS might + # result in generating header files. Add a dependendency so that + # the generated header is created before this object library. + if(ARG_LINK_LIBS) + cmake_parse_arguments(LINK_LIBS_ARG + "" + "" + "PUBLIC;PRIVATE" + ${ARG_LINK_LIBS}) + foreach(link_lib ${LINK_LIBS_ARG_PUBLIC}) + if(LLVM_PTHREAD_LIB) + # Can't specify a dependence on -lpthread + if(NOT ${link_lib} STREQUAL ${LLVM_PTHREAD_LIB}) + add_dependencies(${obj_name} ${link_lib}) + endif() + else() + add_dependencies(${obj_name} ${link_lib}) + endif() + endforeach() + endif() endif() if(ARG_SHARED AND ARG_STATIC) @@ -790,6 +827,10 @@ macro(add_llvm_executable name) if(NOT ARG_NO_INSTALL_RPATH) llvm_setup_rpath(${name}) + elseif (LLVM_LOCAL_RPATH) + set_target_properties(${name} PROPERTIES + BUILD_WITH_INSTALL_RPATH On + INSTALL_RPATH "${LLVM_LOCAL_RPATH}") endif() if(DEFINED windows_resource_file) @@ -850,7 +891,7 @@ endmacro(add_llvm_executable name) # only an object library is built, and no module is built. This is specific to the Polly use case. # # The SUBPROJECT argument contains the LLVM project the plugin belongs -# to. If set, the plugin will link statically by default it if the +# to. If set, the plugin will link statically by default it if the # project was enabled. function(add_llvm_pass_plugin name) cmake_parse_arguments(ARG @@ -884,6 +925,12 @@ function(add_llvm_pass_plugin name) if (TARGET intrinsics_gen) add_dependencies(obj.${name} intrinsics_gen) endif() + if (TARGET omp_gen) + add_dependencies(obj.${name} omp_gen) + endif() + if (TARGET acc_gen) + add_dependencies(obj.${name} acc_gen) + endif() set_property(GLOBAL APPEND PROPERTY LLVM_STATIC_EXTENSIONS ${name}) elseif(NOT ARG_NO_MODULE) add_llvm_library(${name} MODULE ${ARG_UNPARSED_ARGUMENTS}) @@ -1047,7 +1094,7 @@ function(export_executable_symbols target) set(mangling itanium) endif() add_custom_command(OUTPUT ${exported_symbol_file} - COMMAND ${PYTHON_EXECUTABLE} ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file} + COMMAND "${Python3_EXECUTABLE}" ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py --mangling=${mangling} ${static_libs} -o ${exported_symbol_file} WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR} DEPENDS ${LLVM_MAIN_SRC_DIR}/utils/extract_symbols.py ${static_libs} VERBATIM @@ -1076,6 +1123,13 @@ function(export_executable_symbols target) endif() endfunction() +# Export symbols if LLVM plugins are enabled. +function(export_executable_symbols_for_plugins target) + if(LLVM_ENABLE_PLUGINS OR LLVM_EXPORT_SYMBOLS_FOR_PLUGINS) + export_executable_symbols(${target}) + endif() +endfunction() + if(NOT LLVM_TOOLCHAIN_TOOLS) set (LLVM_TOOLCHAIN_TOOLS llvm-ar @@ -1380,7 +1434,7 @@ function(add_unittest test_suite test_name) add_dependencies(${test_suite} ${test_name}) get_target_property(test_suite_folder ${test_suite} FOLDER) - if (NOT ${test_suite_folder} STREQUAL "NOTFOUND") + if (test_suite_folder) set_property(TARGET ${test_name} PROPERTY FOLDER "${test_suite_folder}") endif () endfunction() @@ -1409,36 +1463,6 @@ function(add_benchmark benchmark_name) target_link_libraries(${benchmark_name} PRIVATE benchmark) endfunction() -function(llvm_add_go_executable binary pkgpath) - cmake_parse_arguments(ARG "ALL" "" "DEPENDS;GOFLAGS" ${ARGN}) - - if(LLVM_BINDINGS MATCHES "go") - # FIXME: This should depend only on the libraries Go needs. - get_property(llvmlibs GLOBAL PROPERTY LLVM_LIBS) - set(binpath ${CMAKE_BINARY_DIR}/bin/${binary}${CMAKE_EXECUTABLE_SUFFIX}) - set(cc "${CMAKE_C_COMPILER} ${CMAKE_C_COMPILER_ARG1}") - set(cxx "${CMAKE_CXX_COMPILER} ${CMAKE_CXX_COMPILER_ARG1}") - set(cppflags "") - get_property(include_dirs DIRECTORY PROPERTY INCLUDE_DIRECTORIES) - foreach(d ${include_dirs}) - set(cppflags "${cppflags} -I${d}") - endforeach(d) - set(ldflags "${CMAKE_EXE_LINKER_FLAGS}") - add_custom_command(OUTPUT ${binpath} - COMMAND ${CMAKE_BINARY_DIR}/bin/llvm-go "go=${GO_EXECUTABLE}" "cc=${cc}" "cxx=${cxx}" "cppflags=${cppflags}" "ldflags=${ldflags}" "packages=${LLVM_GO_PACKAGES}" - ${ARG_GOFLAGS} build -o ${binpath} ${pkgpath} - DEPENDS llvm-config ${CMAKE_BINARY_DIR}/bin/llvm-go${CMAKE_EXECUTABLE_SUFFIX} - ${llvmlibs} ${ARG_DEPENDS} - COMMENT "Building Go executable ${binary}" - VERBATIM) - if (ARG_ALL) - add_custom_target(${binary} ALL DEPENDS ${binpath}) - else() - add_custom_target(${binary} DEPENDS ${binpath}) - endif() - endif() -endfunction() - # This function canonicalize the CMake variables passed by names # from CMake boolean to 0/1 suitable for passing into Python or C++, # in place. @@ -1461,13 +1485,57 @@ macro(set_llvm_build_mode) endif () endmacro() +# Takes a list of path names in pathlist and a base directory, and returns +# a list of paths relative to the base directory in out_pathlist. +# Paths that are on a different drive than the basedir (on Windows) or that +# contain symlinks are returned absolute. +# Use with LLVM_LIT_PATH_FUNCTION below. +function(make_paths_relative out_pathlist basedir pathlist) + # Passing ARG_PATH_VALUES as-is to execute_process() makes cmake strip + # empty list entries. So escape the ;s in the list and do the splitting + # ourselves. cmake has no relpath function, so use Python for that. + string(REPLACE ";" "\\;" pathlist_escaped "${pathlist}") + execute_process(COMMAND "${Python3_EXECUTABLE}" "-c" "\n +import os, sys\n +base = sys.argv[1] +def haslink(p):\n + if not p or p == os.path.dirname(p): return False\n + return os.path.islink(p) or haslink(os.path.dirname(p))\n +def relpath(p):\n + if not p: return ''\n + if os.path.splitdrive(p)[0] != os.path.splitdrive(base)[0]: return p\n + if haslink(p) or haslink(base): return p\n + return os.path.relpath(p, base)\n +sys.stdout.write(';'.join(relpath(p) for p in sys.argv[2].split(';')))" + ${basedir} + ${pathlist_escaped} + OUTPUT_VARIABLE pathlist_relative) + set(${out_pathlist} "${pathlist_relative}" PARENT_SCOPE) +endfunction() + +# Converts a file that's relative to the current python file to an absolute +# path. Since this uses __file__, it has to be emitted into python files that +# use it and can't be in a lit module. Use with make_paths_relative(). +string(CONCAT LLVM_LIT_PATH_FUNCTION + "# Allow generated file to be relocatable.\n" + "def path(p):\n" + " if not p: return ''\n" + " return os.path.join(os.path.dirname(os.path.abspath(__file__)), p)\n" + ) + # This function provides an automatic way to 'configure'-like generate a file # based on a set of common and custom variables, specifically targeting the # variables needed for the 'lit.site.cfg' files. This function bundles the # common variables that any Lit instance is likely to need, and custom # variables can be passed in. +# The keyword PATHS is followed by a list of cmake variable names that are +# mentioned as `path("@varname@")` in the lit.cfg.py.in file. Variables in that +# list are treated as paths that are relative to the directory the generated +# lit.cfg.py file is in, and the `path()` function converts the relative +# path back to absolute form. This makes it possible to move a build directory +# containing lit.cfg.py files from one machine to another. function(configure_lit_site_cfg site_in site_out) - cmake_parse_arguments(ARG "" "" "MAIN_CONFIG;OUTPUT_MAPPING" ${ARGN}) + cmake_parse_arguments(ARG "" "" "MAIN_CONFIG;OUTPUT_MAPPING;PATHS" ${ARGN}) if ("${ARG_MAIN_CONFIG}" STREQUAL "") get_filename_component(INPUT_DIR ${site_in} DIRECTORY) @@ -1495,7 +1563,6 @@ function(configure_lit_site_cfg site_in site_out) # SHLIBDIR points the build tree. string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" SHLIBDIR "${LLVM_SHLIB_OUTPUT_INTDIR}") - set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE}) # FIXME: "ENABLE_SHARED" doesn't make sense, since it is used just for # plugins. We may rename it. if(LLVM_ENABLE_PLUGINS) @@ -1517,12 +1584,15 @@ function(configure_lit_site_cfg site_in site_out) set(HOST_CXX "${CMAKE_CXX_COMPILER} ${CMAKE_CXX_COMPILER_ARG1}") set(HOST_LDFLAGS "${CMAKE_EXE_LINKER_FLAGS}") - set(LIT_SITE_CFG_IN_HEADER "## Autogenerated from ${site_in}\n## Do not edit!") + string(CONCAT LIT_SITE_CFG_IN_HEADER + "# Autogenerated from ${site_in}\n# Do not edit!\n\n" + "${LLVM_LIT_PATH_FUNCTION}" + ) # Override config_target_triple (and the env) if(LLVM_TARGET_TRIPLE_ENV) # This is expanded into the heading. - string(CONCAT LIT_SITE_CFG_IN_HEADER "${LIT_SITE_CFG_IN_HEADER}\n\n" + string(CONCAT LIT_SITE_CFG_IN_HEADER "${LIT_SITE_CFG_IN_HEADER}" "import os\n" "target_env = \"${LLVM_TARGET_TRIPLE_ENV}\"\n" "config.target_triple = config.environment[target_env] = os.environ.get(target_env, \"${TARGET_TRIPLE}\")\n" @@ -1532,12 +1602,47 @@ function(configure_lit_site_cfg site_in site_out) set(TARGET_TRIPLE "\"+config.target_triple+\"") endif() + if (ARG_PATHS) + # Walk ARG_PATHS and collect the current value of the variables in there. + # list(APPEND) ignores empty elements exactly if the list is empty, + # so start the list with a dummy element and drop it, to make sure that + # even empty values make it into the values list. + set(ARG_PATH_VALUES "dummy") + foreach(path ${ARG_PATHS}) + list(APPEND ARG_PATH_VALUES "${${path}}") + endforeach() + list(REMOVE_AT ARG_PATH_VALUES 0) + + get_filename_component(OUTPUT_DIR ${site_out} DIRECTORY) + make_paths_relative( + ARG_PATH_VALUES_RELATIVE "${OUTPUT_DIR}" "${ARG_PATH_VALUES}") + + list(LENGTH ARG_PATHS len_paths) + list(LENGTH ARG_PATH_VALUES len_path_values) + list(LENGTH ARG_PATH_VALUES_RELATIVE len_path_value_rels) + if ((NOT ${len_paths} EQUAL ${len_path_values}) OR + (NOT ${len_paths} EQUAL ${len_path_value_rels})) + message(SEND_ERROR "PATHS lengths got confused") + endif() + + # Transform variables mentioned in ARG_PATHS to relative paths for + # the configure_file() call. Variables are copied to subscopeds by cmake, + # so this only modifies the local copy of the variables. + math(EXPR arg_path_limit "${len_paths} - 1") + foreach(i RANGE ${arg_path_limit}) + list(GET ARG_PATHS ${i} val1) + list(GET ARG_PATH_VALUES_RELATIVE ${i} val2) + set(${val1} ${val2}) + endforeach() + endif() + configure_file(${site_in} ${site_out} @ONLY) + if (EXISTS "${ARG_MAIN_CONFIG}") - set(PYTHON_STATEMENT "map_config('${ARG_MAIN_CONFIG}', '${site_out}')") - get_property(LLVM_LIT_CONFIG_MAP GLOBAL PROPERTY LLVM_LIT_CONFIG_MAP) - set(LLVM_LIT_CONFIG_MAP "${LLVM_LIT_CONFIG_MAP}\n${PYTHON_STATEMENT}") - set_property(GLOBAL PROPERTY LLVM_LIT_CONFIG_MAP ${LLVM_LIT_CONFIG_MAP}) + # Remember main config / generated site config for llvm-lit.in. + get_property(LLVM_LIT_CONFIG_FILES GLOBAL PROPERTY LLVM_LIT_CONFIG_FILES) + list(APPEND LLVM_LIT_CONFIG_FILES "${ARG_MAIN_CONFIG}" "${site_out}") + set_property(GLOBAL PROPERTY LLVM_LIT_CONFIG_FILES ${LLVM_LIT_CONFIG_FILES}) endif() endfunction() @@ -1615,7 +1720,7 @@ function(add_lit_target target comment) ALLOW_EXTERNAL ) - set(LIT_COMMAND "${PYTHON_EXECUTABLE};${lit_base_dir}/${lit_file_name}") + set(LIT_COMMAND "${Python3_EXECUTABLE};${lit_base_dir}/${lit_file_name}") list(APPEND LIT_COMMAND ${LIT_ARGS}) foreach(param ${ARG_PARAMS}) list(APPEND LIT_COMMAND --param ${param}) @@ -1642,10 +1747,10 @@ endfunction() # A function to add a set of lit test suites to be driven through 'check-*' targets. function(add_lit_testsuite target comment) - cmake_parse_arguments(ARG "" "" "PARAMS;DEPENDS;ARGS" ${ARGN}) + cmake_parse_arguments(ARG "EXCLUDE_FROM_CHECK_ALL" "" "PARAMS;DEPENDS;ARGS" ${ARGN}) # EXCLUDE_FROM_ALL excludes the test ${target} out of check-all. - if(NOT EXCLUDE_FROM_ALL) + if(NOT ARG_EXCLUDE_FROM_CHECK_ALL) # Register the testsuites, params and depends for the global check rule. set_property(GLOBAL APPEND PROPERTY LLVM_LIT_TESTSUITES ${ARG_UNPARSED_ARGUMENTS}) set_property(GLOBAL APPEND PROPERTY LLVM_LIT_PARAMS ${ARG_PARAMS}) @@ -1664,7 +1769,7 @@ endfunction() function(add_lit_testsuites project directory) if (NOT LLVM_ENABLE_IDE) - cmake_parse_arguments(ARG "" "" "PARAMS;DEPENDS;ARGS" ${ARGN}) + cmake_parse_arguments(ARG "EXCLUDE_FROM_CHECK_ALL" "" "PARAMS;DEPENDS;ARGS" ${ARGN}) # Search recursively for test directories by assuming anything not # in a directory called Inputs contains tests. @@ -1687,6 +1792,7 @@ function(add_lit_testsuites project directory) string(TOLOWER "${project}${name_dashes}" name_var) add_lit_target("check-${name_var}" "Running lit suite ${lit_suite}" ${lit_suite} + ${EXCLUDE_FROM_CHECK_ALL} PARAMS ${ARG_PARAMS} DEPENDS ${ARG_DEPENDS} ARGS ${ARG_ARGS} @@ -1996,38 +2102,39 @@ function(setup_dependency_debugging name) set_target_properties(${name} PROPERTIES RULE_LAUNCH_COMPILE ${sandbox_command}) endfunction() +# If the sources at the given `path` are under version control, set `out_var` +# to the the path of a file which will be modified when the VCS revision +# changes, attempting to create that file if it does not exist; if no such +# file exists and one cannot be created, instead set `out_var` to the +# empty string. +# +# If the sources are not under version control, do not define `out_var`. function(find_first_existing_vc_file path out_var) if(NOT EXISTS "${path}") return() endif() - if(EXISTS "${path}/.svn") - set(svn_files - "${path}/.svn/wc.db" # SVN 1.7 - "${path}/.svn/entries" # SVN 1.6 - ) - foreach(file IN LISTS svn_files) - if(EXISTS "${file}") - set(${out_var} "${file}" PARENT_SCOPE) - return() - endif() - endforeach() - else() - find_package(Git) - if(GIT_FOUND) - execute_process(COMMAND ${GIT_EXECUTABLE} rev-parse --git-dir - WORKING_DIRECTORY ${path} - RESULT_VARIABLE git_result - OUTPUT_VARIABLE git_output - ERROR_QUIET) - if(git_result EQUAL 0) - string(STRIP "${git_output}" git_output) - get_filename_component(git_dir ${git_output} ABSOLUTE BASE_DIR ${path}) - # Some branchless cases (e.g. 'repo') may not yet have .git/logs/HEAD - if (NOT EXISTS "${git_dir}/logs/HEAD") - file(WRITE "${git_dir}/logs/HEAD" "") + find_package(Git) + if(GIT_FOUND) + execute_process(COMMAND ${GIT_EXECUTABLE} rev-parse --git-dir + WORKING_DIRECTORY ${path} + RESULT_VARIABLE git_result + OUTPUT_VARIABLE git_output + ERROR_QUIET) + if(git_result EQUAL 0) + string(STRIP "${git_output}" git_output) + get_filename_component(git_dir ${git_output} ABSOLUTE BASE_DIR ${path}) + # Some branchless cases (e.g. 'repo') may not yet have .git/logs/HEAD + if (NOT EXISTS "${git_dir}/logs/HEAD") + execute_process(COMMAND ${CMAKE_COMMAND} -E touch HEAD + WORKING_DIRECTORY "${git_dir}/logs" + RESULT_VARIABLE touch_head_result + ERROR_QUIET) + if (NOT touch_head_result EQUAL 0) + set(${out_var} "" PARENT_SCOPE) + return() endif() - set(${out_var} "${git_dir}/logs/HEAD" PARENT_SCOPE) endif() + set(${out_var} "${git_dir}/logs/HEAD" PARENT_SCOPE) endif() endif() endfunction() diff --git a/gnu/llvm/llvm/cmake/modules/AddSphinxTarget.cmake b/gnu/llvm/llvm/cmake/modules/AddSphinxTarget.cmake index 2bf654b60c4..b5babb30abc 100644 --- a/gnu/llvm/llvm/cmake/modules/AddSphinxTarget.cmake +++ b/gnu/llvm/llvm/cmake/modules/AddSphinxTarget.cmake @@ -18,6 +18,7 @@ endif() # # ``project`` should be the project name function (add_sphinx_target builder project) + cmake_parse_arguments(ARG "" "SOURCE_DIR" "" ${ARGN}) set(SPHINX_BUILD_DIR "${CMAKE_CURRENT_BINARY_DIR}/${builder}") set(SPHINX_DOC_TREE_DIR "${CMAKE_CURRENT_BINARY_DIR}/_doctrees-${project}-${builder}") set(SPHINX_TARGET_NAME docs-${project}-${builder}) @@ -28,13 +29,18 @@ function (add_sphinx_target builder project) set(SPHINX_WARNINGS_AS_ERRORS_FLAG "") endif() + if (NOT ARG_SOURCE_DIR) + set(ARG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}") + endif() + add_custom_target(${SPHINX_TARGET_NAME} COMMAND ${SPHINX_EXECUTABLE} -b ${builder} -d "${SPHINX_DOC_TREE_DIR}" -q # Quiet: no output other than errors and warnings. + -t builder-${builder} # tag for builder ${SPHINX_WARNINGS_AS_ERRORS_FLAG} # Treat warnings as errors if requested - "${CMAKE_CURRENT_SOURCE_DIR}" # Source + "${ARG_SOURCE_DIR}" # Source "${SPHINX_BUILD_DIR}" # Output COMMENT "Generating ${builder} Sphinx documentation for ${project} into \"${SPHINX_BUILD_DIR}\"") diff --git a/gnu/llvm/llvm/cmake/modules/CMakeLists.txt b/gnu/llvm/llvm/cmake/modules/CMakeLists.txt index af757d6199a..4b8879f65fe 100644 --- a/gnu/llvm/llvm/cmake/modules/CMakeLists.txt +++ b/gnu/llvm/llvm/cmake/modules/CMakeLists.txt @@ -28,6 +28,9 @@ endforeach(lib) if(intrinsics_gen IN_LIST LLVM_COMMON_DEPENDS) list(REMOVE_ITEM LLVM_COMMON_DEPENDS intrinsics_gen) endif() +if(omp_gen IN_LIST LLVM_COMMON_DEPENDS) + list(REMOVE_ITEM LLVM_COMMON_DEPENDS omp_gen) +endif() # Generate LLVMConfig.cmake for the build tree. set(LLVM_CONFIG_CODE " @@ -54,6 +57,15 @@ set(LLVM_CONFIG_CMAKE_DIR "${CMAKE_CURRENT_SOURCE_DIR}") set(LLVM_CONFIG_BINARY_DIR "${LLVM_BINARY_DIR}") set(LLVM_CONFIG_TOOLS_BINARY_DIR "${LLVM_TOOLS_BINARY_DIR}") +# Generate a default location for lit +if (LLVM_BUILD_UTILS) + if (CMAKE_HOST_WIN32 AND NOT CYGWIN) + set(LLVM_CONFIG_DEFAULT_EXTERNAL_LIT "${LLVM_CONFIG_TOOLS_BINARY_DIR}/llvm-lit.py") + else() + set(LLVM_CONFIG_DEFAULT_EXTERNAL_LIT "${LLVM_CONFIG_TOOLS_BINARY_DIR}/llvm-lit") + endif() +endif() + if (LLVM_LINK_LLVM_DYLIB) set(LLVM_CONFIG_LINK_LLVM_DYLIB "set(LLVM_LINK_LLVM_DYLIB ${LLVM_LINK_LLVM_DYLIB})") @@ -103,6 +115,12 @@ set(LLVM_CONFIG_LIBRARY_DIRS "\${LLVM_INSTALL_PREFIX}/lib\${LLVM_LIBDIR_SUFFIX}" set(LLVM_CONFIG_CMAKE_DIR "\${LLVM_INSTALL_PREFIX}/${LLVM_INSTALL_PACKAGE_DIR}") set(LLVM_CONFIG_BINARY_DIR "\${LLVM_INSTALL_PREFIX}") set(LLVM_CONFIG_TOOLS_BINARY_DIR "\${LLVM_INSTALL_PREFIX}/bin") + +# Generate a default location for lit +if (LLVM_INSTALL_UTILS AND LLVM_BUILD_UTILS) + set(LLVM_CONFIG_DEFAULT_EXTERNAL_LIT "${LLVM_CONFIG_TOOLS_BINARY_DIR}/llvm-lit") +endif() + set(LLVM_CONFIG_EXPORTS_FILE "\${LLVM_CMAKE_DIR}/LLVMExports.cmake") set(LLVM_CONFIG_EXPORTS "${LLVM_EXPORTS}") configure_file( diff --git a/gnu/llvm/llvm/cmake/modules/CheckAtomic.cmake b/gnu/llvm/llvm/cmake/modules/CheckAtomic.cmake index 29f3bdd57f0..d0b75f3bcc9 100644 --- a/gnu/llvm/llvm/cmake/modules/CheckAtomic.cmake +++ b/gnu/llvm/llvm/cmake/modules/CheckAtomic.cmake @@ -12,8 +12,12 @@ function(check_working_cxx_atomics varname) CHECK_CXX_SOURCE_COMPILES(" #include std::atomic x; +std::atomic y; +std::atomic z; int main() { - return x; + ++z; + ++y; + return ++x; } " ${varname}) set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS}) @@ -35,19 +39,20 @@ int main() { endfunction(check_working_cxx_atomics64) -# This isn't necessary on MSVC, so avoid command-line switch annoyance -# by only running on GCC-like hosts. -if (LLVM_COMPILER_IS_GCC_COMPATIBLE) +# Check for (non-64-bit) atomic operations. +if(MSVC) + set(HAVE_CXX_ATOMICS_WITHOUT_LIB True) +elseif(LLVM_COMPILER_IS_GCC_COMPATIBLE) # First check if atomics work without the library. check_working_cxx_atomics(HAVE_CXX_ATOMICS_WITHOUT_LIB) # If not, check if the library exists, and atomics work with it. if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB) check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC) - if( HAVE_LIBATOMIC ) + if(HAVE_LIBATOMIC) list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic") check_working_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB) if (NOT HAVE_CXX_ATOMICS_WITH_LIB) - message(FATAL_ERROR "Host compiler must support std::atomic!") + message(FATAL_ERROR "Host compiler must support std::atomic!") endif() else() message(FATAL_ERROR "Host compiler appears to require libatomic, but cannot find it.") @@ -58,21 +63,21 @@ endif() # Check for 64 bit atomic operations. if(MSVC) set(HAVE_CXX_ATOMICS64_WITHOUT_LIB True) -else() +elseif(LLVM_COMPILER_IS_GCC_COMPATIBLE) + # First check if atomics work without the library. check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITHOUT_LIB) -endif() - -# If not, check if the library exists, and atomics work with it. -if(NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB) - check_library_exists(atomic __atomic_load_8 "" HAVE_CXX_LIBATOMICS64) - if(HAVE_CXX_LIBATOMICS64) - list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic") - check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITH_LIB) - if (NOT HAVE_CXX_ATOMICS64_WITH_LIB) - message(FATAL_ERROR "Host compiler must support 64-bit std::atomic!") + # If not, check if the library exists, and atomics work with it. + if(NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB) + check_library_exists(atomic __atomic_load_8 "" HAVE_CXX_LIBATOMICS64) + if(HAVE_CXX_LIBATOMICS64) + list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic") + check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITH_LIB) + if (NOT HAVE_CXX_ATOMICS64_WITH_LIB) + message(FATAL_ERROR "Host compiler must support 64-bit std::atomic!") + endif() + else() + message(FATAL_ERROR "Host compiler appears to require libatomic for 64-bit operations, but cannot find it.") endif() - else() - message(FATAL_ERROR "Host compiler appears to require libatomic for 64-bit operations, but cannot find it.") endif() endif() diff --git a/gnu/llvm/llvm/cmake/modules/CrossCompile.cmake b/gnu/llvm/llvm/cmake/modules/CrossCompile.cmake index 8a6e880c4e2..01cd3712484 100644 --- a/gnu/llvm/llvm/cmake/modules/CrossCompile.cmake +++ b/gnu/llvm/llvm/cmake/modules/CrossCompile.cmake @@ -6,7 +6,7 @@ function(llvm_create_cross_target project_name target_name toolchain buildtype) if(NOT DEFINED ${project_name}_${target_name}_BUILD) set(${project_name}_${target_name}_BUILD - "${CMAKE_BINARY_DIR}/${target_name}") + "${CMAKE_CURRENT_BINARY_DIR}/${target_name}") set(${project_name}_${target_name}_BUILD ${${project_name}_${target_name}_BUILD} PARENT_SCOPE) message(STATUS "Setting native build dir to " ${${project_name}_${target_name}_BUILD}) @@ -68,7 +68,7 @@ function(llvm_create_cross_target project_name target_name toolchain buildtype) add_custom_command(OUTPUT ${${project_name}_${target_name}_BUILD}/CMakeCache.txt COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}" -DCMAKE_MAKE_PROGRAM="${CMAKE_MAKE_PROGRAM}" - ${CROSS_TOOLCHAIN_FLAGS_${target_name}} ${CMAKE_SOURCE_DIR} + ${CROSS_TOOLCHAIN_FLAGS_${target_name}} ${CMAKE_CURRENT_SOURCE_DIR} ${CROSS_TOOLCHAIN_FLAGS_${project_name}_${target_name}} -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE -DLLVM_TARGETS_TO_BUILD="${targets_to_build_arg}" @@ -99,17 +99,17 @@ function(build_native_tool target output_path_var) cmake_parse_arguments(ARG "" "" "DEPENDS" ${ARGN}) if(CMAKE_CONFIGURATION_TYPES) - set(output_path "${${CMAKE_PROJECT_NAME}_NATIVE_BUILD}/Release/bin/${target}") + set(output_path "${${PROJECT_NAME}_NATIVE_BUILD}/Release/bin/${target}") else() - set(output_path "${${CMAKE_PROJECT_NAME}_NATIVE_BUILD}/bin/${target}") + set(output_path "${${PROJECT_NAME}_NATIVE_BUILD}/bin/${target}") endif() - llvm_ExternalProject_BuildCmd(build_cmd ${target} ${${CMAKE_PROJECT_NAME}_NATIVE_BUILD} + llvm_ExternalProject_BuildCmd(build_cmd ${target} ${${PROJECT_NAME}_NATIVE_BUILD} CONFIGURATION Release) add_custom_command(OUTPUT "${output_path}" COMMAND ${build_cmd} - DEPENDS CONFIGURE_${CMAKE_PROJECT_NAME}_NATIVE ${ARG_DEPENDS} - WORKING_DIRECTORY "${${CMAKE_PROJECT_NAME}_NATIVE_BUILD}" + DEPENDS CONFIGURE_${PROJECT_NAME}_NATIVE ${ARG_DEPENDS} + WORKING_DIRECTORY "${${PROJECT_NAME}_NATIVE_BUILD}" COMMENT "Building native ${target}..." USES_TERMINAL) set(${output_path_var} "${output_path}" PARENT_SCOPE) diff --git a/gnu/llvm/llvm/cmake/modules/FindGRPC.cmake b/gnu/llvm/llvm/cmake/modules/FindGRPC.cmake new file mode 100644 index 00000000000..8a0ca593b2f --- /dev/null +++ b/gnu/llvm/llvm/cmake/modules/FindGRPC.cmake @@ -0,0 +1,83 @@ +# This setup requires gRPC to be built from sources using CMake and installed to +# ${GRPC_INSTALL_PATH} via -DCMAKE_INSTALL_PREFIX=${GRPC_INSTALL_PATH}. +# FIXME(kirillbobyrev): Check if gRPC and Protobuf headers can be included at +# configure time. +if (GRPC_INSTALL_PATH) + set(protobuf_MODULE_COMPATIBLE TRUE) + find_package(Protobuf CONFIG REQUIRED HINTS ${GRPC_INSTALL_PATH}) + message(STATUS "Using protobuf ${protobuf_VERSION}") + find_package(gRPC CONFIG REQUIRED HINTS ${GRPC_INSTALL_PATH}) + message(STATUS "Using gRPC ${gRPC_VERSION}") + + include_directories(${Protobuf_INCLUDE_DIRS}) + + # gRPC CMake CONFIG gives the libraries slightly odd names, make them match + # the conventional system-installed names. + set_target_properties(protobuf::libprotobuf PROPERTIES IMPORTED_GLOBAL TRUE) + add_library(protobuf ALIAS protobuf::libprotobuf) + set_target_properties(gRPC::grpc++ PROPERTIES IMPORTED_GLOBAL TRUE) + add_library(grpc++ ALIAS gRPC::grpc++) + + set(GRPC_CPP_PLUGIN $) + set(PROTOC ${Protobuf_PROTOC_EXECUTABLE}) +else() + find_program(GRPC_CPP_PLUGIN grpc_cpp_plugin) + find_program(PROTOC protoc) + if (GRPC_CPP_PLUGIN-NOTFOUND OR PROTOC-NOTFOUND) + message(FATAL_ERROR "gRPC C++ Plugin and Protoc must be on $PATH for Clangd remote index build") + endif() + # On macOS the libraries are typically installed via Homebrew and are not on + # the system path. + if (${APPLE}) + find_program(HOMEBREW brew) + # If Homebrew is not found, the user might have installed libraries + # manually. Fall back to the system path. + if (NOT HOMEBREW-NOTFOUND) + execute_process(COMMAND ${HOMEBREW} --prefix grpc + OUTPUT_VARIABLE GRPC_HOMEBREW_PATH + RESULT_VARIABLE GRPC_HOMEBREW_RETURN_CODE + OUTPUT_STRIP_TRAILING_WHITESPACE) + execute_process(COMMAND ${HOMEBREW} --prefix protobuf + OUTPUT_VARIABLE PROTOBUF_HOMEBREW_PATH + RESULT_VARIABLE PROTOBUF_HOMEBREW_RETURN_CODE + OUTPUT_STRIP_TRAILING_WHITESPACE) + # If either library is not installed via Homebrew, fall back to the + # system path. + if (GRPC_HOMEBREW_RETURN_CODE EQUAL "0") + include_directories(${GRPC_HOMEBREW_PATH}/include) + link_directories(${GRPC_HOMEBREW_PATH}/lib) + endif() + if (PROTOBUF_HOMEBREW_RETURN_CODE EQUAL "0") + include_directories(${PROTOBUF_HOMEBREW_PATH}/include) + link_directories(${PROTOBUF_HOMEBREW_PATH}/lib) + endif() + endif() + endif() +endif() + +# Proto headers are generated in ${CMAKE_CURRENT_BINARY_DIR}. +# Libraries that use these headers should adjust the include path. +# FIXME(kirillbobyrev): Allow optional generation of gRPC code and give callers +# control over it via additional parameters. +function(generate_grpc_protos LibraryName ProtoFile) + get_filename_component(ProtoSourceAbsolutePath "${CMAKE_CURRENT_SOURCE_DIR}/${ProtoFile}" ABSOLUTE) + get_filename_component(ProtoSourcePath ${ProtoSourceAbsolutePath} PATH) + + set(GeneratedProtoSource "${CMAKE_CURRENT_BINARY_DIR}/Index.pb.cc") + set(GeneratedProtoHeader "${CMAKE_CURRENT_BINARY_DIR}/Index.pb.h") + set(GeneratedGRPCSource "${CMAKE_CURRENT_BINARY_DIR}/Index.grpc.pb.cc") + set(GeneratedGRPCHeader "${CMAKE_CURRENT_BINARY_DIR}/Index.grpc.pb.h") + add_custom_command( + OUTPUT "${GeneratedProtoSource}" "${GeneratedProtoHeader}" "${GeneratedGRPCSource}" "${GeneratedGRPCHeader}" + COMMAND ${PROTOC} + ARGS --grpc_out="${CMAKE_CURRENT_BINARY_DIR}" + --cpp_out="${CMAKE_CURRENT_BINARY_DIR}" + --proto_path="${ProtoSourcePath}" + --plugin=protoc-gen-grpc="${GRPC_CPP_PLUGIN}" + "${ProtoSourceAbsolutePath}" + DEPENDS "${ProtoSourceAbsolutePath}") + + add_clang_library(${LibraryName} ${GeneratedProtoSource} ${GeneratedGRPCSource} + PARTIAL_SOURCES_INTENDED + LINK_LIBS grpc++ protobuf) +endfunction() diff --git a/gnu/llvm/llvm/cmake/modules/FindZ3.cmake b/gnu/llvm/llvm/cmake/modules/FindZ3.cmake index 04294275535..95dd37789a8 100644 --- a/gnu/llvm/llvm/cmake/modules/FindZ3.cmake +++ b/gnu/llvm/llvm/cmake/modules/FindZ3.cmake @@ -27,7 +27,7 @@ function(check_z3_version z3_include z3_lib) ) if(Z3_COMPILED) - string(REGEX REPLACE "([0-9]*\\.[0-9]*\\.[0-9]*\\.[0-9]*)" "\\1" + string(REGEX REPLACE "([0-9]*\\.[0-9]*\\.[0-9]*)" "\\1" z3_version "${SRC_OUTPUT}") set(Z3_VERSION_STRING ${z3_version} PARENT_SCOPE) endif() diff --git a/gnu/llvm/llvm/cmake/modules/GetHostTriple.cmake b/gnu/llvm/llvm/cmake/modules/GetHostTriple.cmake index 6c15e2d4896..251ca1a32b1 100644 --- a/gnu/llvm/llvm/cmake/modules/GetHostTriple.cmake +++ b/gnu/llvm/llvm/cmake/modules/GetHostTriple.cmake @@ -14,6 +14,13 @@ function( get_host_triple var ) else() set( value "i686-pc-windows-gnu" ) endif() + elseif( CMAKE_HOST_SYSTEM_NAME STREQUAL AIX ) + # We defer to dynamic detection of the host AIX version. + if( CMAKE_SIZEOF_VOID_P EQUAL 8 ) + set( value "powerpc64-ibm-aix" ) + else() + set( value "powerpc-ibm-aix" ) + endif() else( MSVC ) if(CMAKE_HOST_SYSTEM_NAME STREQUAL Windows AND NOT MSYS) message(WARNING "unable to determine host target triple") @@ -26,8 +33,7 @@ function( get_host_triple var ) if( NOT TT_RV EQUAL 0 ) message(FATAL_ERROR "Failed to execute ${config_guess}") endif( NOT TT_RV EQUAL 0 ) - # Defer to dynamic detection of the host AIX version. - string(REGEX REPLACE "-aix[0-9][^-]*" "-aix" value ${TT_OUT}) + set( value ${TT_OUT} ) endif() endif( MSVC ) set( ${var} ${value} PARENT_SCOPE ) diff --git a/gnu/llvm/llvm/cmake/modules/HandleLLVMOptions.cmake b/gnu/llvm/llvm/cmake/modules/HandleLLVMOptions.cmake index 30f04ca34c2..5ef22eb493b 100644 --- a/gnu/llvm/llvm/cmake/modules/HandleLLVMOptions.cmake +++ b/gnu/llvm/llvm/cmake/modules/HandleLLVMOptions.cmake @@ -11,8 +11,10 @@ include(HandleLLVMStdlib) include(CheckCCompilerFlag) include(CheckCXXCompilerFlag) include(CheckSymbolExists) +include(CMakeDependentOption) +include(LLVMProcessSources) -if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL "lld") OR LLVM_ENABLE_LLD) +if(CMAKE_LINKER MATCHES "lld-link" OR (MSVC AND (LLVM_USE_LINKER STREQUAL "lld" OR LLVM_ENABLE_LLD))) set(LINKER_IS_LLD_LINK TRUE) else() set(LINKER_IS_LLD_LINK FALSE) @@ -26,7 +28,7 @@ string(TOUPPER "${LLVM_ENABLE_LTO}" uppercase_LLVM_ENABLE_LTO) set(LLVM_PARALLEL_COMPILE_JOBS "" CACHE STRING "Define the maximum number of concurrent compilation jobs (Ninja only).") if(LLVM_PARALLEL_COMPILE_JOBS) - if(NOT CMAKE_MAKE_PROGRAM MATCHES "ninja") + if(NOT CMAKE_GENERATOR STREQUAL "Ninja") message(WARNING "Job pooling is only available with Ninja generators.") else() set_property(GLOBAL APPEND PROPERTY JOB_POOLS compile_job_pool=${LLVM_PARALLEL_COMPILE_JOBS}) @@ -36,7 +38,7 @@ endif() set(LLVM_PARALLEL_LINK_JOBS "" CACHE STRING "Define the maximum number of concurrent link jobs (Ninja only).") -if(CMAKE_MAKE_PROGRAM MATCHES "ninja") +if(CMAKE_GENERATOR STREQUAL "Ninja") if(NOT LLVM_PARALLEL_LINK_JOBS AND uppercase_LLVM_ENABLE_LTO STREQUAL "THIN") message(STATUS "ThinLTO provides its own parallel linking - limiting parallel link jobs to 2.") set(LLVM_PARALLEL_LINK_JOBS "2") @@ -57,7 +59,10 @@ if( LLVM_ENABLE_ASSERTIONS ) # On non-Debug builds cmake automatically defines NDEBUG, so we # explicitly undefine it: if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) - add_definitions( -UNDEBUG ) + # NOTE: use `add_compile_options` rather than `add_definitions` since + # `add_definitions` does not support generator expressions. + add_compile_options($<$,$>:-UNDEBUG>) + # Also remove /D NDEBUG to avoid MSVC warnings about conflicting defines. foreach (flags_var_to_scrub CMAKE_CXX_FLAGS_RELEASE @@ -74,7 +79,26 @@ endif() if(LLVM_ENABLE_EXPENSIVE_CHECKS) add_definitions(-DEXPENSIVE_CHECKS) - add_definitions(-D_GLIBCXX_DEBUG) + + # In some libstdc++ versions, std::min_element is not constexpr when + # _GLIBCXX_DEBUG is enabled. + CHECK_CXX_SOURCE_COMPILES(" + #define _GLIBCXX_DEBUG + #include + int main(int argc, char** argv) { + static constexpr int data[] = {0, 1}; + constexpr const int* min_elt = std::min_element(&data[0], &data[2]); + return 0; + }" CXX_SUPPORTS_GLIBCXX_DEBUG) + if(CXX_SUPPORTS_GLIBCXX_DEBUG) + add_definitions(-D_GLIBCXX_DEBUG) + else() + add_definitions(-D_GLIBCXX_ASSERTIONS) + endif() +endif() + +if (LLVM_ENABLE_STRICT_FIXED_SIZE_VECTORS) + add_definitions(-DSTRICT_FIXED_SIZE_VECTORS) endif() string(TOUPPER "${LLVM_ABI_BREAKING_CHECKS}" uppercase_LLVM_ABI_BREAKING_CHECKS) @@ -137,13 +161,21 @@ endif() if(${CMAKE_SYSTEM_NAME} MATCHES "Linux") # RHEL7 has ar and ranlib being non-deterministic by default. The D flag forces determinism, - # however only GNU version of ar and ranlib (2.27) have this option. + # however only GNU version of ar and ranlib (2.27) have this option. # RHEL DTS7 is also affected by this, which uses GNU binutils 2.28 execute_process(COMMAND ${CMAKE_AR} rD t.a - WORKING_DIRECTORY ${CMAKE_BINARY_DIR} RESULT_VARIABLE AR_RESULT OUTPUT_VARIABLE RANLIB_OUTPUT) + WORKING_DIRECTORY ${CMAKE_BINARY_DIR} + RESULT_VARIABLE AR_RESULT + OUTPUT_QUIET + ERROR_QUIET + ) if(${AR_RESULT} EQUAL 0) execute_process(COMMAND ${CMAKE_RANLIB} -D t.a - WORKING_DIRECTORY ${CMAKE_BINARY_DIR} RESULT_VARIABLE RANLIB_RESULT OUTPUT_VARIABLE RANLIB_OUTPUT) + WORKING_DIRECTORY ${CMAKE_BINARY_DIR} + RESULT_VARIABLE RANLIB_RESULT + OUTPUT_QUIET + ERROR_QUIET + ) if(${RANLIB_RESULT} EQUAL 0) set(CMAKE_C_ARCHIVE_CREATE " Dqc ") set(CMAKE_C_ARCHIVE_APPEND " Dq ") @@ -158,17 +190,6 @@ if(${CMAKE_SYSTEM_NAME} MATCHES "Linux") endif() if(${CMAKE_SYSTEM_NAME} MATCHES "AIX") - if(NOT LLVM_BUILD_32_BITS) - if (CMAKE_CXX_COMPILER_ID MATCHES "XL") - append("-q64" CMAKE_CXX_FLAGS CMAKE_C_FLAGS) - else() - append("-maix64" CMAKE_CXX_FLAGS CMAKE_C_FLAGS) - endif() - set(CMAKE_CXX_ARCHIVE_CREATE " -X64 qc ") - set(CMAKE_CXX_ARCHIVE_APPEND " -X64 q ") - set(CMAKE_C_ARCHIVE_FINISH " -X64 ") - set(CMAKE_CXX_ARCHIVE_FINISH " -X64 ") - endif() # -fPIC does not enable the large code model for GCC on AIX but does for XL. if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU") append("-mcmodel=large" CMAKE_CXX_FLAGS CMAKE_C_FLAGS) @@ -176,6 +197,12 @@ if(${CMAKE_SYSTEM_NAME} MATCHES "AIX") # XL generates a small number of relocations not of the large model, -bbigtoc is needed. append("-Wl,-bbigtoc" CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS) + # The default behaviour on AIX processes dynamic initialization of non-local variables with + # static storage duration even for archive members that are otherwise unreferenced. + # Since `--whole-archive` is not used by the LLVM build to keep such initializations for Linux, + # we can limit the processing for archive members to only those that are otherwise referenced. + append("-bcdtors:mbr" + CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS) endif() endif() @@ -265,6 +292,15 @@ if( LLVM_ENABLE_PIC ) NOT Uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") add_flag_or_print_warning("-fno-shrink-wrap" FNO_SHRINK_WRAP) endif() + # gcc with -O3 -fPIC generates TLS sequences that violate the spec on + # Solaris/sparcv9, causing executables created with the system linker + # to SEGV (GCC PR target/96607). + # clang with -O3 -fPIC generates code that SEGVs. + # Both can be worked around by compiling with -O instead. + if(${CMAKE_SYSTEM_NAME} STREQUAL "SunOS" AND LLVM_NATIVE_ARCH STREQUAL "Sparc") + llvm_replace_compiler_option(CMAKE_CXX_FLAGS_RELEASE "-O[23]" "-O") + llvm_replace_compiler_option(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O[23]" "-O") + endif() endif() if(NOT WIN32 AND NOT CYGWIN AND NOT (${CMAKE_SYSTEM_NAME} MATCHES "AIX" AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU")) @@ -499,7 +535,6 @@ if (MSVC) -wd4244 # Suppress ''argument' : conversion from 'type1' to 'type2', possible loss of data' -wd4267 # Suppress ''var' : conversion from 'size_t' to 'type', possible loss of data' -wd4291 # Suppress ''declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception' - -wd4345 # Suppress 'behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized' -wd4351 # Suppress 'new behavior: elements of array 'array' will be default initialized' -wd4456 # Suppress 'declaration of 'var' hides local variable' -wd4457 # Suppress 'declaration of 'var' hides function parameter' @@ -710,6 +745,8 @@ if(LLVM_USE_SANITIZER) elseif (LLVM_USE_SANITIZER STREQUAL "Thread") append_common_sanitizer_flags() append("-fsanitize=thread" CMAKE_C_FLAGS CMAKE_CXX_FLAGS) + elseif (LLVM_USE_SANITIZER STREQUAL "DataFlow") + append("-fsanitize=dataflow" CMAKE_C_FLAGS CMAKE_CXX_FLAGS) elseif (LLVM_USE_SANITIZER STREQUAL "Address;Undefined" OR LLVM_USE_SANITIZER STREQUAL "Undefined;Address") append_common_sanitizer_flags() @@ -747,9 +784,15 @@ if(LLVM_USE_SANITIZER) endif() endif() -# Turn on -gsplit-dwarf if requested -if(LLVM_USE_SPLIT_DWARF) - add_definitions("-gsplit-dwarf") +# Turn on -gsplit-dwarf if requested in debug builds. +if (LLVM_USE_SPLIT_DWARF AND + ((uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") OR + (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO"))) + # Limit to clang and gcc so far. Add compilers supporting this option. + if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" OR + CMAKE_CXX_COMPILER_ID STREQUAL "GNU") + add_compile_options(-gsplit-dwarf) + endif() endif() add_definitions( -D__STDC_CONSTANT_MACROS ) @@ -782,9 +825,11 @@ if(NOT CYGWIN AND NOT WIN32) NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") check_c_compiler_flag("-Werror -fno-function-sections" C_SUPPORTS_FNO_FUNCTION_SECTIONS) if (C_SUPPORTS_FNO_FUNCTION_SECTIONS) - # Don't add -ffunction-section if it can be disabled with -fno-function-sections. + # Don't add -ffunction-sections if it can't be disabled with -fno-function-sections. # Doing so will break sanitizers. add_flag_if_supported("-ffunction-sections" FFUNCTION_SECTIONS) + elseif (CMAKE_CXX_COMPILER_ID MATCHES "XL") + append("-qfuncsect" CMAKE_C_FLAGS CMAKE_CXX_FLAGS) endif() add_flag_if_supported("-fdata-sections" FDATA_SECTIONS) endif() @@ -858,6 +903,28 @@ if (LLVM_BUILD_INSTRUMENTED) endif() endif() +# When using clang-cl with an instrumentation-based tool, add clang's library +# resource directory to the library search path. Because cmake invokes the +# linker directly, it isn't sufficient to pass -fsanitize=* to the linker. +if (CLANG_CL AND (LLVM_BUILD_INSTRUMENTED OR LLVM_USE_SANITIZER)) + execute_process( + COMMAND ${CMAKE_CXX_COMPILER} /clang:-print-resource-dir + OUTPUT_VARIABLE clang_resource_dir + ERROR_VARIABLE clang_cl_stderr + OUTPUT_STRIP_TRAILING_WHITESPACE + ERROR_STRIP_TRAILING_WHITESPACE + RESULT_VARIABLE clang_cl_exit_code) + if (NOT "${clang_cl_exit_code}" STREQUAL "0") + message(FATAL_ERROR + "Unable to invoke clang-cl to find resource dir: ${clang_cl_stderr}") + endif() + file(TO_CMAKE_PATH "${clang_resource_dir}" clang_resource_dir) + append("/libpath:${clang_resource_dir}/lib/windows" + CMAKE_EXE_LINKER_FLAGS + CMAKE_MODULE_LINKER_FLAGS + CMAKE_SHARED_LINKER_FLAGS) +endif() + if(LLVM_PROFDATA_FILE AND EXISTS ${LLVM_PROFDATA_FILE}) if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" ) append("-fprofile-instr-use=\"${LLVM_PROFDATA_FILE}\"" @@ -885,7 +952,7 @@ if (LLVM_BUILD_INSTRUMENTED AND LLVM_BUILD_INSTRUMENTED_COVERAGE) message(FATAL_ERROR "LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE cannot both be specified") endif() -if(LLVM_ENABLE_LTO AND LLVM_ON_WIN32 AND NOT LINKER_IS_LLD_LINK) +if(LLVM_ENABLE_LTO AND LLVM_ON_WIN32 AND NOT LINKER_IS_LLD_LINK AND NOT MINGW) message(FATAL_ERROR "When compiling for Windows, LLVM_ENABLE_LTO requires using lld as the linker (point CMAKE_LINKER at lld-link.exe)") endif() if(uppercase_LLVM_ENABLE_LTO STREQUAL "THIN") @@ -900,7 +967,7 @@ if(uppercase_LLVM_ENABLE_LTO STREQUAL "THIN") if(APPLE) append("-Wl,-cache_path_lto,${PROJECT_BINARY_DIR}/lto.cache" CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS) - elseif(UNIX AND LLVM_USE_LINKER STREQUAL "lld") + elseif((UNIX OR MINGW) AND LLVM_USE_LINKER STREQUAL "lld") append("-Wl,--thinlto-cache-dir=${PROJECT_BINARY_DIR}/lto.cache" CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS) elseif(LLVM_USE_LINKER STREQUAL "gold") @@ -922,12 +989,23 @@ elseif(LLVM_ENABLE_LTO) endif() endif() +# Set an AIX default for LLVM_EXPORT_SYMBOLS_FOR_PLUGINS based on whether we are +# doing dynamic linking (see below). +set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default OFF) +if (NOT (BUILD_SHARED_LIBS OR LLVM_LINK_LLVM_DYLIB)) + set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default ON) +endif() + # This option makes utils/extract_symbols.py be used to determine the list of -# symbols to export from LLVM tools. This is necessary when using MSVC if you -# want to allow plugins, though note that the plugin has to explicitly link -# against (exactly one) tool so we can't unilaterally turn on +# symbols to export from LLVM tools. This is necessary when on AIX or when using +# MSVC if you want to allow plugins. On AIX we don't show this option, and we +# enable it by default except when the LLVM libraries are set up for dynamic +# linking (due to incompatibility). With MSVC, note that the plugin has to +# explicitly link against (exactly one) tool so we can't unilaterally turn on # LLVM_ENABLE_PLUGINS when it's enabled. -option(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS "Export symbols from LLVM tools so that plugins can import them" OFF) +CMAKE_DEPENDENT_OPTION(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS + "Export symbols from LLVM tools so that plugins can import them" OFF + "NOT ${CMAKE_SYSTEM_NAME} MATCHES AIX" ${LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default}) if(BUILD_SHARED_LIBS AND LLVM_EXPORT_SYMBOLS_FOR_PLUGINS) message(FATAL_ERROR "BUILD_SHARED_LIBS not compatible with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS") endif() @@ -993,8 +1071,9 @@ if(macos_signposts_available) endif() endif() +set(LLVM_SOURCE_PREFIX "" CACHE STRING "Use prefix for sources") + option(LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO "Use relative paths in debug info" OFF) -set(LLVM_SOURCE_PREFIX "" CACHE STRING "Use prefix for sources in debug info") if(LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO) check_c_compiler_flag("-fdebug-prefix-map=foo=bar" SUPPORTS_FDEBUG_PREFIX_MAP) @@ -1008,3 +1087,18 @@ if(LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO) append_if(SUPPORTS_FDEBUG_PREFIX_MAP "-fdebug-prefix-map=${source_root}/=${LLVM_SOURCE_PREFIX}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS) add_flag_if_supported("-no-canonical-prefixes" NO_CANONICAL_PREFIXES) endif() + +option(LLVM_USE_RELATIVE_PATHS_IN_FILES "Use relative paths in sources and debug info" OFF) + +if(LLVM_USE_RELATIVE_PATHS_IN_FILES) + check_c_compiler_flag("-ffile-prefix-map=foo=bar" SUPPORTS_FFILE_PREFIX_MAP) + if(LLVM_ENABLE_PROJECTS_USED) + get_filename_component(source_root "${LLVM_MAIN_SRC_DIR}/.." ABSOLUTE) + else() + set(source_root "${LLVM_MAIN_SRC_DIR}") + endif() + file(RELATIVE_PATH relative_root "${source_root}" "${CMAKE_BINARY_DIR}") + append_if(SUPPORTS_FFILE_PREFIX_MAP "-ffile-prefix-map=${CMAKE_BINARY_DIR}=${relative_root}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS) + append_if(SUPPORTS_FFILE_PREFIX_MAP "-ffile-prefix-map=${source_root}/=${LLVM_SOURCE_PREFIX}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS) + add_flag_if_supported("-no-canonical-prefixes" NO_CANONICAL_PREFIXES) +endif() diff --git a/gnu/llvm/llvm/cmake/modules/LLVM-Config.cmake b/gnu/llvm/llvm/cmake/modules/LLVM-Config.cmake index c3fa59e8335..76d4d3e8dbb 100644 --- a/gnu/llvm/llvm/cmake/modules/LLVM-Config.cmake +++ b/gnu/llvm/llvm/cmake/modules/LLVM-Config.cmake @@ -171,13 +171,6 @@ function(llvm_expand_pseudo_components out_components) list(APPEND expanded_components "${t}CodeGen") endif() endforeach(t) - elseif( c STREQUAL "AllTargetsAsmPrinters" ) - # Link all the asm printers from all the targets - foreach(t ${LLVM_TARGETS_TO_BUILD}) - if( TARGET LLVM${t}AsmPrinter ) - list(APPEND expanded_components "${t}AsmPrinter") - endif() - endforeach(t) elseif( c STREQUAL "AllTargetsAsmParsers" ) # Link all the asm parsers from all the targets foreach(t ${LLVM_TARGETS_TO_BUILD}) diff --git a/gnu/llvm/llvm/cmake/modules/LLVMConfig.cmake.in b/gnu/llvm/llvm/cmake/modules/LLVMConfig.cmake.in index 87684ecba0f..4d8e33711d2 100644 --- a/gnu/llvm/llvm/cmake/modules/LLVMConfig.cmake.in +++ b/gnu/llvm/llvm/cmake/modules/LLVMConfig.cmake.in @@ -7,6 +7,7 @@ set(LLVM_VERSION_MINOR @LLVM_VERSION_MINOR@) set(LLVM_VERSION_PATCH @LLVM_VERSION_PATCH@) set(LLVM_VERSION_SUFFIX @LLVM_VERSION_SUFFIX@) set(LLVM_PACKAGE_VERSION @PACKAGE_VERSION@) +set(LLVM_PACKAGE_BUGREPORT @PACKAGE_BUGREPORT@) set(LLVM_BUILD_TYPE @CMAKE_BUILD_TYPE@) @@ -93,6 +94,7 @@ set(LLVM_CMAKE_DIR "@LLVM_CONFIG_CMAKE_DIR@") set(LLVM_BINARY_DIR "@LLVM_CONFIG_BINARY_DIR@") set(LLVM_TOOLS_BINARY_DIR "@LLVM_CONFIG_TOOLS_BINARY_DIR@") set(LLVM_TOOLS_INSTALL_DIR "@LLVM_TOOLS_INSTALL_DIR@") +set(LLVM_DEFAULT_EXTERNAL_LIT "@LLVM_CONFIG_DEFAULT_EXTERNAL_LIT@") set(LLVM_HAVE_OPT_VIEWER_MODULES @LLVM_HAVE_OPT_VIEWER_MODULES@) set(LLVM_CONFIGURATION_TYPES @CMAKE_CONFIGURATION_TYPES@) set(LLVM_ENABLE_SHARED_LIBS @BUILD_SHARED_LIBS@) @@ -103,12 +105,18 @@ if(NOT TARGET LLVMSupport) @llvm_config_include_buildtree_only_exports@ endif() -# By creating intrinsics_gen here, subprojects that depend on LLVM's -# tablegen-generated headers can always depend on this target whether building -# in-tree with LLVM or not. +# By creating intrinsics_gen, omp_gen and acc_gen here, subprojects that depend +# on LLVM's tablegen-generated headers can always depend on this target whether +# building in-tree with LLVM or not. if(NOT TARGET intrinsics_gen) add_custom_target(intrinsics_gen) endif() +if(NOT TARGET omp_gen) + add_custom_target(omp_gen) +endif() +if(NOT TARGET acc_gen) + add_custom_target(acc_gen) +endif() set_property(GLOBAL PROPERTY LLVM_TARGETS_CONFIGURED On) include(${LLVM_CMAKE_DIR}/LLVM-Config.cmake) diff --git a/gnu/llvm/llvm/cmake/modules/LLVMExternalProjectUtils.cmake b/gnu/llvm/llvm/cmake/modules/LLVMExternalProjectUtils.cmake index 75f442b37e1..706a1ffb5c7 100644 --- a/gnu/llvm/llvm/cmake/modules/LLVMExternalProjectUtils.cmake +++ b/gnu/llvm/llvm/cmake/modules/LLVMExternalProjectUtils.cmake @@ -45,16 +45,34 @@ function(llvm_ExternalProject_Add name source_dir) "CMAKE_ARGS;TOOLCHAIN_TOOLS;RUNTIME_LIBRARIES;DEPENDS;EXTRA_TARGETS;PASSTHROUGH_PREFIXES;STRIP_TOOL" ${ARGN}) canonicalize_tool_name(${name} nameCanon) + + foreach(arg ${ARG_CMAKE_ARGS}) + if(arg MATCHES "^-DCMAKE_SYSTEM_NAME=") + string(REGEX REPLACE "^-DCMAKE_SYSTEM_NAME=(.*)$" "\\1" _cmake_system_name "${arg}") + endif() + endforeach() + if(NOT ARG_TOOLCHAIN_TOOLS) - set(ARG_TOOLCHAIN_TOOLS clang lld) - if(NOT APPLE AND NOT WIN32) - list(APPEND ARG_TOOLCHAIN_TOOLS llvm-ar llvm-lipo llvm-ranlib llvm-nm llvm-objcopy llvm-objdump llvm-strip) + set(ARG_TOOLCHAIN_TOOLS clang lld llvm-ar llvm-lipo llvm-ranlib llvm-nm llvm-objdump) + if(NOT _cmake_system_name STREQUAL Darwin) + # TODO: These tools don't fully support Mach-O format yet. + list(APPEND ARG_TOOLCHAIN_TOOLS llvm-objcopy llvm-strip) endif() endif() foreach(tool ${ARG_TOOLCHAIN_TOOLS}) if(TARGET ${tool}) list(APPEND TOOLCHAIN_TOOLS ${tool}) - list(APPEND TOOLCHAIN_BINS $) + + # $ only works on add_executable or add_library targets + # The below logic mirrors cmake's own implementation + get_target_property(target_type "${tool}" TYPE) + if(NOT target_type STREQUAL "OBJECT_LIBRARY" AND + NOT target_type STREQUAL "UTILITY" AND + NOT target_type STREQUAL "GLOBAL_TARGET" AND + NOT target_type STREQUAL "INTERFACE_LIBRARY") + list(APPEND TOOLCHAIN_BINS $) + endif() + endif() endforeach() @@ -104,20 +122,16 @@ function(llvm_ExternalProject_Add name source_dir) endforeach() endforeach() - foreach(arg ${ARG_CMAKE_ARGS}) - if(arg MATCHES "^-DCMAKE_SYSTEM_NAME=") - string(REGEX REPLACE "^-DCMAKE_SYSTEM_NAME=(.*)$" "\\1" _cmake_system_name "${arg}") - endif() - endforeach() - if(ARG_USE_TOOLCHAIN AND NOT CMAKE_CROSSCOMPILING) if(CLANG_IN_TOOLCHAIN) if(_cmake_system_name STREQUAL Windows) set(compiler_args -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX} - -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}) + -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX} + -DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}) else() set(compiler_args -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang${CMAKE_EXECUTABLE_SUFFIX} - -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++${CMAKE_EXECUTABLE_SUFFIX}) + -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++${CMAKE_EXECUTABLE_SUFFIX} + -DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang${CMAKE_EXECUTABLE_SUFFIX}) endif() endif() if(lld IN_LIST TOOLCHAIN_TOOLS) @@ -235,6 +249,8 @@ function(llvm_ExternalProject_Add name source_dir) -DLLVM_HOST_TRIPLE=${LLVM_HOST_TRIPLE} -DLLVM_HAVE_LINK_VERSION_SCRIPT=${LLVM_HAVE_LINK_VERSION_SCRIPT} -DLLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO=${LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO} + -DLLVM_USE_RELATIVE_PATHS_IN_FILES=${LLVM_USE_RELATIVE_PATHS_IN_FILES} + -DLLVM_LIT_ARGS=${LLVM_LIT_ARGS} -DLLVM_SOURCE_PREFIX=${LLVM_SOURCE_PREFIX} -DPACKAGE_VERSION=${PACKAGE_VERSION} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} diff --git a/gnu/llvm/llvm/cmake/modules/LLVMProcessSources.cmake b/gnu/llvm/llvm/cmake/modules/LLVMProcessSources.cmake index d0be0e8b3ba..ba8dca313c8 100644 --- a/gnu/llvm/llvm/cmake/modules/LLVMProcessSources.cmake +++ b/gnu/llvm/llvm/cmake/modules/LLVMProcessSources.cmake @@ -57,10 +57,12 @@ endfunction(find_all_header_files) function(llvm_process_sources OUT_VAR) - cmake_parse_arguments(ARG "" "" "ADDITIONAL_HEADERS;ADDITIONAL_HEADER_DIRS" ${ARGN}) + cmake_parse_arguments(ARG "PARTIAL_SOURCES_INTENDED" "" "ADDITIONAL_HEADERS;ADDITIONAL_HEADER_DIRS" ${ARGN}) set(sources ${ARG_UNPARSED_ARGUMENTS}) - llvm_check_source_file_list( ${sources} ) - + if (NOT ARG_PARTIAL_SOURCES_INTENDED) + llvm_check_source_file_list(${sources}) + endif() + # This adds .td and .h files to the Visual Studio solution: add_td_sources(sources) find_all_header_files(hdrs "${ARG_ADDITIONAL_HEADER_DIRS}") diff --git a/gnu/llvm/llvm/cmake/modules/TableGen.cmake b/gnu/llvm/llvm/cmake/modules/TableGen.cmake index 9d2fcd9a793..73c1e96d3d9 100644 --- a/gnu/llvm/llvm/cmake/modules/TableGen.cmake +++ b/gnu/llvm/llvm/cmake/modules/TableGen.cmake @@ -2,10 +2,6 @@ # Extra parameters for `tblgen' may come after `ofn' parameter. # Adds the name of the generated file to TABLEGEN_OUTPUT. -if(LLVM_MAIN_INCLUDE_DIR) - set(LLVM_TABLEGEN_FLAGS -I ${LLVM_MAIN_INCLUDE_DIR}) -endif() - function(tablegen project ofn) # Validate calling context. if(NOT ${project}_TABLEGEN_EXE) @@ -57,7 +53,24 @@ function(tablegen project ofn) list(APPEND LLVM_TABLEGEN_FLAGS "-gisel-coverage-file=${LLVM_GISEL_COV_PREFIX}all") endif() endif() + # Comments are only useful for Debug builds. Omit them if the backend + # supports it. + if (NOT (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" OR + uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO")) + list(FIND ARGN "-gen-dag-isel" idx) + if (NOT idx EQUAL -1) + list(APPEND LLVM_TABLEGEN_FLAGS "-omit-comments") + endif() + endif() + # MSVC can't support long string literals ("long" > 65534 bytes)[1], so if there's + # a possibility of generated tables being consumed by MSVC, generate arrays of + # char literals, instead. If we're cross-compiling, then conservatively assume + # that the source might be consumed by MSVC. + # [1] https://docs.microsoft.com/en-us/cpp/cpp/compiler-limits?view=vs-2017 + if (MSVC AND project STREQUAL LLVM) + list(APPEND LLVM_TABLEGEN_FLAGS "--long-string-literals=0") + endif() if (CMAKE_GENERATOR MATCHES "Visual Studio") # Visual Studio has problems with llvm-tblgen's native --write-if-changed # behavior. Since it doesn't do restat optimizations anyway, just don't @@ -67,6 +80,14 @@ function(tablegen project ofn) set(tblgen_change_flag "--write-if-changed") endif() + # With CMake 3.12 this can be reduced to: + # get_directory_property(tblgen_includes "INCLUDE_DIRECTORIES") + # list(TRANSFORM tblgen_includes PREPEND -I) + set(tblgen_includes) + get_directory_property(includes "INCLUDE_DIRECTORIES") + foreach(include ${includes}) + list(APPEND tblgen_includes -I ${include}) + endforeach() # We need both _TABLEGEN_TARGET and _TABLEGEN_EXE in the DEPENDS list # (both the target and the file) to have .inc files rebuilt on # a tablegen change, as cmake does not propagate file-level dependencies @@ -78,6 +99,7 @@ function(tablegen project ofn) # but lets us having smaller and cleaner code here. add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${ofn} COMMAND ${${project}_TABLEGEN_EXE} ${ARGN} -I ${CMAKE_CURRENT_SOURCE_DIR} + ${tblgen_includes} ${LLVM_TABLEGEN_FLAGS} ${LLVM_TARGET_DEFINITIONS_ABSOLUTE} ${tblgen_change_flag} diff --git a/gnu/llvm/llvm/cmake/modules/TensorFlowCompile.cmake b/gnu/llvm/llvm/cmake/modules/TensorFlowCompile.cmake new file mode 100644 index 00000000000..a8ba56e67d1 --- /dev/null +++ b/gnu/llvm/llvm/cmake/modules/TensorFlowCompile.cmake @@ -0,0 +1,38 @@ +# Run the tensorflow compiler (saved_model_cli) on the saved model in the +# ${model} directory, looking for the ${tag_set} tag set, and the SignatureDef +# ${signature_def_key}. +# Produce a pair of files called ${fname}.h and ${fname}.o in the +# ${CMAKE_CURRENT_BINARY_DIR}. The generated header will define a C++ class +# called ${cpp_class} - which may be a namespace-qualified class name. +function(tfcompile model tag_set signature_def_key fname cpp_class) + if (IS_ABSOLUTE ${model}) + set(LLVM_ML_MODELS_ABSOLUTE ${model}) + else() + set(LLVM_ML_MODELS_ABSOLUTE + ${CMAKE_CURRENT_SOURCE_DIR}/${model}) + endif() + + set(prefix ${CMAKE_CURRENT_BINARY_DIR}/${fname}) + set(obj_file ${prefix}.o) + set(hdr_file ${prefix}.h) + add_custom_command(OUTPUT ${obj_file} ${hdr_file} + COMMAND "XLA_FLAGS=\"--xla_cpu_multi_thread_eigen=false\"" ${TENSORFLOW_AOT_COMPILER} aot_compile_cpu + --dir ${LLVM_ML_MODELS_ABSOLUTE} + --tag_set ${tag_set} + --signature_def_key ${signature_def_key} + --output_prefix ${prefix} + --cpp_class ${cpp_class} + --target_triple ${LLVM_HOST_TRIPLE} + ) + + # Aggregate the objects so that results of different tfcompile calls may be + # grouped into one target. + set(GENERATED_OBJS ${GENERATED_OBJS} ${obj_file} PARENT_SCOPE) + set_source_files_properties(${obj_file} PROPERTIES + GENERATED 1 EXTERNAL_OBJECT 1) + + set(GENERATED_HEADERS ${GENERATED_HEADERS} ${hdr_file} PARENT_SCOPE) + set_source_files_properties(${hdr_file} PROPERTIES + GENERATED 1) + +endfunction() diff --git a/gnu/llvm/llvm/cmake/modules/VersionFromVCS.cmake b/gnu/llvm/llvm/cmake/modules/VersionFromVCS.cmake index 1b6519b4b7c..18edbeabe3e 100644 --- a/gnu/llvm/llvm/cmake/modules/VersionFromVCS.cmake +++ b/gnu/llvm/llvm/cmake/modules/VersionFromVCS.cmake @@ -4,7 +4,7 @@ # extra argument, otherwise uses CMAKE_CURRENT_SOURCE_DIR). function(get_source_info path revision repository) - find_package(Git) + find_package(Git QUIET) if(GIT_FOUND) execute_process(COMMAND ${GIT_EXECUTABLE} rev-parse --git-dir WORKING_DIRECTORY ${path} @@ -45,5 +45,7 @@ function(get_source_info path revision repository) set(${repository} ${path} PARENT_SCOPE) endif() endif() + else() + message(WARNING "Git not found. Version cannot be determined.") endif() endfunction() diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst index bc2b4f74ecf..d0f65ee6d89 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst @@ -22,8 +22,8 @@ Notation Notation used in this document is explained :ref:`here`. -Overvew -======= +Overview +======== An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX1011.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX1011.rst new file mode 100644 index 00000000000..5e825c693c3 --- /dev/null +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX1011.rst @@ -0,0 +1,92 @@ +.. + ************************************************** + * * + * Automatically generated file, do not edit! * + * * + ************************************************** + +==================================================================================== +Syntax of gfx1011 and gfx1012 Instructions +==================================================================================== + +.. contents:: + :local: + +Introduction +============ + +This document describes the syntax of *instructions specific to gfx1011 and gfx1012*. + +For a description of other gfx1011 and gfx1012 instructions see :doc:`Syntax of Core GFX10 Instructions`. + +Notation +======== + +Notation used in this document is explained :ref:`here`. + +Overview +======== + +An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. + +Instructions +============ + + +DPP16 +----------------------- + +.. parsed-literal:: + + **INSTRUCTION** **DST** **SRC0** **SRC1** **MODIFIERS** + \ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---| + v_dot2c_f32_f16_dpp :ref:`vdst`, :ref:`vsrc0`::ref:`f16x2`, :ref:`vsrc1`::ref:`f16x2` :ref:`dpp16_ctrl` :ref:`row_mask` :ref:`bank_mask` :ref:`bound_ctrl` :ref:`fi` + v_dot4c_i32_i8_dpp :ref:`vdst`, :ref:`vsrc0`::ref:`i8x4`, :ref:`vsrc1`::ref:`i8x4` :ref:`dpp16_ctrl` :ref:`row_mask` :ref:`bank_mask` :ref:`bound_ctrl` :ref:`fi` + +DPP8 +----------------------- + +.. parsed-literal:: + + **INSTRUCTION** **DST** **SRC0** **SRC1** **MODIFIERS** + \ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---| + v_dot2c_f32_f16_dpp :ref:`vdst`, :ref:`vsrc0`::ref:`f16x2`, :ref:`vsrc1`::ref:`f16x2` :ref:`dpp8_sel` :ref:`fi` + v_dot4c_i32_i8_dpp :ref:`vdst`, :ref:`vsrc0`::ref:`i8x4`, :ref:`vsrc1`::ref:`i8x4` :ref:`dpp8_sel` :ref:`fi` + +VOP2 +----------------------- + +.. parsed-literal:: + + **INSTRUCTION** **DST** **SRC0** **SRC1** + \ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---| + v_dot2c_f32_f16 :ref:`vdst`, :ref:`src0`::ref:`f16x2`, :ref:`vsrc1`::ref:`f16x2` + v_dot4c_i32_i8 :ref:`vdst`, :ref:`src0`::ref:`i8x4`, :ref:`vsrc1`::ref:`i8x4` + +VOP3P +----------------------- + +.. parsed-literal:: + + **INSTRUCTION** **DST** **SRC0** **SRC1** **SRC2** **MODIFIERS** + \ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---| + v_dot2_f32_f16 :ref:`vdst`, :ref:`src0`::ref:`f16x2`, :ref:`src1`::ref:`f16x2`, :ref:`src2`::ref:`f32` :ref:`neg_lo` :ref:`neg_hi` :ref:`clamp` + v_dot2_i32_i16 :ref:`vdst`, :ref:`src0`::ref:`i16x2`, :ref:`src1`::ref:`i16x2`, :ref:`src2`::ref:`i32` :ref:`clamp` + v_dot2_u32_u16 :ref:`vdst`, :ref:`src0`::ref:`u16x2`, :ref:`src1`::ref:`u16x2`, :ref:`src2`::ref:`u32` :ref:`clamp` + v_dot4_i32_i8 :ref:`vdst`, :ref:`src0`::ref:`i8x4`, :ref:`src1`::ref:`i8x4`, :ref:`src2`::ref:`i32` :ref:`clamp` + v_dot4_u32_u8 :ref:`vdst`, :ref:`src0`::ref:`u8x4`, :ref:`src1`::ref:`u8x4`, :ref:`src2`::ref:`u32` :ref:`clamp` + v_dot8_i32_i4 :ref:`vdst`, :ref:`src0`::ref:`i4x8`, :ref:`src1`::ref:`i4x8`, :ref:`src2`::ref:`i32` :ref:`clamp` + v_dot8_u32_u4 :ref:`vdst`, :ref:`src0`::ref:`u4x8`, :ref:`src1`::ref:`u4x8`, :ref:`src2`::ref:`u32` :ref:`clamp` + +.. |---| unicode:: U+02014 .. em dash + + +.. toctree:: + :hidden: + + AMDGPUAsmGFX10 + gfx1011_src32_0 + gfx1011_src32_1 + gfx1011_vdst32_0 + gfx1011_vsrc32_0 + gfx1011_type_dev diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst index e96862bcf03..c1b8512367f 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst @@ -22,8 +22,8 @@ Notation Notation used in this document is explained :ref:`here`. -Overvew -======= +Overview +======== An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst index 4dd0439c6fd..b41d5e6eaf9 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst @@ -22,8 +22,8 @@ Notation Notation used in this document is explained :ref:`here`. -Overvew -======= +Overview +======== An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst index 7131718df7e..9f17b34fc1a 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst @@ -22,8 +22,8 @@ Notation Notation used in this document is explained :ref:`here`. -Overvew -======= +Overview +======== An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst index 7832e08dbb3..4e81f974ad7 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst @@ -24,8 +24,8 @@ Notation Notation used in this document is explained :ref:`here`. -Overvew -======= +Overview +======== An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst index 23f79fc96a4..230d689f3a0 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst @@ -24,8 +24,8 @@ Notation Notation used in this document is explained :ref:`here`. -Overvew -======= +Overview +======== An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst index 8119af4392e..385917d6a7b 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst @@ -24,8 +24,8 @@ Notation Notation used in this document is explained :ref:`here`. -Overvew -======= +Overview +======== An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. @@ -66,10 +66,10 @@ VOP3P v_dot2_f32_f16 :ref:`vdst`, :ref:`src0`::ref:`f16x2`, :ref:`src1`::ref:`f16x2`, :ref:`src2`::ref:`f32` :ref:`neg_lo` :ref:`neg_hi` :ref:`clamp` v_dot2_i32_i16 :ref:`vdst`, :ref:`src0`::ref:`i16x2`, :ref:`src1`::ref:`i16x2`, :ref:`src2`::ref:`i32` :ref:`clamp` v_dot2_u32_u16 :ref:`vdst`, :ref:`src0`::ref:`u16x2`, :ref:`src1`::ref:`u16x2`, :ref:`src2`::ref:`u32` :ref:`clamp` - v_dot4_i32_i8 :ref:`vdst`, :ref:`src0`::ref:`i8x2`, :ref:`src1`::ref:`i8x2`, :ref:`src2`::ref:`i32` :ref:`clamp` - v_dot4_u32_u8 :ref:`vdst`, :ref:`src0`::ref:`u8x2`, :ref:`src1`::ref:`u8x2`, :ref:`src2`::ref:`u32` :ref:`clamp` - v_dot8_i32_i4 :ref:`vdst`, :ref:`src0`::ref:`i4x2`, :ref:`src1`::ref:`i4x2`, :ref:`src2`::ref:`i32` :ref:`clamp` - v_dot8_u32_u4 :ref:`vdst`, :ref:`src0`::ref:`u4x2`, :ref:`src1`::ref:`u4x2`, :ref:`src2`::ref:`u32` :ref:`clamp` + v_dot4_i32_i8 :ref:`vdst`, :ref:`src0`::ref:`i8x4`, :ref:`src1`::ref:`i8x4`, :ref:`src2`::ref:`i32` :ref:`clamp` + v_dot4_u32_u8 :ref:`vdst`, :ref:`src0`::ref:`u8x4`, :ref:`src1`::ref:`u8x4`, :ref:`src2`::ref:`u32` :ref:`clamp` + v_dot8_i32_i4 :ref:`vdst`, :ref:`src0`::ref:`i4x8`, :ref:`src1`::ref:`i4x8`, :ref:`src2`::ref:`i32` :ref:`clamp` + v_dot8_u32_u4 :ref:`vdst`, :ref:`src0`::ref:`u4x8`, :ref:`src1`::ref:`u4x8`, :ref:`src2`::ref:`u32` :ref:`clamp` v_fma_mix_f32 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` v_fma_mixhi_f16 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` v_fma_mixlo_f16 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` diff --git a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst index 7e90837cdf0..27da0179289 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst @@ -24,8 +24,8 @@ Notation Notation used in this document is explained :ref:`here`. -Overvew -======= +Overview +======== An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document`. @@ -39,9 +39,9 @@ FLAT .. parsed-literal:: **INSTRUCTION** **DST** **SRC0** **SRC1** **SRC2** **MODIFIERS** - \ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---| - global_atomic_add_f32 :ref:`vdst`::ref:`opt`, :ref:`vaddr`, :ref:`vdata`, :ref:`saddr` :ref:`offset13s` - global_atomic_pk_add_f16 :ref:`vdst`::ref:`opt`::ref:`f16x2`, :ref:`vaddr`, :ref:`vdata`::ref:`f16x2`, :ref:`saddr` :ref:`offset13s` + \ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---| + global_atomic_add_f32 :ref:`vdst`::ref:`opt`, :ref:`vaddr`, :ref:`vdata`, :ref:`saddr` :ref:`offset13s` :ref:`slc` + global_atomic_pk_add_f16 :ref:`vdst`::ref:`opt`::ref:`f16x2`, :ref:`vaddr`, :ref:`vdata`::ref:`f16x2`, :ref:`saddr` :ref:`offset13s` :ref:`slc` MUBUF ----------------------- @@ -90,40 +90,40 @@ VOP3P .. parsed-literal:: - **INSTRUCTION** **DST** **SRC0** **SRC1** **SRC2** **MODIFIERS** - \ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---| + **INSTRUCTION** **DST** **SRC0** **SRC1** **SRC2** **MODIFIERS** + \ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---|\ |---| v_accvgpr_read_b32 :ref:`vdst`, :ref:`asrc` v_accvgpr_write_b32 :ref:`adst`, :ref:`src` - v_dot2_f32_f16 :ref:`vdst`, :ref:`src0`::ref:`f16x2`, :ref:`src1`::ref:`f16x2`, :ref:`src2`::ref:`f32` :ref:`neg_lo` :ref:`neg_hi` :ref:`clamp` - v_dot2_i32_i16 :ref:`vdst`, :ref:`src0`::ref:`i16x2`, :ref:`src1`::ref:`i16x2`, :ref:`src2`::ref:`i32` :ref:`clamp` - v_dot2_u32_u16 :ref:`vdst`, :ref:`src0`::ref:`u16x2`, :ref:`src1`::ref:`u16x2`, :ref:`src2`::ref:`u32` :ref:`clamp` - v_dot4_i32_i8 :ref:`vdst`, :ref:`src0`::ref:`i8x2`, :ref:`src1`::ref:`i8x2`, :ref:`src2`::ref:`i32` :ref:`clamp` - v_dot4_u32_u8 :ref:`vdst`, :ref:`src0`::ref:`u8x2`, :ref:`src1`::ref:`u8x2`, :ref:`src2`::ref:`u32` :ref:`clamp` - v_dot8_i32_i4 :ref:`vdst`, :ref:`src0`::ref:`i4x2`, :ref:`src1`::ref:`i4x2`, :ref:`src2`::ref:`i32` :ref:`clamp` - v_dot8_u32_u4 :ref:`vdst`, :ref:`src0`::ref:`u4x2`, :ref:`src1`::ref:`u4x2`, :ref:`src2`::ref:`u32` :ref:`clamp` - v_fma_mix_f32 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` - v_fma_mixhi_f16 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` - v_fma_mixlo_f16 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` - v_mfma_f32_16x16x16f16 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_16x16x1f32 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_16x16x2bf16 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`i16x2`, :ref:`vasrc1`::ref:`i16x2`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_16x16x4f16 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_16x16x4f32 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_16x16x8bf16 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`i16x2`, :ref:`vasrc1`::ref:`i16x2`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_32x32x1f32 :ref:`adst`::ref:`f32x32`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x32` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_32x32x2bf16 :ref:`adst`::ref:`f32x32`, :ref:`vasrc0`::ref:`i16x2`, :ref:`vasrc1`::ref:`i16x2`, :ref:`asrc2`::ref:`f32x32` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_32x32x2f32 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_32x32x4bf16 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`i16x2`, :ref:`vasrc1`::ref:`i16x2`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_32x32x4f16 :ref:`adst`::ref:`f32x32`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x32` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_32x32x8f16 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_4x4x1f32 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_4x4x2bf16 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`i16x2`, :ref:`vasrc1`::ref:`i16x2`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_f32_4x4x4f16 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_i32_16x16x16i8 :ref:`adst`::ref:`i32x4`, :ref:`vasrc0`::ref:`i32`, :ref:`vasrc1`::ref:`i32`, :ref:`asrc2`::ref:`i32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_i32_16x16x4i8 :ref:`adst`::ref:`i32x16`, :ref:`vasrc0`::ref:`i32`, :ref:`vasrc1`::ref:`i32`, :ref:`asrc2`::ref:`i32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_i32_32x32x4i8 :ref:`adst`::ref:`i32x32`, :ref:`vasrc0`::ref:`i32`, :ref:`vasrc1`::ref:`i32`, :ref:`asrc2`::ref:`i32x32` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_i32_32x32x8i8 :ref:`adst`::ref:`i32x16`, :ref:`vasrc0`::ref:`i32`, :ref:`vasrc1`::ref:`i32`, :ref:`asrc2`::ref:`i32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` - v_mfma_i32_4x4x4i8 :ref:`adst`::ref:`i32x4`, :ref:`vasrc0`::ref:`i32`, :ref:`vasrc1`::ref:`i32`, :ref:`asrc2`::ref:`i32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_dot2_f32_f16 :ref:`vdst`, :ref:`src0`::ref:`f16x2`, :ref:`src1`::ref:`f16x2`, :ref:`src2`::ref:`f32` :ref:`neg_lo` :ref:`neg_hi` :ref:`clamp` + v_dot2_i32_i16 :ref:`vdst`, :ref:`src0`::ref:`i16x2`, :ref:`src1`::ref:`i16x2`, :ref:`src2`::ref:`i32` :ref:`clamp` + v_dot2_u32_u16 :ref:`vdst`, :ref:`src0`::ref:`u16x2`, :ref:`src1`::ref:`u16x2`, :ref:`src2`::ref:`u32` :ref:`clamp` + v_dot4_i32_i8 :ref:`vdst`, :ref:`src0`::ref:`i8x4`, :ref:`src1`::ref:`i8x4`, :ref:`src2`::ref:`i32` :ref:`clamp` + v_dot4_u32_u8 :ref:`vdst`, :ref:`src0`::ref:`u8x4`, :ref:`src1`::ref:`u8x4`, :ref:`src2`::ref:`u32` :ref:`clamp` + v_dot8_i32_i4 :ref:`vdst`, :ref:`src0`::ref:`i4x8`, :ref:`src1`::ref:`i4x8`, :ref:`src2`::ref:`i32` :ref:`clamp` + v_dot8_u32_u4 :ref:`vdst`, :ref:`src0`::ref:`u4x8`, :ref:`src1`::ref:`u4x8`, :ref:`src2`::ref:`u32` :ref:`clamp` + v_fma_mix_f32 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` + v_fma_mixhi_f16 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` + v_fma_mixlo_f16 :ref:`vdst`, :ref:`src0`::ref:`m`::ref:`fx`, :ref:`src1`::ref:`m`::ref:`fx`, :ref:`src2`::ref:`m`::ref:`fx` :ref:`m_op_sel` :ref:`m_op_sel_hi` :ref:`clamp` + v_mfma_f32_16x16x16f16 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_16x16x1f32 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_16x16x2bf16 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`bf16x2`, :ref:`vasrc1`::ref:`bf16x2`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_16x16x4f16 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_16x16x4f32 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_16x16x8bf16 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`bf16x2`, :ref:`vasrc1`::ref:`bf16x2`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_32x32x1f32 :ref:`adst`::ref:`f32x32`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x32` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_32x32x2bf16 :ref:`adst`::ref:`f32x32`, :ref:`vasrc0`::ref:`bf16x2`, :ref:`vasrc1`::ref:`bf16x2`, :ref:`asrc2`::ref:`f32x32` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_32x32x2f32 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_32x32x4bf16 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`bf16x2`, :ref:`vasrc1`::ref:`bf16x2`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_32x32x4f16 :ref:`adst`::ref:`f32x32`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x32` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_32x32x8f16 :ref:`adst`::ref:`f32x16`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_4x4x1f32 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`f32`, :ref:`vasrc1`::ref:`f32`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_4x4x2bf16 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`bf16x2`, :ref:`vasrc1`::ref:`bf16x2`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_f32_4x4x4f16 :ref:`adst`::ref:`f32x4`, :ref:`vasrc0`::ref:`f16x4`, :ref:`vasrc1`::ref:`f16x4`, :ref:`asrc2`::ref:`f32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_i32_16x16x16i8 :ref:`adst`::ref:`i32x4`, :ref:`vasrc0`::ref:`i8x4`, :ref:`vasrc1`::ref:`i8x4`, :ref:`asrc2`::ref:`i32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_i32_16x16x4i8 :ref:`adst`::ref:`i32x16`, :ref:`vasrc0`::ref:`i8x4`, :ref:`vasrc1`::ref:`i8x4`, :ref:`asrc2`::ref:`i32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_i32_32x32x4i8 :ref:`adst`::ref:`i32x32`, :ref:`vasrc0`::ref:`i8x4`, :ref:`vasrc1`::ref:`i8x4`, :ref:`asrc2`::ref:`i32x32` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_i32_32x32x8i8 :ref:`adst`::ref:`i32x16`, :ref:`vasrc0`::ref:`i8x4`, :ref:`vasrc1`::ref:`i8x4`, :ref:`asrc2`::ref:`i32x16` :ref:`cbsz` :ref:`abid` :ref:`blgp` + v_mfma_i32_4x4x4i8 :ref:`adst`::ref:`i32x4`, :ref:`vasrc0`::ref:`i8x4`, :ref:`vasrc1`::ref:`i8x4`, :ref:`asrc2`::ref:`i32x4` :ref:`cbsz` :ref:`abid` :ref:`blgp` .. |---| unicode:: U+02014 .. em dash diff --git a/gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_0.rst b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_0.rst new file mode 100644 index 00000000000..8d82f4171f6 --- /dev/null +++ b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_0.rst @@ -0,0 +1,17 @@ +.. + ************************************************** + * * + * Automatically generated file, do not edit! * + * * + ************************************************** + +.. _amdgpu_synid1011_src32_0: + +src +=========================== + +Instruction input. + +*Size:* 1 dword. + +*Operands:* :ref:`v`, :ref:`s`, :ref:`vcc`, :ref:`ttmp`, :ref:`m0`, :ref:`exec`, :ref:`vccz`, :ref:`execz`, :ref:`scc`, :ref:`lds_direct`, :ref:`constant`, :ref:`literal` diff --git a/gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_1.rst b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_1.rst new file mode 100644 index 00000000000..b923912d041 --- /dev/null +++ b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_src32_1.rst @@ -0,0 +1,17 @@ +.. + ************************************************** + * * + * Automatically generated file, do not edit! * + * * + ************************************************** + +.. _amdgpu_synid1011_src32_1: + +src +=========================== + +Instruction input. + +*Size:* 1 dword. + +*Operands:* :ref:`v`, :ref:`s`, :ref:`vcc`, :ref:`ttmp`, :ref:`m0`, :ref:`exec`, :ref:`vccz`, :ref:`execz`, :ref:`scc`, :ref:`constant`, :ref:`literal` diff --git a/gnu/llvm/llvm/docs/AMDGPU/gfx1011_type_dev.rst b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_type_dev.rst new file mode 100644 index 00000000000..c7ddb82757e --- /dev/null +++ b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_type_dev.rst @@ -0,0 +1,13 @@ +.. + ************************************************** + * * + * Automatically generated file, do not edit! * + * * + ************************************************** + +.. _amdgpu_synid1011_type_dev: + +Type deviation +=========================== + +*Type* of this operand differs from *type* :ref:`implied by the opcode`. This tag specifies actual operand *type*. diff --git a/gnu/llvm/llvm/docs/AMDGPU/gfx1011_vdst32_0.rst b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_vdst32_0.rst new file mode 100644 index 00000000000..115b8527fb6 --- /dev/null +++ b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_vdst32_0.rst @@ -0,0 +1,17 @@ +.. + ************************************************** + * * + * Automatically generated file, do not edit! * + * * + ************************************************** + +.. _amdgpu_synid1011_vdst32_0: + +vdst +=========================== + +Instruction output. + +*Size:* 1 dword. + +*Operands:* :ref:`v` diff --git a/gnu/llvm/llvm/docs/AMDGPU/gfx1011_vsrc32_0.rst b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_vsrc32_0.rst new file mode 100644 index 00000000000..be63c654949 --- /dev/null +++ b/gnu/llvm/llvm/docs/AMDGPU/gfx1011_vsrc32_0.rst @@ -0,0 +1,17 @@ +.. + ************************************************** + * * + * Automatically generated file, do not edit! * + * * + ************************************************** + +.. _amdgpu_synid1011_vsrc32_0: + +vsrc +=========================== + +Instruction input. + +*Size:* 1 dword. + +*Operands:* :ref:`v` diff --git a/gnu/llvm/llvm/docs/AMDGPU/gfx908_saddr_flat_global.rst b/gnu/llvm/llvm/docs/AMDGPU/gfx908_saddr_flat_global.rst index a0e450639e0..fe9864c237a 100644 --- a/gnu/llvm/llvm/docs/AMDGPU/gfx908_saddr_flat_global.rst +++ b/gnu/llvm/llvm/docs/AMDGPU/gfx908_saddr_flat_global.rst @@ -16,4 +16,4 @@ See :ref:`vaddr` for description of available *Size:* 2 dwords. -*Operands:* :ref:`exec`, :ref:`off` +*Operands:* :ref:`s`, :ref:`flat_scratch`, :ref:`vcc`, :ref:`ttmp`, :ref:`exec`, :ref:`off` diff --git a/gnu/llvm/llvm/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.rst b/gnu/llvm/llvm/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.rst new file mode 100644 index 00000000000..a2c48f97717 --- /dev/null +++ b/gnu/llvm/llvm/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.rst @@ -0,0 +1,3896 @@ +.. _amdgpu-dwarf-proposal-for-heterogeneous-debugging: + +****************************************** +DWARF Proposal For Heterogeneous Debugging +****************************************** + +.. contents:: + :local: + +.. warning:: + + This document describes a **provisional proposal** for DWARF Version 6 + [:ref:`DWARF `] to support heterogeneous debugging. It is + not currently fully implemented and is subject to change. + +.. _amdgpu-dwarf-introduction: + +Introduction +============ + +AMD [:ref:`AMD `] has been working on supporting heterogeneous +computing through the AMD Radeon Open Compute Platform (ROCm) [:ref:`AMD-ROCm +`]. A heterogeneous computing program can be written in a +high level language such as C++ or Fortran with OpenMP pragmas, OpenCL, or HIP +(a portable C++ programming environment for heterogeneous computing [:ref:`HIP +`]). A heterogeneous compiler and runtime allows a program to +execute on multiple devices within the same native process. Devices could +include CPUs, GPUs, DSPs, FPGAs, or other special purpose accelerators. +Currently HIP programs execute on systems with CPUs and GPUs. + +ROCm is fully open sourced and includes contributions to open source projects +such as LLVM for compilation [:ref:`LLVM `] and GDB for +debugging [:ref:`GDB `], as well as collaboration with other +third party projects such as the GCC compiler [:ref:`GCC `] +and the Perforce TotalView HPC debugger [:ref:`Perforce-TotalView +`]. + +To support debugging heterogeneous programs several features that are not +provided by current DWARF Version 5 [:ref:`DWARF `] have +been identified. This document contains a collection of proposals to address +providing those features. + +The :ref:`amdgpu-dwarf-motivation` section describes the issues that are being +addressed for heterogeneous computing. That is followed by the +:ref:`amdgpu-dwarf-proposed-changes-relative-to-dwarf-version-5` section +containing the proposed textual changes relative to the DWARF Version 5 +standard. Then there is an :ref:`amdgpu-dwarf-examples` section that links to +the AMD GPU specific usage of the features in the proposal that includes an +example. Finally, there is a :ref:`amdgpu-dwarf-references` section. There are a +number of notes included that raise open questions, or provide alternative +approaches considered. The draft proposal seeks to be general in nature and +backwards compatible with DWARF Version 5. Its goal is to be applicable to +meeting the needs of any heterogeneous system and not be vendor or architecture +specific. + +A fundamental aspect of the draft proposal is that it allows DWARF expression +location descriptions as stack elements. The draft proposal is based on DWARF +Version 5 and maintains compatibility with DWARF Version 5. After attempting +several alternatives, the current thinking is that such an addition to DWARF +Version 5 is the simplest and cleanest way to support debugging optimized GPU +code. It also appears to be generally useful and may be able to address other +reported DWARF issues, as well as being helpful in providing better optimization +support for non-GPU code. + +General feedback on this draft proposal is sought, together with suggestions on +how to clarify, simplify, or organize it before submitting it as a formal DWARF +proposal. The current draft proposal is large and may need to be split into +separate proposals before formal submission. Any suggestions on how best to do +that are appreciated. However, at the initial review stage it is believed there +is value in presenting a unified proposal as there are mutual dependencies +between the various parts that would not be as apparent if it was broken up into +separate independent proposals. + +We are in the process of modifying LLVM and GDB to support this draft proposal +which is providing experience and insights. We plan to upstream the changes to +those projects for any final form of the proposal. + +The author very much appreciates the input provided so far by many others which +has been incorporated into this current version. + +.. _amdgpu-dwarf-motivation: + +Motivation +========== + +This document proposes a set of backwards compatible extensions to DWARF Version +5 [:ref:`DWARF `] for consideration of inclusion into a +future DWARF Version 6 standard to support heterogeneous debugging. + +The remainder of this section provides motivation for each proposed feature in +terms of heterogeneous debugging on commercially available AMD GPU hardware +(AMDGPU). The goal is to add support to the AMD [:ref:`AMD `] +open source Radeon Open Compute Platform (ROCm) [:ref:`AMD-ROCm +`] which is an implementation of the industry standard +for heterogeneous computing devices defined by the Heterogeneous System +Architecture (HSA) Foundation [:ref:`HSA `]. ROCm includes the +LLVM compiler [:ref:`LLVM `] with upstreamed support for +AMDGPU [:ref:`AMDGPU-LLVM `]. The goal is to also add +the GDB debugger [:ref:`GDB `] with upstreamed support for +AMDGPU [:ref:`AMD-ROCgdb `]. In addition, the goal is +to work with third parties to enable support for AMDGPU debugging in the GCC +compiler [:ref:`GCC `] and the Perforce TotalView HPC debugger +[:ref:`Perforce-TotalView `]. + +However, the proposal is intended to be vendor and architecture neutral. It is +believed to apply to other heterogeous hardware devices including GPUs, DSPs, +FPGAs, and other specialized hardware. These collectively include similar +characteristics and requirements as AMDGPU devices. Parts of the proposal can +also apply to traditional CPU hardware that supports large vector registers. +Compilers can map source languages and extensions that describe large scale +parallel execution onto the lanes of the vector registers. This is common in +programming languages used in ML and HPC. The proposal also includes improved +support for optimized code on any architecture. Some of the generalizations may +also benefit other issues that have been raised. + +The proposal has evolved though collaboration with many individuals and active +prototyping within the GDB debugger and LLVM compiler. Input has also been very +much appreciated from the developers working on the Perforce TotalView HPC +Debugger and GCC compiler. + +The AMDGPU has several features that require additional DWARF functionality in +order to support optimized code. + +AMDGPU optimized code may spill vector registers to non-global address space +memory, and this spilling may be done only for lanes that are active on entry +to the subprogram. To support this, a location description that can be created +as a masked select is required. See ``DW_OP_LLVM_select_bit_piece``. + +Since the active lane mask may be held in a register, a way to get the value +of a register on entry to a subprogram is required. To support this an +operation that returns the caller value of a register as specified by the Call +Frame Information (CFI) is required. See ``DW_OP_LLVM_call_frame_entry_reg`` +and :ref:`amdgpu-dwarf-call-frame-information`. + +Current DWARF uses an empty expression to indicate an undefined location +description. Since the masked select composite location description operation +takes more than one location description, it is necessary to have an explicit +way to specify an undefined location description. Otherwise it is not possible +to specify that a particular one of the input location descriptions is +undefined. See ``DW_OP_LLVM_undefined``. + +CFI describes restoring callee saved registers that are spilled. Currently CFI +only allows a location description that is a register, memory address, or +implicit location description. AMDGPU optimized code may spill scalar +registers into portions of vector registers. This requires extending CFI to +allow any location description. See +:ref:`amdgpu-dwarf-call-frame-information`. + +The vector registers of the AMDGPU are represented as their full wavefront +size, meaning the wavefront size times the dword size. This reflects the +actual hardware and allows the compiler to generate DWARF for languages that +map a thread to the complete wavefront. It also allows more efficient DWARF to +be generated to describe the CFI as only a single expression is required for +the whole vector register, rather than a separate expression for each lane's +dword of the vector register. It also allows the compiler to produce DWARF +that indexes the vector register if it spills scalar registers into portions +of a vector registers. + +Since DWARF stack value entries have a base type and AMDGPU registers are a +vector of dwords, the ability to specify that a base type is a vector is +required. See ``DW_AT_LLVM_vector_size``. + +If the source language is mapped onto the AMDGPU wavefronts in a SIMT manner, +then the variable DWARF location expressions must compute the location for a +single lane of the wavefront. Therefore, a DWARF operation is required to +denote the current lane, much like ``DW_OP_push_object_address`` denotes the +current object. The ``DW_OP_*piece`` operations only allow literal indices. +Therefore, a way to use a computed offset of an arbitrary location description +(such as a vector register) is required. See ``DW_OP_LLVM_push_lane``, +``DW_OP_LLVM_offset``, ``DW_OP_LLVM_offset_uconst``, and +``DW_OP_LLVM_bit_offset``. + +If the source language is mapped onto the AMDGPU wavefronts in a SIMT manner +the compiler can use the AMDGPU execution mask register to control which lanes +are active. To describe the conceptual location of non-active lanes a DWARF +expression is needed that can compute a per lane PC. For efficiency, this is +done for the wavefront as a whole. This expression benefits by having a masked +select composite location description operation. This requires an attribute +for source location of each lane. The AMDGPU may update the execution mask for +whole wavefront operations and so needs an attribute that computes the current +active lane mask. See ``DW_OP_LLVM_select_bit_piece``, ``DW_OP_LLVM_extend``, +``DW_AT_LLVM_lane_pc``, and ``DW_AT_LLVM_active_lane``. + +AMDGPU needs to be able to describe addresses that are in different kinds of +memory. Optimized code may need to describe a variable that resides in pieces +that are in different kinds of storage which may include parts of registers, +memory that is in a mixture of memory kinds, implicit values, or be undefined. +DWARF has the concept of segment addresses. However, the segment cannot be +specified within a DWARF expression, which is only able to specify the offset +portion of a segment address. The segment index is only provided by the entity +that specifies the DWARF expression. Therefore, the segment index is a +property that can only be put on complete objects, such as a variable. That +makes it only suitable for describing an entity (such as variable or +subprogram code) that is in a single kind of memory. Therefore, AMDGPU uses +the DWARF concept of address spaces. For example, a variable may be allocated +in a register that is partially spilled to the call stack which is in the +private address space, and partially spilled to the local address space. + +DWARF uses the concept of an address in many expression operations but does not +define how it relates to address spaces. For example, +``DW_OP_push_object_address`` pushes the address of an object. Other contexts +implicitly push an address on the stack before evaluating an expression. For +example, the ``DW_AT_use_location`` attribute of the +``DW_TAG_ptr_to_member_type``. The expression that uses the address needs to +do so in a general way and not need to be dependent on the address space of +the address. For example, a pointer to member value may want to be applied to +an object that may reside in any address space. + +The number of registers and the cost of memory operations is much higher for +AMDGPU than a typical CPU. The compiler attempts to optimize whole variables +and arrays into registers. Currently DWARF only allows +``DW_OP_push_object_address`` and related operations to work with a global +memory location. To support AMDGPU optimized code it is required to generalize +DWARF to allow any location description to be used. This allows registers, or +composite location descriptions that may be a mixture of memory, registers, or +even implicit values. + +DWARF Version 5 does not allow location descriptions to be entries on the +DWARF stack. They can only be the final result of the evaluation of a DWARF +expression. However, by allowing a location description to be a first-class +entry on the DWARF stack it becomes possible to compose expressions containing +both values and location descriptions naturally. It allows objects to be +located in any kind of memory address space, in registers, be implicit values, +be undefined, or a composite of any of these. By extending DWARF carefully, +all existing DWARF expressions can retain their current semantic meaning. +DWARF has implicit conversions that convert from a value that represents an +address in the default address space to a memory location description. This +can be extended to allow a default address space memory location description +to be implicitly converted back to its address value. This allows all DWARF +Version 5 expressions to retain their same meaning, while adding the ability +to explicitly create memory location descriptions in non-default address +spaces and generalizing the power of composite location descriptions to any +kind of location description. See :ref:`amdgpu-dwarf-operation-expressions`. + +To allow composition of composite location descriptions, an explicit operation +that indicates the end of the definition of a composite location description +is required. This can be implied if the end of a DWARF expression is reached, +allowing current DWARF expressions to remain legal. See +``DW_OP_LLVM_piece_end``. + +The ``DW_OP_plus`` and ``DW_OP_minus`` can be defined to operate on a memory +location description in the default target architecture specific address space +and a generic type value to produce an updated memory location description. This +allows them to continue to be used to offset an address. To generalize +offsetting to any location description, including location descriptions that +describe when bytes are in registers, are implicit, or a composite of these, the +``DW_OP_LLVM_offset``, ``DW_OP_LLVM_offset_uconst``, and +``DW_OP_LLVM_bit_offset`` offset operations are added. Unlike ``DW_OP_plus``, +``DW_OP_plus_uconst``, and ``DW_OP_minus`` arithmetic operations, these do not +define that integer overflow causes wrap-around. The offset operations can +operate on location storage of any size. For example, implicit location storage +could be any number of bits in size. It is simpler to define offsets that exceed +the size of the location storage as being ill-formed, than having to force an +implementation to support potentially infinite precision offsets to allow it to +correctly track a series of positive and negative offsets that may transiently +overflow or underflow, but end up in range. This is simple for the arithmetic +operations as they are defined in terms of two's compliment arithmetic on a base +type of a fixed size. + +Having the offset operations allows ``DW_OP_push_object_address`` to push a +location description that may be in a register, or be an implicit value, and the +DWARF expression of ``DW_TAG_ptr_to_member_type`` can contain them to offset +within it. ``DW_OP_LLVM_bit_offset`` generalizes DWARF to work with bit fields +which is not possible in DWARF Version 5. + +The DWARF ``DW_OP_xderef*`` operations allow a value to be converted into an +address of a specified address space which is then read. But it provides no +way to create a memory location description for an address in the non-default +address space. For example, AMDGPU variables can be allocated in the local +address space at a fixed address. It is required to have an operation to +create an address in a specific address space that can be used to define the +location description of the variable. Defining this operation to produce a +location description allows the size of addresses in an address space to be +larger than the generic type. See ``DW_OP_LLVM_form_aspace_address``. + +If the ``DW_OP_LLVM_form_aspace_address`` operation had to produce a value +that can be implicitly converted to a memory location description, then it +would be limited to the size of the generic type which matches the size of the +default address space. Its value would be unspecified and likely not match any +value in the actual program. By making the result a location description, it +allows a consumer great freedom in how it implements it. The implicit +conversion back to a value can be limited only to the default address space to +maintain compatibility with DWARF Version 5. For other address spaces the +producer can use the new operations that explicitly specify the address space. + +``DW_OP_breg*`` treats the register as containing an address in the default +address space. It is required to be able to specify the address space of the +register value. See ``DW_OP_LLVM_aspace_bregx``. + +Similarly, ``DW_OP_implicit_pointer`` treats its implicit pointer value as +being in the default address space. It is required to be able to specify the +address space of the pointer value. See +``DW_OP_LLVM_aspace_implicit_pointer``. + +Almost all uses of addresses in DWARF are limited to defining location +descriptions, or to be dereferenced to read memory. The exception is +``DW_CFA_val_offset`` which uses the address to set the value of a register. +By defining the CFA DWARF expression as being a memory location description, +it can maintain what address space it is, and that can be used to convert the +offset address back to an address in that address space. See +:ref:`amdgpu-dwarf-call-frame-information`. + +This approach allows all existing DWARF to have the identical semantics. It +allows the compiler to explicitly specify the address space it is using. For +example, a compiler could choose to access private memory in a swizzled manner +when mapping a source language to a wavefront in a SIMT manner, or to access +it in an unswizzled manner if mapping the same language with the wavefront +being the thread. It also allows the compiler to mix the address space it uses +to access private memory. For example, for SIMT it can still spill entire +vector registers in an unswizzled manner, while using a swizzled private +memory for SIMT variable access. This approach allows memory location +descriptions for different address spaces to be combined using the regular +``DW_OP_*piece`` operations. + +Location descriptions are an abstraction of storage, they give freedom to the +consumer on how to implement them. They allow the address space to encode lane +information so they can be used to read memory with only the memory +description and no extra arguments. The same set of operations can operate on +locations independent of their kind of storage. The ``DW_OP_deref*`` therefore +can be used on any storage kind. ``DW_OP_xderef*`` is unnecessary except to +become a more compact way to convert a non-default address space address +followed by dereferencing it. + +In DWARF Version 5 a location description is defined as a single location +description or a location list. A location list is defined as either +effectively an undefined location description or as one or more single +location descriptions to describe an object with multiple places. The +``DW_OP_push_object_address`` and ``DW_OP_call*`` operations can put a +location description on the stack. Furthermore, debugger information entry +attributes such as ``DW_AT_data_member_location``, ``DW_AT_use_location``, and +``DW_AT_vtable_elem_location`` are defined as pushing a location description +on the expression stack before evaluating the expression. However, DWARF +Version 5 only allows the stack to contain values and so only a single memory +address can be on the stack which makes these incapable of handling location +descriptions with multiple places, or places other than memory. Since this +proposal allows the stack to contain location descriptions, the operations are +generalized to support location descriptions that can have multiple places. +This is backwards compatible with DWARF Version 5 and allows objects with +multiple places to be supported. For example, the expression that describes +how to access the field of an object can be evaluated with a location +description that has multiple places and will result in a location description +with multiple places as expected. With this change, the separate DWARF Version +5 sections that described DWARF expressions and location lists have been +unified into a single section that describes DWARF expressions in general. +This unification seems to be a natural consequence and a necessity of allowing +location descriptions to be part of the evaluation stack. + +For those familiar with the definition of location descriptions in DWARF +Version 5, the definition in this proposal is presented differently, but does +in fact define the same concept with the same fundamental semantics. However, +it does so in a way that allows the concept to extend to support address +spaces, bit addressing, the ability for composite location descriptions to be +composed of any kind of location description, and the ability to support +objects located at multiple places. Collectively these changes expand the set +of processors that can be supported and improves support for optimized code. + +Several approaches were considered, and the one proposed appears to be the +cleanest and offers the greatest improvement of DWARF's ability to support +optimized code. Examining the GDB debugger and LLVM compiler, it appears only +to require modest changes as they both already have to support general use of +location descriptions. It is anticipated that will also be the case for other +debuggers and compilers. + +As an experiment, GDB was modified to evaluate DWARF Version 5 expressions +with location descriptions as stack entries and implicit conversions. All GDB +tests have passed, except one that turned out to be an invalid test by DWARF +Version 5 rules. The code in GDB actually became simpler as all evaluation was +on the stack and there was no longer a need to maintain a separate structure +for the location description result. This gives confidence of the backwards +compatibility. + +Since the AMDGPU supports languages such as OpenCL [:ref:`OpenCL +`], there is a need to define source language address +classes so they can be used in a consistent way by consumers. It would also be +desirable to add support for using them in defining language types rather than +the current target architecture specific address spaces. See +:ref:`amdgpu-dwarf-segment_addresses`. + +A ``DW_AT_LLVM_augmentation`` attribute is added to a compilation unit +debugger information entry to indicate that there is additional target +architecture specific information in the debugging information entries of that +compilation unit. This allows a consumer to know what extensions are present +in the debugger information entries as is possible with the augmentation +string of other sections. The format that should be used for the augmentation +string in the lookup by name table and CFI Common Information Entry is also +recommended to allow a consumer to parse the string when it contains +information from multiple vendors. + +The AMDGPU supports programming languages that include online compilation +where the source text may be created at runtime. Therefore, a way to embed the +source text in the debug information is required. For example, the OpenCL +language runtime supports online compilation. See +:ref:`amdgpu-dwarf-line-number-information`. + +Support to allow MD5 checksums to be optionally present in the line table is +added. This allows linking together compilation units where some have MD5 +checksums and some do not. In DWARF Version 5 the file timestamp and file size +can be optional, but if the MD5 checksum is present it must be valid for all +files. See :ref:`amdgpu-dwarf-line-number-information`. + +Support is added for the HIP programming language [:ref:`HIP +`] which is supported by the AMDGPU. See +:ref:`amdgpu-dwarf-language-names`. + +The following sections provide the definitions for the additional operations, +as well as clarifying how existing expression operations, CFI operations, and +attributes behave with respect to generalized location descriptions that +support address spaces and location descriptions that support multiple places. +It has been defined such that it is backwards compatible with DWARF Version 5. +The definitions are intended to fully define well-formed DWARF in a consistent +style based on the DWARF Version 5 specification. Non-normative text is shown +in *italics*. + +The names for the new operations, attributes, and constants include "\ +``LLVM``\ " and are encoded with vendor specific codes so this proposal can be +implemented as an LLVM vendor extension to DWARF Version 5. If accepted these +names would not include the "\ ``LLVM``\ " and would not use encodings in the +vendor range. + +The proposal is described in +:ref:`amdgpu-dwarf-proposed-changes-relative-to-dwarf-version-5` and is +organized to follow the section ordering of DWARF Version 5. It includes notes +to indicate the corresponding DWARF Version 5 sections to which they pertain. +Other notes describe additional changes that may be worth considering, and to +raise questions. + +.. _amdgpu-dwarf-proposed-changes-relative-to-dwarf-version-5: + +Proposed Changes Relative to DWARF Version 5 +============================================ + +General Description +------------------- + +Attribute Types +~~~~~~~~~~~~~~~ + +.. note:: + + This augments DWARF Version 5 section 2.2 and Table 2.2. + +The following table provides the additional attributes. See +:ref:`amdgpu-dwarf-debugging-information-entry-attributes`. + +.. table:: Attribute names + :name: amdgpu-dwarf-attribute-names-table + + =========================== ==================================== + Attribute Usage + =========================== ==================================== + ``DW_AT_LLVM_active_lane`` SIMD or SIMT active lanes + ``DW_AT_LLVM_augmentation`` Compilation unit augmentation string + ``DW_AT_LLVM_lane_pc`` SIMD or SIMT lane program location + ``DW_AT_LLVM_lanes`` SIMD or SIMT thread lane count + ``DW_AT_LLVM_vector_size`` Base type vector size + =========================== ==================================== + +.. _amdgpu-dwarf-expressions: + +DWARF Expressions +~~~~~~~~~~~~~~~~~ + +.. note:: + + This section, and its nested sections, replaces DWARF Version 5 section 2.5 and + section 2.6. The new proposed DWARF expression operations are defined as well + as clarifying the extensions to already existing DWARF Version 5 operations. It is + based on the text of the existing DWARF Version 5 standard. + +DWARF expressions describe how to compute a value or specify a location. + +*The evaluation of a DWARF expression can provide the location of an object, the +value of an array bound, the length of a dynamic string, the desired value +itself, and so on.* + +The evaluation of a DWARF expression can either result in a value or a location +description: + +*value* + + A value has a type and a literal value. It can represent a literal value of + any supported base type of the target architecture. The base type specifies + the size and encoding of the literal value. + + .. note:: + + It may be desirable to add an implicit pointer base type encoding. It would + be used for the type of the value that is produced when the ``DW_OP_deref*`` + operation retrieves the full contents of an implicit pointer location + storage created by the ``DW_OP_implicit_pointer`` or + ``DW_OP_LLVM_aspace_implicit_pointer`` operations. The literal value would + record the debugging information entry and byte dispacement specified by the + associated ``DW_OP_implicit_pointer`` or + ``DW_OP_LLVM_aspace_implicit_pointer`` operations. + + Instead of a base type, a value can have a distinguished generic type, which + is an integral type that has the size of an address in the target architecture + default address space and unspecified signedness. + + *The generic type is the same as the unspecified type used for stack + operations defined in DWARF Version 4 and before.* + + An integral type is a base type that has an encoding of ``DW_ATE_signed``, + ``DW_ATE_signed_char``, ``DW_ATE_unsigned``, ``DW_ATE_unsigned_char``, + ``DW_ATE_boolean``, or any target architecture defined integral encoding in + the inclusive range ``DW_ATE_lo_user`` to ``DW_ATE_hi_user``. + + .. note:: + + It is unclear if ``DW_ATE_address`` is an integral type. GDB does not seem + to consider it as integral. + +*location description* + + *Debugging information must provide consumers a way to find the location of + program variables, determine the bounds of dynamic arrays and strings, and + possibly to find the base address of a subprogram’s stack frame or the return + address of a subprogram. Furthermore, to meet the needs of recent computer + architectures and optimization techniques, debugging information must be able + to describe the location of an object whose location changes over the object’s + lifetime, and may reside at multiple locations simultaneously during parts of + an object's lifetime.* + + Information about the location of program objects is provided by location + descriptions. + + Location descriptions can consist of one or more single location descriptions. + + A single location description specifies the location storage that holds a + program object and a position within the location storage where the program + object starts. The position within the location storage is expressed as a bit + offset relative to the start of the location storage. + + A location storage is a linear stream of bits that can hold values. Each + location storage has a size in bits and can be accessed using a zero-based bit + offset. The ordering of bits within a location storage uses the bit numbering + and direction conventions that are appropriate to the current language on the + target architecture. + + There are five kinds of location storage: + + *memory location storage* + Corresponds to the target architecture memory address spaces. + + *register location storage* + Corresponds to the target architecture registers. + + *implicit location storage* + Corresponds to fixed values that can only be read. + + *undefined location storage* + Indicates no value is available and therefore cannot be read or written. + + *composite location storage* + Allows a mixture of these where some bits come from one location storage and + some from another location storage, or from disjoint parts of the same + location storage. + + .. note:: + + It may be better to add an implicit pointer location storage kind used by + the ``DW_OP_implicit_pointer`` and ``DW_OP_LLVM_aspace_implicit_pointer`` + operations. It would specify the debugger information entry and byte offset + provided by the operations. + + *Location descriptions are a language independent representation of addressing + rules. They are created using DWARF operation expressions of arbitrary + complexity. They can be the result of evaluting a debugger information entry + attribute that specifies an operation expression. In this usage they can + describe the location of an object as long as its lifetime is either static or + the same as the lexical block (see DWARF Version 5 section 3.5) that owns it, + and it does not move during its lifetime. They can be the result of evaluating + a debugger information entry attribute that specifies a location list + expression. In this usage they can describe the location of an object that has + a limited lifetime, changes its location during its lifetime, or has multiple + locations over part or all of its lifetime.* + + If a location description has more than one single location description, the + DWARF expression is ill-formed if the object value held in each single + location description's position within the associated location storage is not + the same value, except for the parts of the value that are uninitialized. + + *A location description that has more than one single location description can + only be created by a location list expression that has overlapping program + location ranges, or certain expression operations that act on a location + description that has more than one single location description. There are no + operation expression operations that can directly create a location + description with more than one single location description.* + + *A location description with more than one single location description can be + used to describe objects that reside in more than one piece of storage at the + same time. An object may have more than one location as a result of + optimization. For example, a value that is only read may be promoted from + memory to a register for some region of code, but later code may revert to + reading the value from memory as the register may be used for other purposes. + For the code region where the value is in a register, any change to the object + value must be made in both the register and the memory so both regions of code + will read the updated value.* + + *A consumer of a location description with more than one single location + description can read the object's value from any of the single location + descriptions (since they all refer to location storage that has the same + value), but must write any changed value to all the single location + descriptions.* + +A DWARF expression can either be encoded as a operation expression (see +:ref:`amdgpu-dwarf-operation-expressions`), or as a location list expression +(see :ref:`amdgpu-dwarf-location-list-expressions`). + +A DWARF expression is evaluated in the context of: + +*A current subprogram* + This may be used in the evaluation of register access operations to support + virtual unwinding of the call stack (see + :ref:`amdgpu-dwarf-call-frame-information`). + +*A current program location* + This may be used in the evaluation of location list expressions to select + amongst multiple program location ranges. It should be the program location + corresponding to the current subprogram. If the current subprogram was reached + by virtual call stack unwinding, then the program location will correspond to + the associated call site. + +*An initial stack* + This is a list of values or location descriptions that will be pushed on the + operation expression evaluation stack in the order provided before evaluation + of an operation expression starts. + + Some debugger information entries have attributes that evaluate their DWARF + expression value with initial stack entries. In all other cases the initial + stack is empty. + +When a DWARF expression is evaluated, it may be specified whether a value or +location description is required as the result kind. + +If a result kind is specified, and the result of the evaluation does not match +the specified result kind, then the implicit conversions described in +:ref:`amdgpu-dwarf-memory-location-description-operations` are performed if +valid. Otherwise, the DWARF expression is ill-formed. + +.. _amdgpu-dwarf-operation-expressions: + +DWARF Operation Expressions ++++++++++++++++++++++++++++ + +An operation expression is comprised of a stream of operations, each consisting +of an opcode followed by zero or more operands. The number of operands is +implied by the opcode. + +Operations represent a postfix operation on a simple stack machine. Each stack +entry can hold either a value or a location description. Operations can act on +entries on the stack, including adding entries and removing entries. If the kind +of a stack entry does not match the kind required by the operation and is not +implicitly convertible to the required kind (see +:ref:`amdgpu-dwarf-memory-location-description-operations`), then the DWARF +operation expression is ill-formed. + +Evaluation of an operation expression starts with an empty stack on which the +entries from the initial stack provided by the context are pushed in the order +provided. Then the operations are evaluated, starting with the first operation +of the stream, until one past the last operation of the stream is reached. The +result of the evaluation is: + +* If evaluation of the DWARF expression requires a location description, then: + + * If the stack is empty, the result is a location description with one + undefined location description. + + *This rule is for backwards compatibility with DWARF Version 5 which has no + explicit operation to create an undefined location description, and uses an + empty operation expression for this purpose.* + + * If the top stack entry is a location description, or can be converted + to one (see :ref:`amdgpu-dwarf-memory-location-description-operations`), + then the result is that, possibly converted, location description. Any other + entries on the stack are discarded. + + * Otherwise the DWARF expression is ill-formed. + + .. note:: + + Could define this case as returning an implicit location description as + if the ``DW_OP_implicit`` operation is performed. + +* If evaluation of the DWARF expression requires a value, then: + + * If the top stack entry is a value, or can be converted to one (see + :ref:`amdgpu-dwarf-memory-location-description-operations`), then the result + is that, possibly converted, value. Any other entries on the stack are + discarded. + + * Otherwise the DWARF expression is ill-formed. + +* If evaluation of the DWARF expression does not specify if a value or location + description is required, then: + + * If the stack is empty, the result is a location description with one + undefined location description. + + *This rule is for backwards compatibility with DWARF Version 5 which has no + explicit operation to create an undefined location description, and uses an + empty operation expression for this purpose.* + + .. note:: + + This rule is consistent with the rule above for when a location + description is requested. However, GDB appears to report this as an error + and no GDB tests appear to cause an empty stack for this case. + + * Otherwise, the top stack entry is returned. Any other entries on the stack + are discarded. + +An operation expression is encoded as a byte block with some form of prefix that +specifies the byte count. It can be used: + +* as the value of a debugging information entry attribute that is encoded using + class ``exprloc`` (see DWARF Version 5 section 7.5.5), + +* as the operand to certain operation expression operations, + +* as the operand to certain call frame information operations (see + :ref:`amdgpu-dwarf-call-frame-information`), + +* and in location list entries (see + :ref:`amdgpu-dwarf-location-list-expressions`). + +.. _amdgpu-dwarf-stack-operations: + +Stack Operations +################ + +The following operations manipulate the DWARF stack. Operations that index the +stack assume that the top of the stack (most recently added entry) has index 0. +They allow the stack entries to be either a value or location description. + +If any stack entry accessed by a stack operation is an incomplete composite +location description (see +:ref:`amdgpu-dwarf-composite-location-description-operations`), then the DWARF +expression is ill-formed. + +.. note:: + + These operations now support stack entries that are values and location + descriptions. + +.. note:: + + If it is desired to also make them work with incomplete composite location + descriptions, then would need to define that the composite location storage + specified by the incomplete composite location description is also replicated + when a copy is pushed. This ensures that each copy of the incomplete composite + location description can update the composite location storage they specify + independently. + +1. ``DW_OP_dup`` + + ``DW_OP_dup`` duplicates the stack entry at the top of the stack. + +2. ``DW_OP_drop`` + + ``DW_OP_drop`` pops the stack entry at the top of the stack and discards it. + +3. ``DW_OP_pick`` + + ``DW_OP_pick`` has a single unsigned 1-byte operand that represents an index + I. A copy of the stack entry with index I is pushed onto the stack. + +4. ``DW_OP_over`` + + ``DW_OP_over`` pushes a copy of the entry with index 1. + + *This is equivalent to a ``DW_OP_pick 1`` operation.* + +5. ``DW_OP_swap`` + + ``DW_OP_swap`` swaps the top two stack entries. The entry at the top of the + stack becomes the second stack entry, and the second stack entry becomes the + top of the stack. + +6. ``DW_OP_rot`` + + ``DW_OP_rot`` rotates the first three stack entries. The entry at the top of + the stack becomes the third stack entry, the second entry becomes the top of + the stack, and the third entry becomes the second entry. + +.. _amdgpu-dwarf-control-flow-operations: + +Control Flow Operations +####################### + +The following operations provide simple control of the flow of a DWARF operation +expression. + +1. ``DW_OP_nop`` + + ``DW_OP_nop`` is a place holder. It has no effect on the DWARF stack + entries. + +2. ``DW_OP_le``, ``DW_OP_ge``, ``DW_OP_eq``, ``DW_OP_lt``, ``DW_OP_gt``, + ``DW_OP_ne`` + + .. note:: + + The same as in DWARF Version 5 section 2.5.1.5. + +3. ``DW_OP_skip`` + + ``DW_OP_skip`` is an unconditional branch. Its single operand is a 2-byte + signed integer constant. The 2-byte constant is the number of bytes of the + DWARF expression to skip forward or backward from the current operation, + beginning after the 2-byte constant. + + If the updated position is at one past the end of the last operation, then + the operation expression evaluation is complete. + + Otherwise, the DWARF expression is ill-formed if the updated operation + position is not in the range of the first to last operation inclusive, or + not at the start of an operation. + +4. ``DW_OP_bra`` + + ``DW_OP_bra`` is a conditional branch. Its single operand is a 2-byte signed + integer constant. This operation pops the top of stack. If the value popped + is not the constant 0, the 2-byte constant operand is the number of bytes of + the DWARF operation expression to skip forward or backward from the current + operation, beginning after the 2-byte constant. + + If the updated position is at one past the end of the last operation, then + the operation expression evaluation is complete. + + Otherwise, the DWARF expression is ill-formed if the updated operation + position is not in the range of the first to last operation inclusive, or + not at the start of an operation. + +5. ``DW_OP_call2, DW_OP_call4, DW_OP_call_ref`` + + ``DW_OP_call2``, ``DW_OP_call4``, and ``DW_OP_call_ref`` perform DWARF + procedure calls during evaluation of a DWARF expression. + + ``DW_OP_call2`` and ``DW_OP_call4``, have one operand that is a 2- or 4-byte + unsigned offset, respectively, of a debugging information entry D in the + current compilation unit. + + ``DW_OP_call_ref`` has one operand that is a 4-byte unsigned value in the + 32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format, + that represents an offset of a debugging information entry D in a + ``.debug_info`` section, which may be contained in an executable or shared + object file other than that containing the operation. For references from + one executable or shared object file to another, the relocation must be + performed by the consumer. + + .. note: + + It is unclear how crossing from one executable or shared object file to + another can work. How would a consumer know which executable or shared + object file is being referenced? In an ELF file the DWARF is in a + non-ALLOC segment so standard dynamic relocations cannot be used. + + *Operand interpretation of* ``DW_OP_call2``\ *,* ``DW_OP_call4``\ *, and* + ``DW_OP_call_ref`` *is exactly like that for* ``DW_FORM_ref2``\ *, + ``DW_FORM_ref4``\ *, and* ``DW_FORM_ref_addr``\ *, respectively.* + + The call operation is evaluated by: + + * If D has a ``DW_AT_location`` attribute that is encoded as a ``exprloc`` + that specifies an operation expression E, then execution of the current + operation expression continues from the first operation of E. Execution + continues until one past the last operation of E is reached, at which + point execution continues with the operation following the call operation. + Since E is evaluated on the same stack as the call, E can use, add, and/or + remove entries already on the stack. + + *Values on the stack at the time of the call may be used as parameters by + the called expression and values left on the stack by the called expression + may be used as return values by prior agreement between the calling and + called expressions.* + + * If D has a ``DW_AT_location`` attribute that is encoded as a ``loclist`` or + ``loclistsptr``, then the specified location list expression E is + evaluated, and the resulting location description is pushed on the stack. + The evaluation of E uses a context that has the same current frame and + current program location as the current operation expression, but an empty + initial stack. + + .. note:: + + This rule avoids having to define how to execute a matched location list + entry operation expression on the same stack as the call when there are + multiple matches. But it allows the call to obtain the location + description for a variable or formal parameter which may use a location + list expression. + + An alternative is to treat the case when D has a ``DW_AT_location`` + attribute that is encoded as a ``loclist`` or ``loclistsptr``, and the + specified location list expression E' matches a single location list + entry with operation expression E, the same as the ``exprloc`` case and + evaluate on the same stack. + + But this is not attractive as if the attribute is for a variable that + happens to end with a non-singleton stack, it will not simply put a + location description on the stack. Presumably the intent of using + ``DW_OP_call*`` on a variable or formal parameter debugger information + entry is to push just one location description on the stack. That + location description may have more than one single location description. + + The previous rule for ``exprloc`` also has the same problem as normally + a variable or formal parameter location expression may leave multiple + entries on the stack and only return the top entry. + + GDB implements ``DW_OP_call*`` by always executing E on the same stack. + If the location list has multiple matching entries, it simply picks the + first one and ignores the rest. This seems fundementally at odds with + the desire to supporting multiple places for variables. + + So, it feels like ``DW_OP_call*`` should both support pushing a location + description on the stack for a variable or formal parameter, and also + support being able to execute an operation expression on the same stack. + Being able to specify a different operation expression for different + program locations seems a desirable feature to retain. + + A solution to that is to have a distinct ``DW_AT_LLVM_proc`` attribute + for the ``DW_TAG_dwarf_procedure`` debugging information entry. Then the + ``DW_AT_location`` attribute expression is always executed separately + and pushes a location description (that may have multiple single + location descriptions), and the ``DW_AT_LLVM_proc`` attribute expression + is always executed on the same stack and can leave anything on the + stack. + + The ``DW_AT_LLVM_proc`` attribute could have the new classes + ``exprproc``, ``loclistproc``, and ``loclistsptrproc`` to indicate that + the expression is executed on the same stack. ``exprproc`` is the same + encoding as ``exprloc``. ``loclistproc`` and ``loclistsptrproc`` are the + same encoding as their non-\ ``proc`` counterparts except the DWARF is + ill-formed if the location list does not match exactly one location list + entry and a default entry is required. These forms indicate explicitly + that the matched single operation expression must be executed on the + same stack. This is better than ad hoc special rules for ``loclistproc`` + and ``loclistsptrproc`` which are currently clearly defined to always + return a location description. The producer then explicitly indicates + the intent through the attribute classes. + + Such a change would be a breaking change for how GDB implements + ``DW_OP_call*``. However, are the breaking cases actually occurring in + practice? GDB could implement the current approach for DWARF Version 5, + and the new semantics for DWARF Version 6 which has been done for some + other features. + + Another option is to limit the execution to be on the same stack only to + the evaluation of an expression E that is the value of a + ``DW_AT_location`` attribute of a ``DW_TAG_dwarf_procedure`` debugging + information entry. The DWARF would be ill-formed if E is a location list + expression that does not match exactly one location list entry. In all + other cases the evaluation of an expression E that is the value of a + ``DW_AT_location`` attribute would evaluate E with a context that has + the same current frame and current program location as the current + operation expression, but an empty initial stack, and push the resulting + location description on the stack. + + * If D has a ``DW_AT_const_value`` attribute with a value V, then it is as + if a ``DW_OP_implicit_value V`` operation was executed. + + *This allows a call operation to be used to compute the location + description for any variable or formal parameter regardless of whether the + producer has optimized it to a constant. This is consistent with the + ``DW_OP_implicit_pointer`` operation.* + + .. note:: + + Alternatively, could deprecate using ``DW_AT_const_value`` for + ``DW_TAG_variable`` and ``DW_TAG_formal_parameter`` debugger information + entries that are constants and instead use ``DW_AT_location`` with an + operation expression that results in a location description with one + implicit location description. Then this rule would not be required. + + * Otherwise, there is no effect and no changes are made to the stack. + + .. note:: + + In DWARF Version 5, if D does not have a ``DW_AT_location`` then + ``DW_OP_call*`` is defined to have no effect. It is unclear that this is + the right definition as a producer should be able to rely on using + ``DW_OP_call*`` to get a location description for any non-\ + ``DW_TAG_dwarf_procedure`` debugging information entries. Also, the + producer should not be creating DWARF with ``DW_OP_call*`` to a + ``DW_TAG_dwarf_procedure`` that does not have a ``DW_AT_location`` + attribute. So, should this case be defined as an ill-formed DWARF + expression? + + *The* ``DW_TAG_dwarf_procedure`` *debugging information entry can be used to + define DWARF procedures that can be called.* + +.. _amdgpu-dwarf-value-operations: + +Value Operations +################ + +This section describes the operations that push values on the stack. + +Each value stack entry has a type and a literal value and can represent a +literal value of any supported base type of the target architecture. The base +type specifies the size and encoding of the literal value. + +Instead of a base type, value stack entries can have a distinguished generic +type, which is an integral type that has the size of an address in the target +architecture default address space and unspecified signedness. + +*The generic type is the same as the unspecified type used for stack operations +defined in DWARF Version 4 and before.* + +An integral type is a base type that has an encoding of ``DW_ATE_signed``, +``DW_ATE_signed_char``, ``DW_ATE_unsigned``, ``DW_ATE_unsigned_char``, +``DW_ATE_boolean``, or any target architecture defined integral encoding in the +inclusive range ``DW_ATE_lo_user`` to ``DW_ATE_hi_user``. + +.. note:: + + Unclear if ``DW_ATE_address`` is an integral type. GDB does not seem to + consider it as integral. + +.. _amdgpu-dwarf-literal-operations: + +Literal Operations +^^^^^^^^^^^^^^^^^^ + +The following operations all push a literal value onto the DWARF stack. + +Operations other than ``DW_OP_const_type`` push a value V with the generic type. +If V is larger than the generic type, then V is truncated to the generic type +size and the low-order bits used. + +1. ``DW_OP_lit0``, ``DW_OP_lit1``, ..., ``DW_OP_lit31`` + + ``DW_OP_lit`` operations encode an unsigned literal value N from 0 + through 31, inclusive. They push the value N with the generic type. + +2. ``DW_OP_const1u``, ``DW_OP_const2u``, ``DW_OP_const4u``, ``DW_OP_const8u`` + + ``DW_OP_constu`` operations have a single operand that is a 1, 2, 4, or + 8-byte unsigned integer constant U, respectively. They push the value U with + the generic type. + +3. ``DW_OP_const1s``, ``DW_OP_const2s``, ``DW_OP_const4s``, ``DW_OP_const8s`` + + ``DW_OP_consts`` operations have a single operand that is a 1, 2, 4, or + 8-byte signed integer constant S, respectively. They push the value S with + the generic type. + +4. ``DW_OP_constu`` + + ``DW_OP_constu`` has a single unsigned LEB128 integer operand N. It pushes + the value N with the generic type. + +5. ``DW_OP_consts`` + + ``DW_OP_consts`` has a single signed LEB128 integer operand N. It pushes the + value N with the generic type. + +6. ``DW_OP_constx`` + + ``DW_OP_constx`` has a single unsigned LEB128 integer operand that + represents a zero-based index into the ``.debug_addr`` section relative to + the value of the ``DW_AT_addr_base`` attribute of the associated compilation + unit. The value N in the ``.debug_addr`` section has the size of the generic + type. It pushes the value N with the generic type. + + *The* ``DW_OP_constx`` *operation is provided for constants that require + link-time relocation but should not be interpreted by the consumer as a + relocatable address (for example, offsets to thread-local storage).* + +9. ``DW_OP_const_type`` + + ``DW_OP_const_type`` has three operands. The first is an unsigned LEB128 + integer that represents the offset of a debugging information entry D in the + current compilation unit, that provides the type of the constant value. The + second is a 1-byte unsigned integral constant S. The third is a block of + bytes B, with a length equal to S. + + T is the bit size of the type D. The least significant T bits of B are + interpreted as a value V of the type D. It pushes the value V with the type + D. + + The DWARF is ill-formed if D is not a ``DW_TAG_base_type`` debugging + information entry, or if T divided by 8 and rounded up to a multiple of 8 + (the byte size) is not equal to S. + + *While the size of the byte block B can be inferred from the type D + definition, it is encoded explicitly into the operation so that the + operation can be parsed easily without reference to the* ``.debug_info`` + *section.* + +10. ``DW_OP_LLVM_push_lane`` *New* + + ``DW_OP_LLVM_push_lane`` pushes a value with the generic type that is the + target architecture specific lane identifier of the thread of execution for + which a user presented expression is currently being evaluated. + + *For languages that are implemented using a SIMD or SIMT execution model, + this is the lane number that corresponds to the source language thread of + execution upon which the user is focused.* + +.. _amdgpu-dwarf-arithmetic-logical-operations: + +Arithmetic and Logical Operations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. note:: + + This section is the same as DWARF Version 5 section 2.5.1.4. + +.. _amdgpu-dwarf-type-conversions-operations: + +Type Conversion Operations +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. note:: + + This section is the same as DWARF Version 5 section 2.5.1.6. + +.. _amdgpu-dwarf-general-operations: + +Special Value Operations +^^^^^^^^^^^^^^^^^^^^^^^^ + +There are these special value operations currently defined: + +1. ``DW_OP_regval_type`` + + ``DW_OP_regval_type`` has two operands. The first is an unsigned LEB128 + integer that represents a register number R. The second is an unsigned + LEB128 integer that represents the offset of a debugging information entry D + in the current compilation unit, that provides the type of the register + value. + + The contents of register R are interpreted as a value V of the type D. The + value V is pushed on the stack with the type D. + + The DWARF is ill-formed if D is not a ``DW_TAG_base_type`` debugging + information entry, or if the size of type D is not the same as the size of + register R. + + .. note:: + + Should DWARF allow the type D to be a different size to the size of the + register R? Requiring them to be the same bit size avoids any issue of + conversion as the bit contents of the register is simply interpreted as a + value of the specified type. If a conversion is wanted it can be done + explicitly using a ``DW_OP_convert`` operation. + + GDB has a per register hook that allows a target specific conversion on a + register by register basis. It defaults to truncation of bigger registers, + and to actually reading bytes from the next register (or reads out of + bounds for the last register) for smaller registers. There are no GDB + tests that read a register out of bounds (except an illegal hand written + assembly test). + +2. ``DW_OP_deref`` + + The ``DW_OP_deref`` operation pops one stack entry that must be a location + description L. + + A value of the bit size of the generic type is retrieved from the location + storage specified by L. The value V retrieved is pushed on the stack with + the generic type. + + If any bit of the value is retrieved from the undefined location storage, or + the offset of any bit exceeds the size of the location storage specified by + L, then the DWARF expression is ill-formed. + + See :ref:`amdgpu-dwarf-implicit-location-descriptions` for special rules + concerning implicit location descriptions created by the + ``DW_OP_implicit_pointer`` and ``DW_OP_LLVM_implicit_aspace_pointer`` + operations. + + *If L, or the location description of any composite location description + part that is a subcomponent of L, has more than one single location + description, then any one of them can be selected as they are required to + all have the same value. For any single location description SL, bits are + retrieved from the associated storage location starting at the bit offset + specified by SL. For a composite location description, the retrieved bits + are the concatenation of the N bits from each composite location part PL, + where N is limited to the size of PL.* + +3. ``DW_OP_deref_size`` + + ``DW_OP_deref_size`` has a single 1-byte unsigned integral constant that + represents a byte result size S. + + It pops one stack entry that must be a location description L. + + T is the smaller of the generic type size and S scaled by 8 (the byte size). + A value V of T bits is retrieved from the location storage specified by L. + If V is smaller than the size of the generic type, V is zero-extended to the + generic type size. V is pushed onto the stack with the generic type. + + The DWARF expression is ill-formed if any bit of the value is retrieved from + the undefined location storage, or if the offset of any bit exceeds the size + of the location storage specified by L. + + .. note:: + + Truncating the value when S is larger than the generic type matches what + GDB does. This allows the generic type size to not be a integral byte + size. It does allow S to be arbitrarily large. Should S be restricted to + the size of the generic type rounded up to a multiple of 8? + + See :ref:`amdgpu-dwarf-implicit-location-descriptions` for special rules + concerning implicit location descriptions created by the + ``DW_OP_implicit_pointer`` and ``DW_OP_LLVM_implicit_aspace_pointer`` + operations. + +4. ``DW_OP_deref_type`` + + ``DW_OP_deref_type`` has two operands. The first is a 1-byte unsigned + integral constant S. The second is an unsigned LEB128 integer that + represents the offset of a debugging information entry D in the current + compilation unit, that provides the type of the result value. + + It pops one stack entry that must be a location description L. T is the bit + size of the type D. A value V of T bits is retrieved from the location + storage specified by L. V is pushed on the stack with the type D. + + The DWARF is ill-formed if D is not a ``DW_TAG_base_type`` debugging + information entry, if T divided by 8 and rounded up to a multiple of 8 (the + byte size) is not equal to S, if any bit of the value is retrieved from the + undefined location storage, or if the offset of any bit exceeds the size of + the location storage specified by L. + + See :ref:`amdgpu-dwarf-implicit-location-descriptions` for special rules + concerning implicit location descriptions created by the + ``DW_OP_implicit_pointer`` and ``DW_OP_LLVM_implicit_aspace_pointer`` + operations. + + *While the size of the pushed value V can be inferred from the type D + definition, it is encoded explicitly into the operation so that the + operation can be parsed easily without reference to the* ``.debug_info`` + *section.* + + .. note:: + + It is unclear why the operand S is needed. Unlike ``DW_OP_const_type``, + the size is not needed for parsing. Any evaluation needs to get the base + type to record with the value to know its encoding and bit size. + + This definition allows the base type to be a bit size since there seems no + reason to restrict it. + +5. ``DW_OP_xderef`` *Deprecated* + + ``DW_OP_xderef`` pops two stack entries. The first must be an integral type + value that represents an address A. The second must be an integral type + value that represents a target architecture specific address space + identifier AS. + + The operation is equivalent to performing ``DW_OP_swap; + DW_OP_LLVM_form_aspace_address; DW_OP_deref``. The value V retrieved is left + on the stack with the generic type. + + *This operation is deprecated as the* ``DW_OP_LLVM_form_aspace_address`` + *operation can be used and provides greater expressiveness.* + +6. ``DW_OP_xderef_size`` *Deprecated* + + ``DW_OP_xderef_size`` has a single 1-byte unsigned integral constant that + represents a byte result size S. + + It pops two stack entries. The first must be an integral type value that + represents an address A. The second must be an integral type value that + represents a target architecture specific address space identifier AS. + + The operation is equivalent to performing ``DW_OP_swap; + DW_OP_LLVM_form_aspace_address; DW_OP_deref_size S``. The zero-extended + value V retrieved is left on the stack with the generic type. + + *This operation is deprecated as the* ``DW_OP_LLVM_form_aspace_address`` + *operation can be used and provides greater expressiveness.* + +7. ``DW_OP_xderef_type`` *Deprecated* + + ``DW_OP_xderef_type`` has two operands. The first is a 1-byte unsigned + integral constant S. The second operand is an unsigned LEB128 + integer R that represents the offset of a debugging information entry D in + the current compilation unit, that provides the type of the result value. + + It pops two stack entries. The first must be an integral type value that + represents an address A. The second must be an integral type value that + represents a target architecture specific address space identifier AS. + + The operation is equivalent to performing ``DW_OP_swap; + DW_OP_LLVM_form_aspace_address; DW_OP_deref_type S R``. The value V + retrieved is left on the stack with the type D. + + *This operation is deprecated as the* ``DW_OP_LLVM_form_aspace_address`` + *operation can be used and provides greater expressiveness.* + +8. ``DW_OP_entry_value`` *Deprecated* + + ``DW_OP_entry_value`` pushes the value that the described location held upon + entering the current subprogram. + + It has two operands. The first is an unsigned LEB128 integer S. The second + is a block of bytes, with a length equal S, interpreted as a DWARF + operation expression E. + + E is evaluated as if it had been evaluated upon entering the current + subprogram with an empty initial stack. + + .. note:: + + It is unclear what this means. What is the current program location and + current frame that must be used? Does this require reverse execution so + the register and memory state are as it was on entry to the current + subprogram? + + The DWARF expression is ill-formed if the evaluation of E executes a + ``DW_OP_push_object_address`` operation. + + If the result of E is a location description with one register location + description (see :ref:`amdgpu-dwarf-register-location-descriptions`), + ``DW_OP_entry_value`` pushes the value that register had upon entering the + current subprogram. The value entry type is the target architecture register + base type. If the register value is undefined or the register location + description bit offset is not 0, then the DWARF expression is ill-formed. + + *The register location description provides a more compact form for the case + where the value was in a register on entry to the subprogram.* + + If the result of E is a value V, ``DW_OP_entry_value`` pushes V on the + stack. + + Otherwise, the DWARF expression is ill-formed. + + *The values needed to evaluate* ``DW_OP_entry_value`` *could be obtained in + several ways. The consumer could suspend execution on entry to the + subprogram, record values needed by* ``DW_OP_entry_value`` *expressions + within the subprogram, and then continue. When evaluating* + ``DW_OP_entry_value``\ *, the consumer would use these recorded values + rather than the current values. Or, when evaluating* ``DW_OP_entry_value``\ + *, the consumer could virtually unwind using the Call Frame Information + (see* :ref:`amdgpu-dwarf-call-frame-information`\ *) to recover register + values that might have been clobbered since the subprogram entry point.* + + *The* ``DW_OP_entry_value`` *operation is deprecated as its main usage is + provided by other means. DWARF Version 5 added the* + ``DW_TAG_call_site_parameter`` *debugger information entry for call sites + that has* ``DW_AT_call_value``\ *,* ``DW_AT_call_data_location``\ *, and* + ``DW_AT_call_data_value`` *attributes that provide DWARF expressions to + compute actual parameter values at the time of the call, and requires the + producer to ensure the expressions are valid to evaluate even when virtually + unwound. The* ``DW_OP_LLVM_call_frame_entry_reg`` *operation provides access + to registers in the virtually unwound calling frame.* + + .. note:: + + It is unclear why this operation is defined this way. How would a consumer + know what values have to be saved on entry to the subprogram? Does it have + to parse every expression of every ``DW_OP_entry_value`` operation to + capture all the possible results needed? Or does it have to implement + reverse execution so it can evaluate the expression in the context of the + entry of the subprogram so it can obtain the entry point register and + memory values? Or does the compiler somehow instruct the consumer how to + create the saved copies of the variables on entry? + + If the expression is simply using existing variables, then it is just a + regular expression and no special operation is needed. If the main purpose + is only to read the entry value of a register using CFI then it would be + better to have an operation that explicitly does just that such as the + proposed ``DW_OP_LLVM_call_frame_entry_reg`` operation. + + GDB only seems to implement ``DW_OP_entry_value`` when E is exactly + ``DW_OP_reg*`` or ``DW_OP_breg*; DW_OP_deref*``. It evaluates E in the + context of the calling subprogram and the calling call site program + location. But the wording suggests that is not the intention. + + Given these issues it is suggested ``DW_OP_entry_value`` is deprecated in + favor of using the new facities that have well defined semantics and + implementations. + +.. _amdgpu-dwarf-location-description-operations: + +Location Description Operations +############################### + +This section describes the operations that push location descriptions on the +stack. + +General Location Description Operations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +1. ``DW_OP_LLVM_offset`` *New* + + ``DW_OP_LLVM_offset`` pops two stack entries. The first must be an integral + type value that represents a byte displacement B. The second must be a + location description L. + + It adds the value of B scaled by 8 (the byte size) to the bit offset of each + single location description SL of L, and pushes the updated L. + + If the updated bit offset of any SL is less than 0 or greater than or equal + to the size of the location storage specified by SL, then the DWARF + expression is ill-formed. + +2. ``DW_OP_LLVM_offset_uconst`` *New* + + ``DW_OP_LLVM_offset_uconst`` has a single unsigned LEB128 integer operand + that represents a byte displacement B. + + The operation is equivalent to performing ``DW_OP_constu B; + DW_OP_LLVM_offset``. + + *This operation is supplied specifically to be able to encode more field + displacements in two bytes than can be done with* ``DW_OP_lit*; + DW_OP_LLVM_offset``\ *.* + + .. note:: + + Should this be named ``DW_OP_LLVM_offset_uconst`` to match + ``DW_OP_plus_uconst``, or ``DW_OP_LLVM_offset_constu`` to match + ``DW_OP_constu``? + +3. ``DW_OP_LLVM_bit_offset`` *New* + + ``DW_OP_LLVM_bit_offset`` pops two stack entries. The first must be an + integral type value that represents a bit displacement B. The second must be + a location description L. + + It adds the value of B to the bit offset of each single location description + SL of L, and pushes the updated L. + + If the updated bit offset of any SL is less than 0 or greater than or equal + to the size of the location storage specified by SL, then the DWARF + expression is ill-formed. + +4. ``DW_OP_push_object_address`` + + ``DW_OP_push_object_address`` pushes the location description L of the + object currently being evaluated as part of evaluation of a user presented + expression. + + This object may correspond to an independent variable described by its own + debugging information entry or it may be a component of an array, structure, + or class whose address has been dynamically determined by an earlier step + during user expression evaluation. + + *This operation provides explicit functionality (especially for arrays + involving descriptions) that is analogous to the implicit push of the base + location description of a structure prior to evaluation of a + ``DW_AT_data_member_location`` to access a data member of a structure.* + +5. ``DW_OP_LLVM_call_frame_entry_reg`` *New* + + ``DW_OP_LLVM_call_frame_entry_reg`` has a single unsigned LEB128 integer + operand that represents a target architecture register number R. + + It pushes a location description L that holds the value of register R on + entry to the current subprogram as defined by the Call Frame Information + (see :ref:`amdgpu-dwarf-call-frame-information`). + + *If there is no Call Frame Information defined, then the default rules for + the target architecture are used. If the register rule is* undefined\ *, then + the undefined location description is pushed. If the register rule is* same + value\ *, then a register location description for R is pushed.* + +Undefined Location Description Operations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +*The undefined location storage represents a piece or all of an object that is +present in the source but not in the object code (perhaps due to optimization). +Neither reading nor writing to the undefined location storage is meaningful.* + +An undefined location description specifies the undefined location storage. +There is no concept of the size of the undefined location storage, nor of a bit +offset for an undefined location description. The ``DW_OP_LLVM_*offset`` +operations leave an undefined location description unchanged. The +``DW_OP_*piece`` operations can explicitly or implicitly specify an undefined +location description, allowing any size and offset to be specified, and results +in a part with all undefined bits. + +1. ``DW_OP_LLVM_undefined`` *New* + + ``DW_OP_LLVM_undefined`` pushes a location description L that comprises one + undefined location description SL. + +.. _amdgpu-dwarf-memory-location-description-operations: + +Memory Location Description Operations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Each of the target architecture specific address spaces has a corresponding +memory location storage that denotes the linear addressable memory of that +address space. The size of each memory location storage corresponds to the range +of the addresses in the corresponding address space. + +*It is target architecture defined how address space location storage maps to +target architecture physical memory. For example, they may be independent +memory, or more than one location storage may alias the same physical memory +possibly at different offsets and with different interleaving. The mapping may +also be dictated by the source language address classes.* + +A memory location description specifies a memory location storage. The bit +offset corresponds to a bit position within a byte of the memory. Bits accessed +using a memory location description, access the corresponding target +architecture memory starting at the bit position within the byte specified by +the bit offset. + +A memory location description that has a bit offset that is a multiple of 8 (the +byte size) is defined to be a byte address memory location description. It has a +memory byte address A that is equal to the bit offset divided by 8. + +A memory location description that does not have a bit offset that is a multiple +of 8 (the byte size) is defined to be a bit field memory location description. +It has a bit position B equal to the bit offset modulo 8, and a memory byte +address A equal to the bit offset minus B that is then divided by 8. + +The address space AS of a memory location description is defined to be the +address space that corresponds to the memory location storage associated with +the memory location description. + +A location description that is comprised of one byte address memory location +description SL is defined to be a memory byte address location description. It +has a byte address equal to A and an address space equal to AS of the +corresponding SL. + +``DW_ASPACE_none`` is defined as the target architecture default address space. + +If a stack entry is required to be a location description, but it is a value V +with the generic type, then it is implicitly converted to a location description +L with one memory location description SL. SL specifies the memory location +storage that corresponds to the target architecture default address space with a +bit offset equal to V scaled by 8 (the byte size). + +.. note:: + + If it is wanted to allow any integral type value to be implicitly converted to + a memory location description in the target architecture default address + space: + + If a stack entry is required to be a location description, but is a value V + with an integral type, then it is implicitly converted to a location + description L with a one memory location description SL. If the type size of + V is less than the generic type size, then the value V is zero extended to + the size of the generic type. The least significant generic type size bits + are treated as a twos-complement unsigned value to be used as an address A. + SL specifies memory location storage corresponding to the target + architecture default address space with a bit offset equal to A scaled by 8 + (the byte size). + + The implicit conversion could also be defined as target architecture specific. + For example, GDB checks if V is an integral type. If it is not it gives an + error. Otherwise, GDB zero-extends V to 64 bits. If the GDB target defines a + hook function, then it is called. The target specific hook function can modify + the 64-bit value, possibly sign extending based on the original value type. + Finally, GDB treats the 64-bit value V as a memory location address. + +If a stack entry is required to be a location description, but it is an implicit +pointer value IPV with the target architecture default address space, then it is +implicitly converted to a location description with one single location +description specified by IPV. See +:ref:`amdgpu-dwarf-implicit-location-descriptions`. + +.. note:: + + Is this rule required for DWARF Version 5 backwards compatibility? If not, it + can be eliminated, and the producer can use + ``DW_OP_LLVM_form_aspace_address``. + +If a stack entry is required to be a value, but it is a location description L +with one memory location description SL in the target architecture default +address space with a bit offset B that is a multiple of 8, then it is implicitly +converted to a value equal to B divided by 8 (the byte size) with the generic +type. + +1. ``DW_OP_addr`` + + ``DW_OP_addr`` has a single byte constant value operand, which has the size + of the generic type, that represents an address A. + + It pushes a location description L with one memory location description SL + on the stack. SL specifies the memory location storage corresponding to the + target architecture default address space with a bit offset equal to A + scaled by 8 (the byte size). + + *If the DWARF is part of a code object, then A may need to be relocated. For + example, in the ELF code object format, A must be adjusted by the difference + between the ELF segment virtual address and the virtual address at which the + segment is loaded.* + +2. ``DW_OP_addrx`` + + ``DW_OP_addrx`` has a single unsigned LEB128 integer operand that represents + a zero-based index into the ``.debug_addr`` section relative to the value of + the ``DW_AT_addr_base`` attribute of the associated compilation unit. The + address value A in the ``.debug_addr`` section has the size of the generic + type. + + It pushes a location description L with one memory location description SL + on the stack. SL specifies the memory location storage corresponding to the + target architecture default address space with a bit offset equal to A + scaled by 8 (the byte size). + + *If the DWARF is part of a code object, then A may need to be relocated. For + example, in the ELF code object format, A must be adjusted by the difference + between the ELF segment virtual address and the virtual address at which the + segment is loaded.* + +3. ``DW_OP_LLVM_form_aspace_address`` *New* + + ``DW_OP_LLVM_form_aspace_address`` pops top two stack entries. The first + must be an integral type value that represents a target architecture + specific address space identifier AS. The second must be an integral type + value that represents an address A. + + The address size S is defined as the address bit size of the target + architecture specific address space that corresponds to AS. + + A is adjusted to S bits by zero extending if necessary, and then treating the + least significant S bits as a twos-complement unsigned value A'. + + It pushes a location description L with one memory location description SL + on the stack. SL specifies the memory location storage that corresponds to + AS with a bit offset equal to A' scaled by 8 (the byte size). + + The DWARF expression is ill-formed if AS is not one of the values defined by + the target architecture specific ``DW_ASPACE_*`` values. + + See :ref:`amdgpu-dwarf-implicit-location-descriptions` for special rules + concerning implicit pointer values produced by dereferencing implicit + location descriptions created by the ``DW_OP_implicit_pointer`` and + ``DW_OP_LLVM_implicit_aspace_pointer`` operations. + +4. ``DW_OP_form_tls_address`` + + ``DW_OP_form_tls_address`` pops one stack entry that must be an integral + type value and treats it as a thread-local storage address T. + + It pushes a location description L with one memory location description SL + on the stack. SL is the target architecture specific memory location + description that corresponds to the thread-local storage address T. + + The meaning of the thread-local storage address T is defined by the run-time + environment. If the run-time environment supports multiple thread-local + storage blocks for a single thread, then the block corresponding to the + executable or shared library containing this DWARF expression is used. + + *Some implementations of C, C++, Fortran, and other languages support a + thread-local storage class. Variables with this storage class have distinct + values and addresses in distinct threads, much as automatic variables have + distinct values and addresses in each subprogram invocation. Typically, + there is a single block of storage containing all thread-local variables + declared in the main executable, and a separate block for the variables + declared in each shared library. Each thread-local variable can then be + accessed in its block using an identifier. This identifier is typically a + byte offset into the block and pushed onto the DWARF stack by one of the* + ``DW_OP_const*`` *operations prior to the* ``DW_OP_form_tls_address`` + *operation. Computing the address of the appropriate block can be complex + (in some cases, the compiler emits a function call to do it), and difficult + to describe using ordinary DWARF location descriptions. Instead of forcing + complex thread-local storage calculations into the DWARF expressions, the* + ``DW_OP_form_tls_address`` *allows the consumer to perform the computation + based on the target architecture specific run-time environment.* + +5. ``DW_OP_call_frame_cfa`` + + ``DW_OP_call_frame_cfa`` pushes the location description L of the Canonical + Frame Address (CFA) of the current subprogram, obtained from the Call Frame + Information on the stack. See :ref:`amdgpu-dwarf-call-frame-information`. + + *Although the value of the* ``DW_AT_frame_base`` *attribute of the debugger + information entry corresponding to the current subprogram can be computed + using a location list expression, in some cases this would require an + extensive location list because the values of the registers used in + computing the CFA change during a subprogram execution. If the Call Frame + Information is present, then it already encodes such changes, and it is + space efficient to reference that using the* ``DW_OP_call_frame_cfa`` + *operation.* + +6. ``DW_OP_fbreg`` + + ``DW_OP_fbreg`` has a single signed LEB128 integer operand that represents a + byte displacement B. + + The location description L for the *frame base* of the current subprogram is + obtained from the ``DW_AT_frame_base`` attribute of the debugger information + entry corresponding to the current subprogram as described in + :ref:`amdgpu-dwarf-debugging-information-entry-attributes`. + + The location description L is updated as if the ``DW_OP_LLVM_offset_uconst + B`` operation was applied. The updated L is pushed on the stack. + +7. ``DW_OP_breg0``, ``DW_OP_breg1``, ..., ``DW_OP_breg31`` + + The ``DW_OP_breg`` operations encode the numbers of up to 32 registers, + numbered from 0 through 31, inclusive. The register number R corresponds to + the N in the operation name. + + They have a single signed LEB128 integer operand that represents a byte + displacement B. + + The address space identifier AS is defined as the one corresponding to the + target architecture specific default address space. + + The address size S is defined as the address bit size of the target + architecture specific address space corresponding to AS. + + The contents of the register specified by R are retrieved as a + twos-complement unsigned value and zero extended to S bits. B is added and + the least significant S bits are treated as a twos-complement unsigned value + to be used as an address A. + + They push a location description L comprising one memory location + description LS on the stack. LS specifies the memory location storage that + corresponds to AS with a bit offset equal to A scaled by 8 (the byte size). + +8. ``DW_OP_bregx`` + + ``DW_OP_bregx`` has two operands. The first is an unsigned LEB128 integer + that represents a register number R. The second is a signed LEB128 + integer that represents a byte displacement B. + + The action is the same as for ``DW_OP_breg`` except that R is used as the + register number and B is used as the byte displacement. + +9. ``DW_OP_LLVM_aspace_bregx`` *New* + + ``DW_OP_LLVM_aspace_bregx`` has two operands. The first is an unsigned + LEB128 integer that represents a register number R. The second is a signed + LEB128 integer that represents a byte displacement B. It pops one stack + entry that is required to be an integral type value that represents a target + architecture specific address space identifier AS. + + The action is the same as for ``DW_OP_breg`` except that R is used as the + register number, B is used as the byte displacement, and AS is used as the + address space identifier. + + The DWARF expression is ill-formed if AS is not one of the values defined by + the target architecture specific ``DW_ASPACE_*`` values. + + .. note:: + + Could also consider adding ``DW_OP_aspace_breg0, DW_OP_aspace_breg1, ..., + DW_OP_aspace_bref31`` which would save encoding size. + +.. _amdgpu-dwarf-register-location-descriptions: + +Register Location Description Operations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There is a register location storage that corresponds to each of the target +architecture registers. The size of each register location storage corresponds +to the size of the corresponding target architecture register. + +A register location description specifies a register location storage. The bit +offset corresponds to a bit position within the register. Bits accessed using a +register location description access the corresponding target architecture +register starting at the specified bit offset. + +1. ``DW_OP_reg0``, ``DW_OP_reg1``, ..., ``DW_OP_reg31`` + + ``DW_OP_reg`` operations encode the numbers of up to 32 registers, + numbered from 0 through 31, inclusive. The target architecture register + number R corresponds to the N in the operation name. + + They push a location description L that specifies one register location + description SL on the stack. SL specifies the register location storage that + corresponds to R with a bit offset of 0. + +2. ``DW_OP_regx`` + + ``DW_OP_regx`` has a single unsigned LEB128 integer operand that represents + a target architecture register number R. + + It pushes a location description L that specifies one register location + description SL on the stack. SL specifies the register location storage that + corresponds to R with a bit offset of 0. + +*These operations obtain a register location. To fetch the contents of a +register, it is necessary to use* ``DW_OP_regval_type``\ *, use one of the* +``DW_OP_breg*`` *register-based addressing operations, or use* ``DW_OP_deref*`` +*on a register location description.* + +.. _amdgpu-dwarf-implicit-location-descriptions: + +Implicit Location Description Operations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Implicit location storage represents a piece or all of an object which has no +actual location in the program but whose contents are nonetheless known, either +as a constant or can be computed from other locations and values in the program. + +An implicit location description specifies an implicit location storage. The bit +offset corresponds to a bit position within the implicit location storage. Bits +accessed using an implicit location description, access the corresponding +implicit storage value starting at the bit offset. + +1. ``DW_OP_implicit_value`` + + ``DW_OP_implicit_value`` has two operands. The first is an unsigned LEB128 + integer that represents a byte size S. The second is a block of bytes with a + length equal to S treated as a literal value V. + + An implicit location storage LS is created with the literal value V and a + size of S. + + It pushes location description L with one implicit location description SL + on the stack. SL specifies LS with a bit offset of 0. + +2. ``DW_OP_stack_value`` + + ``DW_OP_stack_value`` pops one stack entry that must be a value V. + + An implicit location storage LS is created with the literal value V and a + size equal to V's base type size. + + It pushes a location description L with one implicit location description SL + on the stack. SL specifies LS with a bit offset of 0. + + *The* ``DW_OP_stack_value`` *operation specifies that the object does not + exist in memory, but its value is nonetheless known. In this form, the + location description specifies the actual value of the object, rather than + specifying the memory or register storage that holds the value.* + + See :ref:`amdgpu-dwarf-implicit-location-descriptions` for special rules + concerning implicit pointer values produced by dereferencing implicit + location descriptions created by the ``DW_OP_implicit_pointer`` and + ``DW_OP_LLVM_implicit_aspace_pointer`` operations. + + .. note:: + + Since location descriptions are allowed on the stack, the + ``DW_OP_stack_value`` operation no longer terminates the DWARF operation + expression execution as in DWARF Version 5. + +3. ``DW_OP_implicit_pointer`` + + *An optimizing compiler may eliminate a pointer, while still retaining the + value that the pointer addressed.* ``DW_OP_implicit_pointer`` *allows a + producer to describe this value.* + + ``DW_OP_implicit_pointer`` *specifies an object is a pointer to the target + architecture default address space that cannot be represented as a real + pointer, even though the value it would point to can be described. In this + form, the location description specifies a debugging information entry that + represents the actual location description of the object to which the + pointer would point. Thus, a consumer of the debug information would be able + to access the dereferenced pointer, even when it cannot access the pointer + itself.* + + ``DW_OP_implicit_pointer`` has two operands. The first is a 4-byte unsigned + value in the 32-bit DWARF format, or an 8-byte unsigned value in the 64-bit + DWARF format, that represents a debugging information entry reference R. The + second is a signed LEB128 integer that represents a byte displacement B. + + R is used as the offset of a debugging information entry D in a + ``.debug_info`` section, which may be contained in an executable or shared + object file other than that containing the operation. For references from one + executable or shared object file to another, the relocation must be + performed by the consumer. + + *The first operand interpretation is exactly like that for* + ``DW_FORM_ref_addr``\ *.* + + The address space identifier AS is defined as the one corresponding to the + target architecture specific default address space. + + The address size S is defined as the address bit size of the target + architecture specific address space corresponding to AS. + + An implicit location storage LS is created with the debugging information + entry D, address space AS, and size of S. + + It pushes a location description L that comprises one implicit location + description SL on the stack. SL specifies LS with a bit offset of 0. + + If a ``DW_OP_deref*`` operation pops a location description L', and + retrieves S bits where both: + + 1. All retrieved bits come from an implicit location description that + refers to an implicit location storage that is the same as LS. + + *Note that all bits do not have to come from the same implicit location + description, as L' may involve composite location descriptors.* + + 2. The bits come from consecutive ascending offsets within their respective + implicit location storage. + + *These rules are equivalent to retrieving the complete contents of LS.* + + Then the value V pushed by the ``DW_OP_deref*`` operation is an implicit + pointer value IPV with a target architecture specific address space of AS, a + debugging information entry of D, and a base type of T. If AS is the target + architecture default address space, then T is the generic type. Otherwise, T + is a target architecture specific integral type with a bit size equal to S. + + Otherwise, if a ``DW_OP_deref*`` operation is applied to a location + description such that some retrieved bits come from an implicit location + storage that is the same as LS, then the DWARF expression is ill-formed. + + If IPV is either implicitly converted to a location description (only done + if AS is the target architecture default address space) or used by + ``DW_OP_LLVM_form_aspace_address`` (only done if the address space specified + is AS), then the resulting location description RL is: + + * If D has a ``DW_AT_location`` attribute, the DWARF expression E from the + ``DW_AT_location`` attribute is evaluated as a location description. The + current subprogram and current program location of the evaluation context + that is accessing IPV is used for the evaluation context of E, together + with an empty initial stack. RL is the expression result. + + * If D has a ``DW_AT_const_value`` attribute, then an implicit location + storage RLS is created from the ``DW_AT_const_value`` attribute's value + with a size matching the size of the ``DW_AT_const_value`` attribute's + value. RL comprises one implicit location description SRL. SRL specifies + RLS with a bit offset of 0. + + .. note:: + + If using ``DW_AT_const_value`` for variables and formal parameters is + deprecated and instead ``DW_AT_location`` is used with an implicit + location description, then this rule would not be required. + + * Otherwise the DWARF expression is ill-formed. + + The bit offset of RL is updated as if the ``DW_OP_LLVM_offset_uconst B`` + operation was applied. + + If a ``DW_OP_stack_value`` operation pops a value that is the same as IPV, + then it pushes a location description that is the same as L. + + The DWARF expression is ill-formed if it accesses LS or IPV in any other + manner. + + *The restrictions on how an implicit pointer location description created + by* ``DW_OP_implicit_pointer`` *and* ``DW_OP_LLVM_aspace_implicit_pointer`` + *can be used are to simplify the DWARF consumer. Similarly, for an implicit + pointer value created by* ``DW_OP_deref*`` *and* ``DW_OP_stack_value``\ .* + +4. ``DW_OP_LLVM_aspace_implicit_pointer`` *New* + + ``DW_OP_LLVM_aspace_implicit_pointer`` has two operands that are the same as + for ``DW_OP_implicit_pointer``. + + It pops one stack entry that must be an integral type value that represents + a target architecture specific address space identifier AS. + + The location description L that is pushed on the stack is the same as for + ``DW_OP_implicit_pointer`` except that the address space identifier used is + AS. + + The DWARF expression is ill-formed if AS is not one of the values defined by + the target architecture specific ``DW_ASPACE_*`` values. + +*Typically a* ``DW_OP_implicit_pointer`` *or* +``DW_OP_LLVM_aspace_implicit_pointer`` *operation is used in a DWARF expression +E*\ :sub:`1` *of a* ``DW_TAG_variable`` *or* ``DW_TAG_formal_parameter`` +*debugging information entry D*\ :sub:`1`\ *'s* ``DW_AT_location`` *attribute. +The debugging information entry referenced by the* ``DW_OP_implicit_pointer`` +*or* ``DW_OP_LLVM_aspace_implicit_pointer`` *operations is typically itself a* +``DW_TAG_variable`` *or* ``DW_TAG_formal_parameter`` *debugging information +entry D*\ :sub:`2` *whose* ``DW_AT_location`` *attribute gives a second DWARF +expression E*\ :sub:`2`\ *.* + +*D*\ :sub:`1` *and E*\ :sub:`1` *are describing the location of a pointer type +object. D*\ :sub:`2` *and E*\ :sub:`2` *are describing the location of the +object pointed to by that pointer object.* + +*However, D*\ :sub:`2` *may be any debugging information entry that contains a* +``DW_AT_location`` *or* ``DW_AT_const_value`` *attribute (for example,* +``DW_TAG_dwarf_procedure``\ *). By using E*\ :sub:`2`\ *, a consumer can +reconstruct the value of the object when asked to dereference the pointer +described by E*\ :sub:`1` *which contains the* ``DW_OP_implicit_pointer`` or +``DW_OP_LLVM_aspace_implicit_pointer`` *operation.* + +.. _amdgpu-dwarf-composite-location-description-operations: + +Composite Location Description Operations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A composite location storage represents an object or value which may be +contained in part of another location storage or contained in parts of more +than one location storage. + +Each part has a part location description L and a part bit size S. L can have +one or more single location descriptions SL. If there are more than one SL then +that indicates that part is located in more than one place. The bits of each +place of the part comprise S contiguous bits from the location storage LS +specified by SL starting at the bit offset specified by SL. All the bits must +be within the size of LS or the DWARF expression is ill-formed. + +A composite location storage can have zero or more parts. The parts are +contiguous such that the zero-based location storage bit index will range over +each part with no gaps between them. Therefore, the size of a composite location +storage is the sum of the size of its parts. The DWARF expression is ill-formed +if the size of the contiguous location storage is larger than the size of the +memory location storage corresponding to the largest target architecture +specific address space. + +A composite location description specifies a composite location storage. The bit +offset corresponds to a bit position within the composite location storage. + +There are operations that create a composite location storage. + +There are other operations that allow a composite location storage to be +incrementally created. Each part is created by a separate operation. There may +be one or more operations to create the final composite location storage. A +series of such operations describes the parts of the composite location storage +that are in the order that the associated part operations are executed. + +To support incremental creation, a composite location storage can be in an +incomplete state. When an incremental operation operates on an incomplete +composite location storage, it adds a new part, otherwise it creates a new +composite location storage. The ``DW_OP_LLVM_piece_end`` operation explicitly +makes an incomplete composite location storage complete. + +A composite location description that specifies a composite location storage +that is incomplete is termed an incomplete composite location description. A +composite location description that specifies a composite location storage that +is complete is termed a complete composite location description. + +If the top stack entry is a location description that has one incomplete +composite location description SL after the execution of an operation expression +has completed, SL is converted to a complete composite location description. + +*Note that this conversion does not happen after the completion of an operation +expression that is evaluated on the same stack by the* ``DW_OP_call*`` +*operations. Such executions are not a separate evaluation of an operation +expression, but rather the continued evaluation of the same operation expression +that contains the* ``DW_OP_call*`` *operation.* + +If a stack entry is required to be a location description L, but L has an +incomplete composite location description, then the DWARF expression is +ill-formed. The exception is for the operations involved in incrementally +creating a composite location description as described below. + +*Note that a DWARF operation expression may arbitrarily compose composite +location descriptions from any other location description, including those that +have multiple single location descriptions, and those that have composite +location descriptions.* + +*The incremental composite location description operations are defined to be +compatible with the definitions in DWARF Version 5.* + +1. ``DW_OP_piece`` + + ``DW_OP_piece`` has a single unsigned LEB128 integer that represents a byte + size S. + + The action is based on the context: + + * If the stack is empty, then a location description L comprised of one + incomplete composite location description SL is pushed on the stack. + + An incomplete composite location storage LS is created with a single part + P. P specifies a location description PL and has a bit size of S scaled by + 8 (the byte size). PL is comprised of one undefined location description + PSL. + + SL specifies LS with a bit offset of 0. + + * Otherwise, if the top stack entry is a location description L comprised of + one incomplete composite location description SL, then the incomplete + composite location storage LS that SL specifies is updated to append a new + part P. P specifies a location description PL and has a bit size of S + scaled by 8 (the byte size). PL is comprised of one undefined location + description PSL. L is left on the stack. + + * Otherwise, if the top stack entry is a location description or can be + converted to one, then it is popped and treated as a part location + description PL. Then: + + * If the top stack entry (after popping PL) is a location description L + comprised of one incomplete composite location description SL, then the + incomplete composite location storage LS that SL specifies is updated to + append a new part P. P specifies the location description PL and has a + bit size of S scaled by 8 (the byte size). L is left on the stack. + + * Otherwise, a location description L comprised of one incomplete + composite location description SL is pushed on the stack. + + An incomplete composite location storage LS is created with a single + part P. P specifies the location description PL and has a bit size of S + scaled by 8 (the byte size). + + SL specifies LS with a bit offset of 0. + + * Otherwise, the DWARF expression is ill-formed + + *Many compilers store a single variable in sets of registers or store a + variable partially in memory and partially in registers.* ``DW_OP_piece`` + *provides a way of describing where a part of a variable is located.* + + *If a non-0 byte displacement is required, the* ``DW_OP_LLVM_offset`` + *operation can be used to update the location description before using it as + the part location description of a* ``DW_OP_piece`` *operation.* + + *The evaluation rules for the* ``DW_OP_piece`` *operation allow it to be + compatible with the DWARF Version 5 definition.* + + .. note:: + + Since this proposal allows location descriptions to be entries on the + stack, a simpler operation to create composite location descriptions. For + example, just one operation that specifies how many parts, and pops pairs + of stack entries for the part size and location description. Not only + would this be a simpler operation and avoid the complexities of incomplete + composite location descriptions, but it may also have a smaller encoding + in practice. However, the desire for compatibility with DWARF Version 5 is + likely a stronger consideration. + +2. ``DW_OP_bit_piece`` + + ``DW_OP_bit_piece`` has two operands. The first is an unsigned LEB128 + integer that represents the part bit size S. The second is an unsigned + LEB128 integer that represents a bit displacement B. + + The action is the same as for ``DW_OP_piece`` except that any part created + has the bit size S, and the location description PL of any created part is + updated as if the ``DW_OP_constu B; DW_OP_LLVM_bit_offset`` operations were + applied. + + ``DW_OP_bit_piece`` *is used instead of* ``DW_OP_piece`` *when the piece to + be assembled is not byte-sized or is not at the start of the part location + description.* + + *If a computed bit displacement is required, the* ``DW_OP_LLVM_bit_offset`` + *operation can be used to update the location description before using it as + the part location description of a* ``DW_OP_bit_piece`` *operation.* + + .. note:: + + The bit offset operand is not needed as ``DW_OP_LLVM_bit_offset`` can be + used on the part's location description. + +3. ``DW_OP_LLVM_piece_end`` *New* + + If the top stack entry is not a location description L comprised of one + incomplete composite location description SL, then the DWARF expression is + ill-formed. + + Otherwise, the incomplete composite location storage LS specified by SL is + updated to be a complete composite location description with the same parts. + +4. ``DW_OP_LLVM_extend`` *New* + + ``DW_OP_LLVM_extend`` has two operands. The first is an unsigned LEB128 + integer that represents the element bit size S. The second is an unsigned + LEB128 integer that represents a count C. + + It pops one stack entry that must be a location description and is treated + as the part location description PL. + + A location description L comprised of one complete composite location + description SL is pushed on the stack. + + A complete composite location storage LS is created with C identical parts + P. Each P specifies PL and has a bit size of S. + + SL specifies LS with a bit offset of 0. + + The DWARF expression is ill-formed if the element bit size or count are 0. + +5. ``DW_OP_LLVM_select_bit_piece`` *New* + + ``DW_OP_LLVM_select_bit_piece`` has two operands. The first is an unsigned + LEB128 integer that represents the element bit size S. The second is an + unsigned LEB128 integer that represents a count C. + + It pops three stack entries. The first must be an integral type value that + represents a bit mask value M. The second must be a location description + that represents the one-location description L1. The third must be a + location description that represents the zero-location description L0. + + A complete composite location storage LS is created with C parts P\ :sub:`N` + ordered in ascending N from 0 to C-1 inclusive. Each P\ :sub:`N` specifies + location description PL\ :sub:`N` and has a bit size of S. + + PL\ :sub:`N` is as if the ``DW_OP_LLVM_bit_offset N*S`` operation was + applied to PLX\ :sub:`N`\ . + + PLX\ :sub:`N` is the same as L0 if the N\ :sup:`th` least significant bit of + M is a zero, otherwise it is the same as L1. + + A location description L comprised of one complete composite location + description SL is pushed on the stack. SL specifies LS with a bit offset of + 0. + + The DWARF expression is ill-formed if S or C are 0, or if the bit size of M + is less than C. + +.. _amdgpu-dwarf-location-list-expressions: + +DWARF Location List Expressions ++++++++++++++++++++++++++++++++ + +*To meet the needs of recent computer architectures and optimization techniques, +debugging information must be able to describe the location of an object whose +location changes over the object’s lifetime, and may reside at multiple +locations during parts of an object's lifetime. Location list expressions are +used in place of operation expressions whenever the object whose location is +being described has these requirements.* + +A location list expression consists of a series of location list entries. Each +location list entry is one of the following kinds: + +*Bounded location description* + + This kind of location list entry provides an operation expression that + evaluates to the location description of an object that is valid over a + lifetime bounded by a starting and ending address. The starting address is the + lowest address of the address range over which the location is valid. The + ending address is the address of the first location past the highest address + of the address range. + + The location list entry matches when the current program location is within + the given range. + + There are several kinds of bounded location description entries which differ + in the way that they specify the starting and ending addresses. + +*Default location description* + + This kind of location list entry provides an operation expression that + evaluates to the location description of an object that is valid when no + bounded location description entry applies. + + The location list entry matches when the current program location is not + within the range of any bounded location description entry. + +*Base address* + + This kind of location list entry provides an address to be used as the base + address for beginning and ending address offsets given in certain kinds of + bounded location description entries. The applicable base address of a bounded + location description entry is the address specified by the closest preceding + base address entry in the same location list. If there is no preceding base + address entry, then the applicable base address defaults to the base address + of the compilation unit (see DWARF Version 5 section 3.1.1). + + In the case of a compilation unit where all of the machine code is contained + in a single contiguous section, no base address entry is needed. + +*End-of-list* + + This kind of location list entry marks the end of the location list + expression. + +The address ranges defined by the bounded location description entries of a +location list expression may overlap. When they do, they describe a situation in +which an object exists simultaneously in more than one place. + +If all of the address ranges in a given location list expression do not +collectively cover the entire range over which the object in question is +defined, and there is no following default location description entry, it is +assumed that the object is not available for the portion of the range that is +not covered. + +The operation expression of each matching location list entry is evaluated as a +location description and its result is returned as the result of the location +list entry. The operation expression is evaluated with the same context as the +location list expression, including the same current frame, current program +location, and initial stack. + +The result of the evaluation of a DWARF location list expression is a location +description that is comprised of the union of the single location descriptions +of the location description result of each matching location list entry. If +there are no matching location list entries, then the result is a location +description that comprises one undefined location description. + +A location list expression can only be used as the value of a debugger +information entry attribute that is encoded using class ``loclist`` or +``loclistsptr`` (see DWARF Version 5 section 7.5.5). The value of the attribute +provides an index into a separate object file section called ``.debug_loclists`` +or ``.debug_loclists.dwo`` (for split DWARF object files) that contains the +location list entries. + +A ``DW_OP_call*`` and ``DW_OP_implicit_pointer`` operation can be used to +specify a debugger information entry attribute that has a location list +expression. Several debugger information entry attributes allow DWARF +expressions that are evaluated with an initial stack that includes a location +description that may originate from the evaluation of a location list +expression. + +*This location list representation, the* ``loclist`` *and* ``loclistsptr`` +*class, and the related* ``DW_AT_loclists_base`` *attribute are new in DWARF +Version 5. Together they eliminate most, or all of the code object relocations +previously needed for location list expressions.* + +.. note:: + + The rest of this section is the same as DWARF Version 5 section 2.6.2. + +.. _amdgpu-dwarf-segment_addresses: + +Segmented Addresses +~~~~~~~~~~~~~~~~~~~ + +.. note:: + + This augments DWARF Version 5 section 2.12. + +DWARF address classes are used for source languages that have the concept of +memory spaces. They are used in the ``DW_AT_address_class`` attribute for +pointer type, reference type, subprogram, and subprogram type debugger +information entries. + +Each DWARF address class is conceptually a separate source language memory space +with its own lifetime and aliasing rules. DWARF address classes are used to +specify the source language memory spaces that pointer type and reference type +values refer, and to specify the source language memory space in which variables +are allocated. + +The set of currently defined source language DWARF address classes, together +with source language mappings, is given in +:ref:`amdgpu-dwarf-address-class-table`. + +Vendor defined source language address classes may be defined using codes in the +range ``DW_ADDR_LLVM_lo_user`` to ``DW_ADDR_LLVM_hi_user``. + +.. table:: Address class + :name: amdgpu-dwarf-address-class-table + + ========================= ============ ========= ========= ========= + Address Class Name Meaning C/C++ OpenCL CUDA/HIP + ========================= ============ ========= ========= ========= + ``DW_ADDR_none`` generic *default* generic *default* + ``DW_ADDR_LLVM_global`` global global + ``DW_ADDR_LLVM_constant`` constant constant constant + ``DW_ADDR_LLVM_group`` thread-group local shared + ``DW_ADDR_LLVM_private`` thread private + ``DW_ADDR_LLVM_lo_user`` + ``DW_ADDR_LLVM_hi_user`` + ========================= ============ ========= ========= ========= + +DWARF address spaces correspond to target architecture specific linear +addressable memory areas. They are used in DWARF expression location +descriptions to describe in which target architecture specific memory area data +resides. + +*Target architecture specific DWARF address spaces may correspond to hardware +supported facilities such as memory utilizing base address registers, scratchpad +memory, and memory with special interleaving. The size of addresses in these +address spaces may vary. Their access and allocation may be hardware managed +with each thread or group of threads having access to independent storage. For +these reasons they may have properties that do not allow them to be viewed as +part of the unified global virtual address space accessible by all threads.* + +*It is target architecture specific whether multiple DWARF address spaces are +supported and how source language DWARF address classes map to target +architecture specific DWARF address spaces. A target architecture may map +multiple source language DWARF address classes to the same target architecture +specific DWARF address class. Optimization may determine that variable lifetime +and access pattern allows them to be allocated in faster scratchpad memory +represented by a different DWARF address space.* + +Although DWARF address space identifiers are target architecture specific, +``DW_ASPACE_none`` is a common address space supported by all target +architectures. + +DWARF address space identifiers are used by: + +* The DWARF expession operations: ``DW_OP_LLVM_aspace_bregx``, + ``DW_OP_LLVM_form_aspace_address``, ``DW_OP_LLVM_implicit_aspace_pointer``, + and ``DW_OP_xderef*``. + +* The CFI instructions: ``DW_CFA_def_aspace_cfa`` and + ``DW_CFA_def_aspace_cfa_sf``. + +.. note:: + + With the definition of DWARF address classes and DWARF address spaces in this + proposal, DWARF Version 5 table 2.7 needs to be updated. It seems it is an + example of DWARF address spaces and not DWARF address classes. + +.. note:: + + With the expanded support for DWARF address spaces in this proposal, it may be + worth examining if DWARF segments can be eliminated and DWARF address spaces + used instead. + + That may involve extending DWARF address spaces to also be used to specify + code locations. In target architectures that use different memory areas for + code and data this would seem a natural use for DWARF address spaces. This + would allow DWARF expression location descriptions to be used to describe the + location of subprograms and entry points that are used in expressions + involving subprogram pointer type values. + + Currently, DWARF expressions assume data and code resides in the same default + DWARF address space, and only the address ranges in DWARF location list + entries and in the ``.debug_aranges`` section for accelerated access for + addresses allow DWARF segments to be used to distinguish. + +.. note:: + + Currently, DWARF defines address class values as being target architecture + specific. It is unclear how language specific memory spaces are intended to be + represented in DWARF using these. + + For example, OpenCL defines memory spaces (called address spaces in OpenCL) + for ``global``, ``local``, ``constant``, and ``private``. These are part of + the type system and are modifiers to pointer types. In addition, OpenCL + defines ``generic`` pointers that can reference either the ``global``, + ``local``, or ``private`` memory spaces. To support the OpenCL language the + debugger would want to support casting pointers between the ``generic`` and + other memory spaces, querying what memory space a ``generic`` pointer value is + currently referencing, and possibly using pointer casting to form an address + for a specific memory space out of an integral value. + + The method to use to dereference a pointer type or reference type value is + defined in DWARF expressions using ``DW_OP_xderef*`` which uses a target + architecture specific address space. + + DWARF defines the ``DW_AT_address_class`` attribute on pointer type and + reference type debugger information entries. It specifies the method to use to + dereference them. Why is the value of this not the same as the address space + value used in ``DW_OP_xderef*``? In both cases it is target architecture + specific and the architecture presumably will use the same set of methods to + dereference pointers in both cases. + + Since ``DW_AT_address_class`` uses a target architecture specific value, it + cannot in general capture the source language memory space type modifier + concept. On some architectures all source language memory space modifiers may + actually use the same method for dereferencing pointers. + + One possibility is for DWARF to add an ``DW_TAG_LLVM_address_class_type`` + debugger information entry type modifier that can be applied to a pointer type + and reference type. The ``DW_AT_address_class`` attribute could be re-defined + to not be target architecture specific and instead define generalized language + values (as is proposed above for DWARF address classes in the table + :ref:`amdgpu-dwarf-address-class-table`) that will support OpenCL and other + languages using memory spaces. The ``DW_AT_address_class`` attribute could be + defined to not be applied to pointer types or reference types, but instead + only to the new ``DW_TAG_LLVM_address_class_type`` type modifier debugger + information entry. + + If a pointer type or reference type is not modified by + ``DW_TAG_LLVM_address_class_type`` or if ``DW_TAG_LLVM_address_class_type`` + has no ``DW_AT_address_class`` attribute, then the pointer type or reference + type would be defined to use the ``DW_ADDR_none`` address class as currently. + Since modifiers can be chained, it would need to be defined if multiple + ``DW_TAG_LLVM_address_class_type`` modifiers were legal, and if so if the + outermost one is the one that takes precedence. + + A target architecture implementation that supports multiple address spaces + would need to map ``DW_ADDR_none`` appropriately to support CUDA-like + languages that have no address classes in the type system but do support + variable allocation in address classes. Such variable allocation would result + in the variable's location description needing an address space. + + The approach proposed in :ref:`amdgpu-dwarf-address-class-table` is to define + the default ``DW_ADDR_none`` to be the generic address class and not the + global address class. This matches how CLANG and LLVM have added support for + CUDA-like languages on top of existing C++ language support. This allows all + addresses to be generic by default which matches CUDA-like languages. + + An alternative approach is to define ``DW_ADDR_none`` as being the global + address class and then change ``DW_ADDR_LLVM_global`` to + ``DW_ADDR_LLVM_generic``. This would match the reality that languages that do + not support multiple memory spaces only have one default global memory space. + Generally, in these languages if they expose that the target architecture + supports multiple address spaces, the default one is still the global memory + space. Then a language that does support multiple memory spaces has to + explicitly indicate which pointers have the added ability to reference more + than the global memory space. However, compilers generating DWARF for + CUDA-like languages would then have to define every CUDA-like language pointer + type or reference type using ``DW_TAG_LLVM_address_class_type`` with a + ``DW_AT_address_class`` attribute of ``DW_ADDR_LLVM_generic`` to match the + language semantics. + + A new ``DW_AT_LLVM_address_space`` attribute could be defined that can be + applied to pointer type, reference type, subprogram, and subprogram type to + describe how objects having the given type are dereferenced or called (the + role that ``DW_AT_address_class`` currently provides). The values of + ``DW_AT_address_space`` would be target architecture specific and the same as + used in ``DW_OP_xderef*``. + +.. _amdgpu-dwarf-debugging-information-entry-attributes: + +Debugging Information Entry Attributes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + This section provides changes to existing debugger information entry + attributes and defines attributes added by the proposal. These would be + incorporated into the appropriate DWARF Version 5 chapter 2 sections. + +1. ``DW_AT_location`` + + Any debugging information entry describing a data object (which includes + variables and parameters) or common blocks may have a ``DW_AT_location`` + attribute, whose value is a DWARF expression E. + + The result of the attribute is obtained by evaluating E as a location + description in the context of the current subprogram, current program + location, and with an empty initial stack. See + :ref:`amdgpu-dwarf-expressions`. + + See :ref:`amdgpu-dwarf-control-flow-operations` for special evaluation rules + used by the ``DW_OP_call*`` operations. + + .. note:: + + Delete the description of how the ``DW_OP_call*`` operations evaluate a + ``DW_AT_location`` attribute as that is now described in the operations. + + .. note:: + + See the discussion about the ``DW_AT_location`` attribute in the + ``DW_OP_call*`` operation. Having each attribute only have a single + purpose and single execution semantics seems desirable. It makes it easier + for the consumer that no longer have to track the context. It makes it + easier for the producer as it can rely on a single semantics for each + attribute. + + For that reason, limiting the ``DW_AT_location`` attribute to only + supporting evaluating the location description of an object, and using a + different attribute and encoding class for the evaluation of DWARF + expression *procedures* on the same operation expression stack seems + desirable. + +2. ``DW_AT_const_value`` + + .. note:: + + Could deprecate using the ``DW_AT_const_value`` attribute for + ``DW_TAG_variable`` or ``DW_TAG_formal_parameter`` debugger information + entries that have been optimized to a constant. Instead, + ``DW_AT_location`` could be used with a DWARF expression that produces an + implicit location description now that any location description can be + used within a DWARF expression. This allows the ``DW_OP_call*`` operations + to be used to push the location description of any variable regardless of + how it is optimized. + +3. ``DW_AT_frame_base`` + + A ``DW_TAG_subprogram`` or ``DW_TAG_entry_point`` debugger information entry + may have a ``DW_AT_frame_base`` attribute, whose value is a DWARF expression + E. + + The result of the attribute is obtained by evaluating E as a location + description in the context of the current subprogram, current program + location, and with an empty initial stack. + + The DWARF is ill-formed if E contains an ``DW_OP_fbreg`` operation, or the + resulting location description L is not comprised of one single location + description SL. + + If SL a register location description for register R, then L is replaced + with the result of evaluating a ``DW_OP_bregx R, 0`` operation. This + computes the frame base memory location description in the target + architecture default address space. + + *This allows the more compact* ``DW_OPreg*`` *to be used instead of* + ``DW_OP_breg* 0``\ *.* + + .. note:: + + This rule could be removed and require the producer to create the required + location description directly using ``DW_OP_call_frame_cfa``, + ``DW_OP_breg*``, or ``DW_OP_LLVM_aspace_bregx``. This would also then + allow a target to implement the call frames within a large register. + + Otherwise, the DWARF is ill-formed if SL is not a memory location + description in any of the target architecture specific address spaces. + + The resulting L is the *frame base* for the subprogram or entry point. + + *Typically, E will use the* ``DW_OP_call_frame_cfa`` *operation or be a + stack pointer register plus or minus some offset.* + +4. ``DW_AT_data_member_location`` + + For a ``DW_AT_data_member_location`` attribute there are two cases: + + 1. If the attribute is an integer constant B, it provides the offset in + bytes from the beginning of the containing entity. + + The result of the attribute is obtained by evaluating a + ``DW_OP_LLVM_offset B`` operation with an initial stack comprising the + location description of the beginning of the containing entity. The + result of the evaluation is the location description of the base of the + member entry. + + *If the beginning of the containing entity is not byte aligned, then the + beginning of the member entry has the same bit displacement within a + byte.* + + 2. Otherwise, the attribute must be a DWARF expression E which is evaluated + with a context of the current frame, current program location, and an + initial stack comprising the location description of the beginning of + the containing entity. The result of the evaluation is the location + description of the base of the member entry. + + .. note:: + + The beginning of the containing entity can now be any location + description, including those with more than one single location + description, and those with single location descriptions that are of any + kind and have any bit offset. + +5. ``DW_AT_use_location`` + + The ``DW_TAG_ptr_to_member_type`` debugging information entry has a + ``DW_AT_use_location`` attribute whose value is a DWARF expression E. It is + used to compute the location description of the member of the class to which + the pointer to member entry points. + + *The method used to find the location description of a given member of a + class, structure, or union is common to any instance of that class, + structure, or union and to any instance of the pointer to member type. The + method is thus associated with the pointer to member type, rather than with + each object that has a pointer to member type.* + + The ``DW_AT_use_location`` DWARF expression is used in conjunction with the + location description for a particular object of the given pointer to member + type and for a particular structure or class instance. + + The result of the attribute is obtained by evaluating E as a location + description with the context of the current subprogram, current program + location, and an initial stack comprising two entries. The first entry is + the value of the pointer to member object itself. The second entry is the + location description of the base of the entire class, structure, or union + instance containing the member whose location is being calculated. + +6. ``DW_AT_data_location`` + + The ``DW_AT_data_location`` attribute may be used with any type that + provides one or more levels of hidden indirection and/or run-time parameters + in its representation. Its value is a DWARF operation expression E which + computes the location description of the data for an object. When this + attribute is omitted, the location description of the data is the same as + the location description of the object. + + The result of the attribute is obtained by evaluating E as a location + description with the context of the current subprogram, current program + location, and an empty initial stack. + + *E will typically involve an operation expression that begins with a* + ``DW_OP_push_object_address`` *operation which loads the location + description of the object which can then serve as a description in + subsequent calculation.* + + .. note:: + + Since ``DW_AT_data_member_location``, ``DW_AT_use_location``, and + ``DW_AT_vtable_elem_location`` allow both operation expressions and + location list expressions, why does ``DW_AT_data_location`` not allow + both? In all cases they apply to data objects so less likely that + optimization would cause different operation expressions for different + program location ranges. But if supporting for some then should be for + all. + + It seems odd this attribute is not the same as + ``DW_AT_data_member_location`` in having an initial stack with the + location description of the object since the expression has to need it. + +7. ``DW_AT_vtable_elem_location`` + + An entry for a virtual function also has a ``DW_AT_vtable_elem_location`` + attribute whose value is a DWARF expression E. + + The result of the attribute is obtained by evaluating E as a location + description with the context of the current subprogram, current program + location, and an initial stack comprising the location description of the + object of the enclosing type. + + The resulting location description is the slot for the function within the + virtual function table for the enclosing class. + +8. ``DW_AT_static_link`` + + If a ``DW_TAG_subprogram`` or ``DW_TAG_entry_point`` debugger information + entry is lexically nested, it may have a ``DW_AT_static_link`` attribute, + whose value is a DWARF expression E. + + The result of the attribute is obtained by evaluating E as a location + description with the context of the current subprogram, current program + location, and an empty initial stack. + + The DWARF is ill-formed if the resulting location description L is is not + comprised of one memory location description in any of the target + architecture specific address spaces. + + The resulting L is the *frame base* of the relevant instance of the + subprogram that immediately lexically encloses the subprogram or entry + point. + +9. ``DW_AT_return_addr`` + + A ``DW_TAG_subprogram``, ``DW_TAG_inlined_subroutine``, or + ``DW_TAG_entry_point`` debugger information entry may have a + ``DW_AT_return_addr`` attribute, whose value is a DWARF expression E. + + The result of the attribute is obtained by evaluating E as a location + description with the context of the current subprogram, current program + location, and an empty initial stack. + + The DWARF is ill-formed if the resulting location description L is not + comprised one memory location description in any of the target architecture + specific address spaces. + + The resulting L is the place where the return address for the subprogram or + entry point is stored. + + .. note:: + + It is unclear why ``DW_TAG_inlined_subroutine`` has a + ``DW_AT_return_addr`` attribute but not a ``DW_AT_frame_base`` or + ``DW_AT_static_link`` attribute. Seems it would either have all of them or + none. Since inlined subprograms do not have a frame it seems they would + have none of these attributes. + +10. ``DW_AT_call_value``, ``DW_AT_call_data_location``, and ``DW_AT_call_data_value`` + + A ``DW_TAG_call_site_parameter`` debugger information entry may have a + ``DW_AT_call_value`` attribute, whose value is a DWARF operation expression + E\ :sub:`1`\ . + + The result of the ``DW_AT_call_value`` attribute is obtained by evaluating + E\ :sub:`1` as a value with the context of the call site subprogram, call + site program location, and an empty initial stack. + + The call site subprogram is the subprogram containing the + ``DW_TAG_call_site_parameter`` debugger information entry. The call site + program location is the location of call site in the call site subprogram. + + *The consumer may have to virtually unwind to the call site in order to + evaluate the attribute. This will provide both the call site subprogram and + call site program location needed to evaluate the expression.* + + The resulting value V\ :sub:`1` is the value of the parameter at the time of + the call made by the call site. + + For parameters passed by reference, where the code passes a pointer to a + location which contains the parameter, or for reference type parameters, the + ``DW_TAG_call_site_parameter`` debugger information entry may also have a + ``DW_AT_call_data_location`` attribute whose value is a DWARF operation + expression E\ :sub:`2`\ , and a ``DW_AT_call_data_value`` attribute whose + value is a DWARF operation expression E\ :sub:`3`\ . + + The value of the ``DW_AT_call_data_location`` attribute is obtained by + evaluating E\ :sub:`2` as a location description with the context of the + call site subprogram, call site program location, and an empty initial + stack. + + The resulting location description L\ :sub:`2` is the location where the + referenced parameter lives during the call made by the call site. If E\ + :sub:`2` would just be a ``DW_OP_push_object_address``, then the + ``DW_AT_call_data_location`` attribute may be omitted. + + The value of the ``DW_AT_call_data_value`` attribute is obtained by + evaluating E\ :sub:`3` as a value with the context of the call site + subprogram, call site program location, and an empty initial stack. + + The resulting value V\ :sub:`3` is the value in L\ :sub:`2` at the time of + the call made by the call site. + + If it is not possible to avoid the expressions of these attributes from + accessing registers or memory locations that might be clobbered by the + subprogram being called by the call site, then the associated attribute + should not be provided. + + *The reason for the restriction is that the parameter may need to be + accessed during the execution of the callee. The consumer may virtually + unwind from the called subprogram back to the caller and then evaluate the + attribute expressions. The call frame information (see* + :ref:`amdgpu-dwarf-call-frame-information`\ *) will not be able to restore + registers that have been clobbered, and clobbered memory will no longer have + the value at the time of the call.* + +11. ``DW_AT_LLVM_lanes`` *New* + + For languages that are implemented using a SIMD or SIMT execution model, a + ``DW_TAG_subprogram``, ``DW_TAG_inlined_subroutine``, or + ``DW_TAG_entry_point`` debugger information entry may have a + ``DW_AT_LLVM_lanes`` attribute whose value is an integer constant that is + the number of lanes per thread. This is the static number of lanes per + thread. It is not the dynamic number of lanes with which the thread was + initiated, for example, due to smaller or partial work-groups. + + If not present, the default value of 1 is used. + + The DWARF is ill-formed if the value is 0. + +12. ``DW_AT_LLVM_lane_pc`` *New* + + For languages that are implemented using a SIMD or SIMT execution model, a + ``DW_TAG_subprogram``, ``DW_TAG_inlined_subroutine``, or + ``DW_TAG_entry_point`` debugging information entry may have a + ``DW_AT_LLVM_lane_pc`` attribute whose value is a DWARF expression E. + + The result of the attribute is obtained by evaluating E as a location + description with the context of the current subprogram, current program + location, and an empty initial stack. + + The resulting location description L is for a thread lane count sized vector + of generic type elements. The thread lane count is the value of the + ``DW_AT_LLVM_lanes`` attribute. Each element holds the conceptual program + location of the corresponding lane, where the least significant element + corresponds to the first target architecture specific lane identifier and so + forth. If the lane was not active when the current subprogram was called, + its element is an undefined location description. + + ``DW_AT_LLVM_lane_pc`` *allows the compiler to indicate conceptually where + each lane of a SIMT thread is positioned even when it is in divergent + control flow that is not active.* + + *Typically, the result is a location description with one composite location + description with each part being a location description with either one + undefined location description or one memory location description.* + + If not present, the thread is not being used in a SIMT manner, and the + thread's current program location is used. + +13. ``DW_AT_LLVM_active_lane`` *New* + + For languages that are implemented using a SIMD or SIMT execution model, a + ``DW_TAG_subprogram``, ``DW_TAG_inlined_subroutine``, or + ``DW_TAG_entry_point`` debugger information entry may have a + ``DW_AT_LLVM_active_lane`` attribute whose value is a DWARF expression E. + + The result of the attribute is obtained by evaluating E as a value with the + context of the current subprogram, current program location, and an empty + initial stack. + + The DWARF is ill-formed if the resulting value V is not an integral value. + + The resulting V is a bit mask of active lanes for the current program + location. The N\ :sup:`th` least significant bit of the mask corresponds to + the N\ :sup:`th` lane. If the bit is 1 the lane is active, otherwise it is + inactive. + + *Some targets may update the target architecture execution mask for regions + of code that must execute with different sets of lanes than the current + active lanes. For example, some code must execute with all lanes made + temporarily active.* ``DW_AT_LLVM_active_lane`` *allows the compiler to + provide the means to determine the source language active lanes.* + + If not present and ``DW_AT_LLVM_lanes`` is greater than 1, then the target + architecture execution mask is used. + +14. ``DW_AT_LLVM_vector_size`` *New* + + A ``DW_TAG_base_type`` debugger information entry for a base type T may have + a ``DW_AT_LLVM_vector_size`` attribute whose value is an integer constant + that is the vector type size N. + + The representation of a vector base type is as N contiguous elements, each + one having the representation of a base type T' that is the same as T + without the ``DW_AT_LLVM_vector_size`` attribute. + + If a ``DW_TAG_base_type`` debugger information entry does not have a + ``DW_AT_LLVM_vector_size`` attribute, then the base type is not a vector + type. + + The DWARF is ill-formed if N is not greater than 0. + + .. note:: + + LLVM has mention of a non-upstreamed debugger information entry that is + intended to support vector types. However, that was not for a base type so + would not be suitable as the type of a stack value entry. But perhaps that + could be replaced by using this attribute. + +15. ``DW_AT_LLVM_augmentation`` *New* + + A ``DW_TAG_compile_unit`` debugger information entry for a compilation unit + may have a ``DW_AT_LLVM_augmentation`` attribute, whose value is an + augmentation string. + + *The augmentation string allows producers to indicate that there is + additional vendor or target specific information in the debugging + information entries. For example, this might be information about the + version of vendor specific extensions that are being used.* + + If not present, or if the string is empty, then the compilation unit has no + augmentation string. + + The format for the augmentation string is: + + | ``[``\ *vendor*\ ``:v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ * + + Where *vendor* is the producer, ``vX.Y`` specifies the major X and minor Y + version number of the extensions used, and *options* is an optional string + providing additional information about the extensions. The version number + must conform to semantic versioning [:ref:`SEMVER `]. + The *options* string must not contain the "\ ``]``\ " character. + + For example: + + :: + + [abc:v0.0][def:v1.2:feature-a=on,feature-b=3] + +Program Scope Entities +---------------------- + +.. _amdgpu-dwarf-language-names: + +Unit Entities +~~~~~~~~~~~~~ + +.. note:: + + This augments DWARF Version 5 section 3.1.1 and Table 3.1. + +Additional language codes defined for use with the ``DW_AT_language`` attribute +are defined in :ref:`amdgpu-dwarf-language-names-table`. + +.. table:: Language Names + :name: amdgpu-dwarf-language-names-table + + ==================== ============================= + Language Name Meaning + ==================== ============================= + ``DW_LANG_LLVM_HIP`` HIP Language. + ==================== ============================= + +The HIP language [:ref:`HIP `] can be supported by extending +the C++ language. + +Other Debugger Information +-------------------------- + +Accelerated Access +~~~~~~~~~~~~~~~~~~ + +.. _amdgpu-dwarf-lookup-by-name: + +Lookup By Name +++++++++++++++ + +Contents of the Name Index +########################## + +.. note:: + + The following provides changes to DWARF Version 5 section 6.1.1.1. + + The rule for debugger information entries included in the name index in the + optional ``.debug_names`` section is extended to also include named + ``DW_TAG_variable`` debugging information entries with a ``DW_AT_location`` + attribute that includes a ``DW_OP_LLVM_form_aspace_address`` operation. + +The name index must contain an entry for each debugging information entry that +defines a named subprogram, label, variable, type, or namespace, subject to the +following rules: + +* ``DW_TAG_variable`` debugging information entries with a ``DW_AT_location`` + attribute that includes a ``DW_OP_addr``, ``DW_OP_LLVM_form_aspace_address``, + or ``DW_OP_form_tls_address`` operation are included; otherwise, they are + excluded. + +Data Representation of the Name Index +##################################### + +Section Header +^^^^^^^^^^^^^^ + +.. note:: + + The following provides an addition to DWARF Version 5 section 6.1.1.4.1 item + 14 ``augmentation_string``. + +A null-terminated UTF-8 vendor specific augmentation string, which provides +additional information about the contents of this index. If provided, the +recommended format for augmentation string is: + + | ``[``\ *vendor*\ ``:v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ * + +Where *vendor* is the producer, ``vX.Y`` specifies the major X and minor Y +version number of the extensions used in the DWARF of the compilation unit, and +*options* is an optional string providing additional information about the +extensions. The version number must conform to semantic versioning [:ref:`SEMVER +`]. The *options* string must not contain the "\ ``]``\ " +character. + +For example: + + :: + + [abc:v0.0][def:v1.2:feature-a=on,feature-b=3] + +.. note:: + + This is different to the definition in DWARF Version 5 but is consistent with + the other augmentation strings and allows multiple vendor extensions to be + supported. + +.. _amdgpu-dwarf-line-number-information: + +Line Number Information +~~~~~~~~~~~~~~~~~~~~~~~ + +The Line Number Program Header +++++++++++++++++++++++++++++++ + +Standard Content Descriptions +############################# + +.. note:: + + This augments DWARF Version 5 section 6.2.4.1. + +.. _amdgpu-dwarf-line-number-information-dw-lnct-llvm-source: + +1. ``DW_LNCT_LLVM_source`` + + The component is a null-terminated UTF-8 source text string with "\ ``\n``\ + " line endings. This content code is paired with the same forms as + ``DW_LNCT_path``. It can be used for file name entries. + + The value is an empty null-terminated string if no source is available. If + the source is available but is an empty file then the value is a + null-terminated single "\ ``\n``\ ". + + *When the source field is present, consumers can use the embedded source + instead of attempting to discover the source on disk using the file path + provided by the* ``DW_LNCT_path`` *field. When the source field is absent, + consumers can access the file to get the source text.* + + *This is particularly useful for programing languages that support runtime + compilation and runtime generation of source text. In these cases, the + source text does not reside in any permanent file. For example, the OpenCL + language [:ref:`OpenCL `] supports online compilation.* + +2. ``DW_LNCT_LLVM_is_MD5`` + + ``DW_LNCT_LLVM_is_MD5`` indicates if the ``DW_LNCT_MD5`` content kind, if + present, is valid: when 0 it is not valid and when 1 it is valid. If + ``DW_LNCT_LLVM_is_MD5`` content kind is not present, and ``DW_LNCT_MD5`` + content kind is present, then the MD5 checksum is valid. + + ``DW_LNCT_LLVM_is_MD5`` is always paired with the ``DW_FORM_udata`` form. + + *This allows a compilation unit to have a mixture of files with and without + MD5 checksums. This can happen when multiple relocatable files are linked + together.* + +.. _amdgpu-dwarf-call-frame-information: + +Call Frame Information +~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + This section provides changes to existing Call Frame Information and defines + instructions added by the proposal. Additional support is added for address + spaces. Register unwind DWARF expressions are generalized to allow any + location description, including those with composite and implicit location + descriptions. + + These changes would be incorporated into the DWARF Version 5 section 6.1. + +Structure of Call Frame Information ++++++++++++++++++++++++++++++++++++ + +The register rules are: + +*undefined* + A register that has this rule has no recoverable value in the previous frame. + (By convention, it is not preserved by a callee.) + +*same value* + This register has not been modified from the previous frame. (By convention, + it is preserved by the callee, but the callee has not modified it.) + +*offset(N)* + N is a signed byte offset. The previous value of this register is saved at the + location description computed as if the DWARF operation expression + ``DW_OP_LLVM_offset N`` is evaluated as a location description with an initial + stack comprising the location description of the current CFA (see + :ref:`amdgpu-dwarf-operation-expressions`). + +*val_offset(N)* + N is a signed byte offset. The previous value of this register is the memory + byte address of the location description computed as if the DWARF operation + expression ``DW_OP_LLVM_offset N`` is evaluated as a location description with + an initial stack comprising the location description of the current CFA (see + :ref:`amdgpu-dwarf-operation-expressions`). + + The DWARF is ill-formed if the CFA location description is not a memory byte + address location description, or if the register size does not match the size + of an address in the address space of the current CFA location description. + + *Since the CFA location description is required to be a memory byte address + location description, the value of val_offset(N) will also be a memory byte + address location description since it is offsetting the CFA location + description by N bytes. Furthermore, the value of val_offset(N) will be a + memory byte address in the same address space as the CFA location + description.* + + .. note:: + + Should DWARF allow the address size to be a different size to the size of + the register? Requiring them to be the same bit size avoids any issue of + conversion as the bit contents of the register is simply interpreted as a + value of the address. + + GDB has a per register hook that allows a target specific conversion on a + register by register basis. It defaults to truncation of bigger registers, + and to actually reading bytes from the next register (or reads out of bounds + for the last register) for smaller registers. There are no GDB tests that + read a register out of bounds (except an illegal hand written assembly + test). + +*register(R)* + The previous value of this register is stored in another register numbered R. + + The DWARF is ill-formed if the register sizes do not match. + +*expression(E)* + The previous value of this register is located at the location description + produced by evaluating the DWARF operation expression E (see + :ref:`amdgpu-dwarf-operation-expressions`). + + E is evaluated as a location description in the context of the current + subprogram, current program location, and with an initial stack comprising the + location description of the current CFA. + +*val_expression(E)* + The previous value of this register is the value produced by evaluating the + DWARF operation expression E (see :ref:`amdgpu-dwarf-operation-expressions`). + + E is evaluated as a value in the context of the current subprogram, current + program location, and with an initial stack comprising the location + description of the current CFA. + + The DWARF is ill-formed if the resulting value type size does not match the + register size. + + .. note:: + + This has limited usefulness as the DWARF expression E can only produce + values up to the size of the generic type. This is due to not allowing any + operations that specify a type in a CFI operation expression. This makes it + unusable for registers that are larger than the generic type. However, + *expression(E)* can be used to create an implicit location description of + any size. + +*architectural* + The rule is defined externally to this specification by the augmenter. + +A Common Information Entry holds information that is shared among many Frame +Description Entries. There is at least one CIE in every non-empty +``.debug_frame`` section. A CIE contains the following fields, in order: + +1. ``length`` (initial length) + + A constant that gives the number of bytes of the CIE structure, not + including the length field itself. The size of the length field plus the + value of length must be an integral multiple of the address size specified + in the ``address_size`` field. + +2. ``CIE_id`` (4 or 8 bytes, see + :ref:`amdgpu-dwarf-32-bit-and-64-bit-dwarf-formats`) + + A constant that is used to distinguish CIEs from FDEs. + + In the 32-bit DWARF format, the value of the CIE id in the CIE header is + 0xffffffff; in the 64-bit DWARF format, the value is 0xffffffffffffffff. + +3. ``version`` (ubyte) + + A version number. This number is specific to the call frame information and + is independent of the DWARF version number. + + The value of the CIE version number is 4. + + .. note:: + + Would this be increased to 5 to reflect the changes in the proposal? + +4. ``augmentation`` (sequence of UTF-8 characters) + + A null-terminated UTF-8 string that identifies the augmentation to this CIE + or to the FDEs that use it. If a reader encounters an augmentation string + that is unexpected, then only the following fields can be read: + + * CIE: length, CIE_id, version, augmentation + * FDE: length, CIE_pointer, initial_location, address_range + + If there is no augmentation, this value is a zero byte. + + *The augmentation string allows users to indicate that there is additional + vendor and target architecture specific information in the CIE or FDE which + is needed to virtually unwind a stack frame. For example, this might be + information about dynamically allocated data which needs to be freed on exit + from the routine.* + + *Because the* ``.debug_frame`` *section is useful independently of any* + ``.debug_info`` *section, the augmentation string always uses UTF-8 + encoding.* + + The recommended format for the augmentation string is: + + | ``[``\ *vendor*\ ``:v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ * + + Where *vendor* is the producer, ``vX.Y`` specifies the major X and minor Y + version number of the extensions used, and *options* is an optional string + providing additional information about the extensions. The version number + must conform to semantic versioning [:ref:`SEMVER `]. + The *options* string must not contain the "\ ``]``\ " character. + + For example: + + :: + + [abc:v0.0][def:v1.2:feature-a=on,feature-b=3] + +5. ``address_size`` (ubyte) + + The size of a target address in this CIE and any FDEs that use it, in bytes. + If a compilation unit exists for this frame, its address size must match the + address size here. + +6. ``segment_selector_size`` (ubyte) + + The size of a segment selector in this CIE and any FDEs that use it, in + bytes. + +7. ``code_alignment_factor`` (unsigned LEB128) + + A constant that is factored out of all advance location instructions (see + :ref:`amdgpu-dwarf-row-creation-instructions`). The resulting value is + ``(operand * code_alignment_factor)``. + +8. ``data_alignment_factor`` (signed LEB128) + + A constant that is factored out of certain offset instructions (see + :ref:`amdgpu-dwarf-cfa-definition-instructions` and + :ref:`amdgpu-dwarf-register-rule-instructions`). The resulting value is + ``(operand * data_alignment_factor)``. + +9. ``return_address_register`` (unsigned LEB128) + + An unsigned LEB128 constant that indicates which column in the rule table + represents the return address of the subprogram. Note that this column might + not correspond to an actual machine register. + +10. ``initial_instructions`` (array of ubyte) + + A sequence of rules that are interpreted to create the initial setting of + each column in the table. + + The default rule for all columns before interpretation of the initial + instructions is the undefined rule. However, an ABI authoring body or a + compilation system authoring body may specify an alternate default value for + any or all columns. + +11. ``padding`` (array of ubyte) + + Enough ``DW_CFA_nop`` instructions to make the size of this entry match the + length value above. + +An FDE contains the following fields, in order: + +1. ``length`` (initial length) + + A constant that gives the number of bytes of the header and instruction + stream for this subprogram, not including the length field itself. The size + of the length field plus the value of length must be an integral multiple of + the address size. + +2. ``CIE_pointer`` (4 or 8 bytes, see + :ref:`amdgpu-dwarf-32-bit-and-64-bit-dwarf-formats`) + + A constant offset into the ``.debug_frame`` section that denotes the CIE + that is associated with this FDE. + +3. ``initial_location`` (segment selector and target address) + + The address of the first location associated with this table entry. If the + segment_selector_size field of this FDE’s CIE is non-zero, the initial + location is preceded by a segment selector of the given length. + +4. ``address_range`` (target address) + + The number of bytes of program instructions described by this entry. + +5. ``instructions`` (array of ubyte) + + A sequence of table defining instructions that are described in + :ref:`amdgpu-dwarf-call-frame-instructions`. + +6. ``padding`` (array of ubyte) + + Enough ``DW_CFA_nop`` instructions to make the size of this entry match the + length value above. + +.. _amdgpu-dwarf-call-frame-instructions: + +Call Frame Instructions ++++++++++++++++++++++++ + +Some call frame instructions have operands that are encoded as DWARF operation +expressions E (see :ref:`amdgpu-dwarf-operation-expressions`). The DWARF +operations that can be used in E have the following restrictions: + +* ``DW_OP_addrx``, ``DW_OP_call2``, ``DW_OP_call4``, ``DW_OP_call_ref``, + ``DW_OP_const_type``, ``DW_OP_constx``, ``DW_OP_convert``, + ``DW_OP_deref_type``, ``DW_OP_fbreg``, ``DW_OP_implicit_pointer``, + ``DW_OP_regval_type``, ``DW_OP_reinterpret``, and ``DW_OP_xderef_type`` + operations are not allowed because the call frame information must not depend + on other debug sections. + +* ``DW_OP_push_object_address`` is not allowed because there is no object + context to provide a value to push. + +* ``DW_OP_LLVM_push_lane`` is not allowed because the call frame instructions + describe the actions for the whole thread, not the lanes independently. + +* ``DW_OP_call_frame_cfa`` and ``DW_OP_entry_value`` are not allowed because + their use would be circular. + +* ``DW_OP_LLVM_call_frame_entry_reg`` is not allowed if evaluating E causes a + circular dependency between ``DW_OP_LLVM_call_frame_entry_reg`` operations. + + *For example, if a register R1 has a* ``DW_CFA_def_cfa_expression`` + *instruction that evaluates a* ``DW_OP_LLVM_call_frame_entry_reg`` *operation + that specifies register R2, and register R2 has a* + ``DW_CFA_def_cfa_expression`` *instruction that that evaluates a* + ``DW_OP_LLVM_call_frame_entry_reg`` *operation that specifies register R1.* + +*Call frame instructions to which these restrictions apply include* +``DW_CFA_def_cfa_expression``\ *,* ``DW_CFA_expression``\ *, and* +``DW_CFA_val_expression``\ *.* + +.. _amdgpu-dwarf-row-creation-instructions: + +Row Creation Instructions +######################### + +.. note:: + + These instructions are the same as in DWARF Version 5 section 6.4.2.1. + +.. _amdgpu-dwarf-cfa-definition-instructions: + +CFA Definition Instructions +########################### + +1. ``DW_CFA_def_cfa`` + + The ``DW_CFA_def_cfa`` instruction takes two unsigned LEB128 operands + representing a register number R and a (non-factored) byte displacement B. + AS is set to the target architecture default address space identifier. The + required action is to define the current CFA rule to be the result of + evaluating the DWARF operation expression ``DW_OP_constu AS; + DW_OP_aspace_bregx R, B`` as a location description. + +2. ``DW_CFA_def_cfa_sf`` + + The ``DW_CFA_def_cfa_sf`` instruction takes two operands: an unsigned LEB128 + value representing a register number R and a signed LEB128 factored byte + displacement B. AS is set to the target architecture default address space + identifier. The required action is to define the current CFA rule to be the + result of evaluating the DWARF operation expression ``DW_OP_constu AS; + DW_OP_aspace_bregx R, B*data_alignment_factor`` as a location description. + + *The action is the same as* ``DW_CFA_def_cfa`` *except that the second + operand is signed and factored.* + +3. ``DW_CFA_def_aspace_cfa`` *New* + + The ``DW_CFA_def_aspace_cfa`` instruction takes three unsigned LEB128 + operands representing a register number R, a (non-factored) byte + displacement B, and a target architecture specific address space identifier + AS. The required action is to define the current CFA rule to be the result + of evaluating the DWARF operation expression ``DW_OP_constu AS; + DW_OP_aspace_bregx R, B`` as a location description. + + If AS is not one of the values defined by the target architecture specific + ``DW_ASPACE_*`` values then the DWARF expression is ill-formed. + +4. ``DW_CFA_def_aspace_cfa_sf`` *New* + + The ``DW_CFA_def_cfa_sf`` instruction takes three operands: an unsigned + LEB128 value representing a register number R, a signed LEB128 factored byte + displacement B, and an unsigned LEB128 value representing a target + architecture specific address space identifier AS. The required action is to + define the current CFA rule to be the result of evaluating the DWARF + operation expression ``DW_OP_constu AS; DW_OP_aspace_bregx R, + B*data_alignment_factor`` as a location description. + + If AS is not one of the values defined by the target architecture specific + ``DW_ASPACE_*`` values, then the DWARF expression is ill-formed. + + *The action is the same as* ``DW_CFA_aspace_def_cfa`` *except that the + second operand is signed and factored.* + +5. ``DW_CFA_def_cfa_register`` + + The ``DW_CFA_def_cfa_register`` instruction takes a single unsigned LEB128 + operand representing a register number R. The required action is to define + the current CFA rule to be the result of evaluating the DWARF operation + expression ``DW_OP_constu AS; DW_OP_aspace_bregx R, B`` as a location + description. B and AS are the old CFA byte displacement and address space + respectively. + + If the subprogram has no current CFA rule, or the rule was defined by a + ``DW_CFA_def_cfa_expression`` instruction, then the DWARF is ill-formed. + +6. ``DW_CFA_def_cfa_offset`` + + The ``DW_CFA_def_cfa_offset`` instruction takes a single unsigned LEB128 + operand representing a (non-factored) byte displacement B. The required + action is to define the current CFA rule to be the result of evaluating the + DWARF operation expression ``DW_OP_constu AS; DW_OP_aspace_bregx R, B`` as a + location description. R and AS are the old CFA register number and address + space respectively. + + If the subprogram has no current CFA rule, or the rule was defined by a + ``DW_CFA_def_cfa_expression`` instruction, then the DWARF is ill-formed. + +7. ``DW_CFA_def_cfa_offset_sf`` + + The ``DW_CFA_def_cfa_offset_sf`` instruction takes a signed LEB128 operand + representing a factored byte displacement B. The required action is to + define the current CFA rule to be the result of evaluating the DWARF + operation expression ``DW_OP_constu AS; DW_OP_aspace_bregx R, + B*data_alignment_factor`` as a location description. R and AS are the old + CFA register number and address space respectively. + + If the subprogram has no current CFA rule, or the rule was defined by a + ``DW_CFA_def_cfa_expression`` instruction, then the DWARF is ill-formed. + + *The action is the same as* ``DW_CFA_def_cfa_offset`` *except that the + operand is signed and factored.* + +8. ``DW_CFA_def_cfa_expression`` + + The ``DW_CFA_def_cfa_expression`` instruction takes a single operand encoded + as a ``DW_FORM_exprloc`` value representing a DWARF operation expression E. + The required action is to define the current CFA rule to be the result of + evaluating E as a location description in the context of the current + subprogram, current program location, and an empty initial stack. + + *See* :ref:`amdgpu-dwarf-call-frame-instructions` *regarding restrictions on + the DWARF expression operations that can be used in E.* + + The DWARF is ill-formed if the result of evaluating E is not a memory byte + address location description. + +.. _amdgpu-dwarf-register-rule-instructions: + +Register Rule Instructions +########################## + +1. ``DW_CFA_undefined`` + + The ``DW_CFA_undefined`` instruction takes a single unsigned LEB128 operand + that represents a register number R. The required action is to set the rule + for the register specified by R to ``undefined``. + +2. ``DW_CFA_same_value`` + + The ``DW_CFA_same_value`` instruction takes a single unsigned LEB128 operand + that represents a register number R. The required action is to set the rule + for the register specified by R to ``same value``. + +3. ``DW_CFA_offset`` + + The ``DW_CFA_offset`` instruction takes two operands: a register number R + (encoded with the opcode) and an unsigned LEB128 constant representing a + factored displacement B. The required action is to change the rule for the + register specified by R to be an *offset(B\*data_alignment_factor)* rule. + + .. note:: + + Seems this should be named ``DW_CFA_offset_uf`` since the offset is + unsigned factored. + +4. ``DW_CFA_offset_extended`` + + The ``DW_CFA_offset_extended`` instruction takes two unsigned LEB128 + operands representing a register number R and a factored displacement B. + This instruction is identical to ``DW_CFA_offset`` except for the encoding + and size of the register operand. + + .. note:: + + Seems this should be named ``DW_CFA_offset_extended_uf`` since the + displacement is unsigned factored. + +5. ``DW_CFA_offset_extended_sf`` + + The ``DW_CFA_offset_extended_sf`` instruction takes two operands: an + unsigned LEB128 value representing a register number R and a signed LEB128 + factored displacement B. This instruction is identical to + ``DW_CFA_offset_extended`` except that B is signed. + +6. ``DW_CFA_val_offset`` + + The ``DW_CFA_val_offset`` instruction takes two unsigned LEB128 operands + representing a register number R and a factored displacement B. The required + action is to change the rule for the register indicated by R to be a + *val_offset(B\*data_alignment_factor)* rule. + + .. note:: + + Seems this should be named ``DW_CFA_val_offset_uf`` since the displacement + is unsigned factored. + + .. note:: + + An alternative is to define ``DW_CFA_val_offset`` to implicitly use the + target architecture default address space, and add another operation that + specifies the address space. + +7. ``DW_CFA_val_offset_sf`` + + The ``DW_CFA_val_offset_sf`` instruction takes two operands: an unsigned + LEB128 value representing a register number R and a signed LEB128 factored + displacement B. This instruction is identical to ``DW_CFA_val_offset`` + except that B is signed. + +8. ``DW_CFA_register`` + + The ``DW_CFA_register`` instruction takes two unsigned LEB128 operands + representing register numbers R1 and R2 respectively. The required action is + to set the rule for the register specified by R1 to be a *register(R2)* rule. + +9. ``DW_CFA_expression`` + + The ``DW_CFA_expression`` instruction takes two operands: an unsigned LEB128 + value representing a register number R, and a ``DW_FORM_block`` value + representing a DWARF operation expression E. The required action is to + change the rule for the register specified by R to be an *expression(E)* + rule. + + *That is, E computes the location description where the register value can + be retrieved.* + + *See* :ref:`amdgpu-dwarf-call-frame-instructions` *regarding restrictions on + the DWARF expression operations that can be used in E.* + +10. ``DW_CFA_val_expression`` + + The ``DW_CFA_val_expression`` instruction takes two operands: an unsigned + LEB128 value representing a register number R, and a ``DW_FORM_block`` value + representing a DWARF operation expression E. The required action is to + change the rule for the register specified by R to be a *val_expression(E)* + rule. + + *That is, E computes the value of register R.* + + *See* :ref:`amdgpu-dwarf-call-frame-instructions` *regarding restrictions on + the DWARF expression operations that can be used in E.* + + If the result of evaluating E is not a value with a base type size that + matches the register size, then the DWARF is ill-formed. + +11. ``DW_CFA_restore`` + + The ``DW_CFA_restore`` instruction takes a single operand (encoded with the + opcode) that represents a register number R. The required action is to + change the rule for the register specified by R to the rule assigned it by + the ``initial_instructions`` in the CIE. + +12. ``DW_CFA_restore_extended`` + + The ``DW_CFA_restore_extended`` instruction takes a single unsigned LEB128 + operand that represents a register number R. This instruction is identical + to ``DW_CFA_restore`` except for the encoding and size of the register + operand. + +Row State Instructions +###################### + +.. note:: + + These instructions are the same as in DWARF Version 5 section 6.4.2.4. + +Padding Instruction +################### + +.. note:: + + These instructions are the same as in DWARF Version 5 section 6.4.2.5. + +Call Frame Instruction Usage +++++++++++++++++++++++++++++ + +.. note:: + + The same as in DWARF Version 5 section 6.4.3. + +.. _amdgpu-dwarf-call-frame-calling-address: + +Call Frame Calling Address +++++++++++++++++++++++++++ + +.. note:: + + The same as in DWARF Version 5 section 6.4.4. + +Data Representation +------------------- + +.. _amdgpu-dwarf-32-bit-and-64-bit-dwarf-formats: + +32-Bit and 64-Bit DWARF Formats +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + This augments DWARF Version 5 section 7.4. + +1. Within the body of the ``.debug_info`` section, certain forms of attribute + value depend on the choice of DWARF format as follows. For the 32-bit DWARF + format, the value is a 4-byte unsigned integer; for the 64-bit DWARF format, + the value is an 8-byte unsigned integer. + + .. table:: ``.debug_info`` section attribute form roles + :name: amdgpu-dwarf-debug-info-section-attribute-form-roles-table + + ================================== =================================== + Form Role + ================================== =================================== + DW_FORM_line_strp offset in ``.debug_line_str`` + DW_FORM_ref_addr offset in ``.debug_info`` + DW_FORM_sec_offset offset in a section other than + ``.debug_info`` or ``.debug_str`` + DW_FORM_strp offset in ``.debug_str`` + DW_FORM_strp_sup offset in ``.debug_str`` section of + supplementary object file + DW_OP_call_ref offset in ``.debug_info`` + DW_OP_implicit_pointer offset in ``.debug_info`` + DW_OP_LLVM_aspace_implicit_pointer offset in ``.debug_info`` + ================================== =================================== + +Format of Debugging Information +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Attribute Encodings ++++++++++++++++++++ + +.. note:: + + This augments DWARF Version 5 section 7.5.4 and Table 7.5. + +The following table gives the encoding of the additional debugging information +entry attributes. + +.. table:: Attribute encodings + :name: amdgpu-dwarf-attribute-encodings-table + + ================================== ====== =================================== + Attribute Name Value Classes + ================================== ====== =================================== + DW_AT_LLVM_active_lane 0x3e08 exprloc, loclist + DW_AT_LLVM_augmentation 0x3e09 string + DW_AT_LLVM_lanes 0x3e0a constant + DW_AT_LLVM_lane_pc 0x3e0b exprloc, loclist + DW_AT_LLVM_vector_size 0x3e0c constant + ================================== ====== =================================== + +DWARF Expressions +~~~~~~~~~~~~~~~~~ + +.. note:: + + Rename DWARF Version 5 section 7.7 to reflect the unification of location + descriptions into DWARF expressions. + +Operation Expressions ++++++++++++++++++++++ + +.. note:: + + Rename DWARF Version 5 section 7.7.1 and delete section 7.7.2 to reflect the + unification of location descriptions into DWARF expressions. + + This augments DWARF Version 5 section 7.7.1 and Table 7.9. + +The following table gives the encoding of the additional DWARF expression +operations. + +.. table:: DWARF Operation Encodings + :name: amdgpu-dwarf-operation-encodings-table + + ================================== ===== ======== =============================== + Operation Code Number Notes + of + Operands + ================================== ===== ======== =============================== + DW_OP_LLVM_form_aspace_address 0xe1 0 + DW_OP_LLVM_push_lane 0xe2 0 + DW_OP_LLVM_offset 0xe3 0 + DW_OP_LLVM_offset_uconst 0xe4 1 ULEB128 byte displacement + DW_OP_LLVM_bit_offset 0xe5 0 + DW_OP_LLVM_call_frame_entry_reg 0xe6 1 ULEB128 register number + DW_OP_LLVM_undefined 0xe7 0 + DW_OP_LLVM_aspace_bregx 0xe8 2 ULEB128 register number, + ULEB128 byte displacement + DW_OP_LLVM_aspace_implicit_pointer 0xe9 2 4- or 8-byte offset of DIE, + SLEB128 byte displacement + DW_OP_LLVM_piece_end 0xea 0 + DW_OP_LLVM_extend 0xeb 2 ULEB128 bit size, + ULEB128 count + DW_OP_LLVM_select_bit_piece 0xec 2 ULEB128 bit size, + ULEB128 count + ================================== ===== ======== =============================== + +Location List Expressions ++++++++++++++++++++++++++ + +.. note:: + + Rename DWARF Version 5 section 7.7.3 to reflect that location lists are a kind + of DWARF expression. + +Source Languages +~~~~~~~~~~~~~~~~ + +.. note:: + + This augments DWARF Version 5 section 7.12 and Table 7.17. + +The following table gives the encoding of the additional DWARF languages. + +.. table:: Language encodings + :name: amdgpu-dwarf-language-encodings-table + + ==================== ====== =================== + Language Name Value Default Lower Bound + ==================== ====== =================== + ``DW_LANG_LLVM_HIP`` 0x8100 0 + ==================== ====== =================== + +Address Class and Address Space Encodings +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + This replaces DWARF Version 5 section 7.13. + +The encodings of the constants used for the currently defined address classes +are given in :ref:`amdgpu-dwarf-address-class-encodings-table`. + +.. table:: Address class encodings + :name: amdgpu-dwarf-address-class-encodings-table + + ========================== ====== + Address Class Name Value + ========================== ====== + ``DW_ADDR_none`` 0x0000 + ``DW_ADDR_LLVM_global`` 0x0001 + ``DW_ADDR_LLVM_constant`` 0x0002 + ``DW_ADDR_LLVM_group`` 0x0003 + ``DW_ADDR_LLVM_private`` 0x0004 + ``DW_ADDR_LLVM_lo_user`` 0x8000 + ``DW_ADDR_LLVM_hi_user`` 0xffff + ========================== ====== + +Line Number Information +~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + This augments DWARF Version 5 section 7.22 and Table 7.27. + +The following table gives the encoding of the additional line number header +entry formats. + +.. table:: Line number header entry format encodings + :name: amdgpu-dwarf-line-number-header-entry-format-encodings-table + + ==================================== ==================== + Line number header entry format name Value + ==================================== ==================== + ``DW_LNCT_LLVM_source`` 0x2001 + ``DW_LNCT_LLVM_is_MD5`` 0x2002 + ==================================== ==================== + +Call Frame Information +~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + This augments DWARF Version 5 section 7.24 and Table 7.29. + +The following table gives the encoding of the additional call frame information +instructions. + +.. table:: Call frame instruction encodings + :name: amdgpu-dwarf-call-frame-instruction-encodings-table + + ======================== ====== ====== ================ ================ ================ + Instruction High 2 Low 6 Operand 1 Operand 2 Operand 3 + Bits Bits + ======================== ====== ====== ================ ================ ================ + DW_CFA_def_aspace_cfa 0 0x30 ULEB128 register ULEB128 offset ULEB128 address space + DW_CFA_def_aspace_cfa_sf 0 0x31 ULEB128 register SLEB128 offset ULEB128 address space + ======================== ====== ====== ================ ================ ================ + +Attributes by Tag Value (Informative) +------------------------------------- + +.. note:: + + This augments DWARF Version 5 Appendix A and Table A.1. + +The following table provides the additional attributes that are applicable to +debugger information entries. + +.. table:: Attributes by tag value + :name: amdgpu-dwarf-attributes-by-tag-value-table + + ============================= ============================= + Tag Name Applicable Attributes + ============================= ============================= + ``DW_TAG_base_type`` * ``DW_AT_LLVM_vector_size`` + ``DW_TAG_compile_unit`` * ``DW_AT_LLVM_augmentation`` + ``DW_TAG_entry_point`` * ``DW_AT_LLVM_active_lane`` + * ``DW_AT_LLVM_lane_pc`` + * ``DW_AT_LLVM_lanes`` + ``DW_TAG_inlined_subroutine`` * ``DW_AT_LLVM_active_lane`` + * ``DW_AT_LLVM_lane_pc`` + * ``DW_AT_LLVM_lanes`` + ``DW_TAG_subprogram`` * ``DW_AT_LLVM_active_lane`` + * ``DW_AT_LLVM_lane_pc`` + * ``DW_AT_LLVM_lanes`` + ============================= ============================= + +.. _amdgpu-dwarf-examples: + +Examples +======== + +The AMD GPU specific usage of the features in the proposal, including examples, +is available at :ref:`amdgpu-dwarf-debug-information`. + +.. _amdgpu-dwarf-references: + +References +========== + + .. _amdgpu-dwarf-AMD: + +1. [AMD] `Advanced Micro Devices `__ + + .. _amdgpu-dwarf-AMD-ROCm: + +2. [AMD-ROCm] `AMD ROCm Platform `__ + + .. _amdgpu-dwarf-AMD-ROCgdb: + +3. [AMD-ROCgdb] `AMD ROCm Debugger (ROCgdb) `__ + + .. _amdgpu-dwarf-AMDGPU-LLVM: + +4. [AMDGPU-LLVM] `User Guide for AMDGPU LLVM Backend `__ + + .. _amdgpu-dwarf-CUDA: + +5. [CUDA] `Nvidia CUDA Language `__ + + .. _amdgpu-dwarf-DWARF: + +6. [DWARF] `DWARF Debugging Information Format `__ + + .. _amdgpu-dwarf-ELF: + +7. [ELF] `Executable and Linkable Format (ELF) `__ + + .. _amdgpu-dwarf-GCC: + +8. [GCC] `GCC: The GNU Compiler Collection `__ + + .. _amdgpu-dwarf-GDB: + +9. [GDB] `GDB: The GNU Project Debugger `__ + + .. _amdgpu-dwarf-HIP: + +10. [HIP] `HIP Programming Guide `__ + + .. _amdgpu-dwarf-HSA: + +11. [HSA] `Heterogeneous System Architecture (HSA) Foundation `__ + + .. _amdgpu-dwarf-LLVM: + +12. [LLVM] `The LLVM Compiler Infrastructure `__ + + .. _amdgpu-dwarf-OpenCL: + +13. [OpenCL] `The OpenCL Specification Version 2.0 `__ + + .. _amdgpu-dwarf-Perforce-TotalView: + +14. [Perforce-TotalView] `Perforce TotalView HPC Debugging Software `__ + + .. _amdgpu-dwarf-SEMVER: + +15. [SEMVER] `Semantic Versioning `__ diff --git a/gnu/llvm/llvm/docs/AMDGPUUsage.rst b/gnu/llvm/llvm/docs/AMDGPUUsage.rst index c153363b89e..af764c08560 100644 --- a/gnu/llvm/llvm/docs/AMDGPUUsage.rst +++ b/gnu/llvm/llvm/docs/AMDGPUUsage.rst @@ -5,6 +5,24 @@ User Guide for AMDGPU Backend .. contents:: :local: +.. toctree:: + :hidden: + + AMDGPU/AMDGPUAsmGFX7 + AMDGPU/AMDGPUAsmGFX8 + AMDGPU/AMDGPUAsmGFX9 + AMDGPU/AMDGPUAsmGFX900 + AMDGPU/AMDGPUAsmGFX904 + AMDGPU/AMDGPUAsmGFX906 + AMDGPU/AMDGPUAsmGFX908 + AMDGPU/AMDGPUAsmGFX10 + AMDGPU/AMDGPUAsmGFX1011 + AMDGPUModifierSyntax + AMDGPUOperandSyntax + AMDGPUInstructionSyntax + AMDGPUInstructionNotation + AMDGPUDwarfProposalForHeterogeneousDebugging + Introduction ============ @@ -207,42 +225,45 @@ names from both the *Processor* and *Alternative Processor* can be used. names. ``gfx906`` ``amdgcn`` dGPU - xnack - Radeon Instinct MI50 [off] - Radeon Instinct MI60 + - Radeon VII + - Radeon Pro VII ``gfx908`` ``amdgcn`` dGPU - xnack *TBA* [off] sram-ecc [on] - ``gfx909`` ``amdgcn`` APU - xnack *TBA* (Raven Ridge 2) + .. TODO:: + Add product + names. + ``gfx909`` ``amdgcn`` APU - xnack *TBA* [on] .. TODO:: Add product names. **GCN GFX10** [AMD-GCN-GFX10]_ ----------------------------------------------------------------------------------------------- - ``gfx1010`` ``amdgcn`` dGPU - xnack *TBA* - [off] - - wavefrontsize64 + ``gfx1010`` ``amdgcn`` dGPU - xnack - Radeon RX 5700 + [off] - Radeon RX 5700 XT + - wavefrontsize64 - Radeon Pro 5600 XT [off] - cumode [off] - .. TODO:: - Add product - names. - ``gfx1011`` ``amdgcn`` dGPU - xnack *TBA* + ``gfx1011`` ``amdgcn`` dGPU - xnack - Radeon Pro 5600M [off] - wavefrontsize64 [off] - cumode [off] - .. TODO:: - Add product - names. - ``gfx1012`` ``amdgcn`` dGPU - xnack *TBA* - [off] + ``gfx1012`` ``amdgcn`` dGPU - xnack - Radeon RX 5500 + [off] - Radeon RX 5500 XT - wavefrontsize64 [off] - cumode [off] - .. TODO:: + ``gfx1030`` ``amdgcn`` dGPU - wavefrontsize64 *TBA* + [off] + - cumode + [off] + .. TODO Add product names. =========== =============== ============ ===== ================= ======= ====================== @@ -290,7 +311,7 @@ For example: ``xnack`` feature is not enabled. Executing code that has the feature enabled on a device that does not have XNACK replay - enabled will execute correctly, but may + enabled will execute correctly but may be less performant than code with the feature disabled. @@ -317,8 +338,8 @@ Address Spaces The AMDGPU architecture supports a number of memory address spaces. The address space names use the OpenCL standard names, with some additions. -The AMDGPU address spaces correspond to architecture-specific LLVM address -space numbers used in LLVM IR. +The AMDGPU address spaces correspond to target architecture specific LLVM +address space numbers used in LLVM IR. The AMDGPU address spaces are described in :ref:`amdgpu-address-spaces-table`. Only 64-bit process address spaces are @@ -338,8 +359,8 @@ supported for the ``amdgcn`` target. Region 2 N/A GDS 32 *not implemented for AMDHSA* Local 3 group LDS 32 0xFFFFFFFF Constant 4 constant *same as global* 64 0x0000000000000000 - Private 5 private scratch 32 0x00000000 - Constant 32-bit 6 *TODO* + Private 5 private scratch 32 0xFFFFFFFF + Constant 32-bit 6 *TODO* 0x00000000 Buffer Fat Pointer (experimental) 7 *TODO* ================================= =============== =========== ================ ======= ============================ @@ -353,9 +374,9 @@ supported for the ``amdgcn`` target. (scratch), and group (LDS) memory depending on if the address is within one of the aperture ranges. Flat access to scratch requires hardware aperture setup and setup in the kernel prologue (see - :ref:`amdgpu-amdhsa-flat-scratch`). Flat access to LDS requires hardware - aperture setup and M0 (GFX7-GFX8) register setup (see - :ref:`amdgpu-amdhsa-m0`). + :ref:`amdgpu-amdhsa-kernel-prolog-flat-scratch`). Flat access to LDS requires + hardware aperture setup and M0 (GFX7-GFX8) register setup (see + :ref:`amdgpu-amdhsa-kernel-prolog-m0`). To convert between a private or group address space address (termed a segment address) and a flat address the base address of the corresponding aperture @@ -403,7 +424,7 @@ supported for the ``amdgcn`` target. **Private** The private address space uses the hardware scratch memory support which - automatically allocates memory when it creates a wavefront, and frees it when + automatically allocates memory when it creates a wavefront and frees it when a wavefronts terminates. The memory accessed by a lane of a wavefront for any given private address will be different to the memory accessed by another lane of the same or different wavefront for the same private address. @@ -454,7 +475,7 @@ backend memory model when the target triple OS is ``amdhsa`` (see The memory model supported is based on the HSA memory model [HSA]_ which is based in turn on HRF-indirect with scope inclusion [HRF]_. The happens-before -relation is transitive over the synchronizes-with relation independent of scope, +relation is transitive over the synchronizes-with relation independent of scope and synchronizes-with allows the memory scope instances to be inclusive (see table :ref:`amdgpu-amdhsa-llvm-sync-scopes-table`). @@ -480,7 +501,7 @@ is conservatively correct for OpenCL. - ``agent`` and executed by a thread on the same agent. - ``workgroup`` and executed by a thread in the - same workgroup. + same work-group. - ``wavefront`` and executed by a thread in the same wavefront. @@ -493,7 +514,7 @@ is conservatively correct for OpenCL. - ``system`` or ``agent`` and executed by a thread on the same agent. - ``workgroup`` and executed by a thread in the - same workgroup. + same work-group. - ``wavefront`` and executed by a thread in the same wavefront. @@ -504,7 +525,7 @@ is conservatively correct for OpenCL. provided the other operation's sync scope is: - ``system``, ``agent`` or ``workgroup`` and - executed by a thread in the same workgroup. + executed by a thread in the same work-group. - ``wavefront`` and executed by a thread in the same wavefront. @@ -518,7 +539,7 @@ is conservatively correct for OpenCL. ``wavefront`` and executed by a thread in the same wavefront. - ``singlethread`` Only synchronizes with, and participates in + ``singlethread`` Only synchronizes with and participates in modification and seq_cst total orderings with, other operations (except image operations) running in the same thread for all address spaces (for @@ -540,8 +561,8 @@ is conservatively correct for OpenCL. other operations within the same address space. ======================= =================================================== -AMDGPU Intrinsics ------------------ +LLVM IR Intrinsics +------------------ The AMDGPU backend implements the following LLVM IR intrinsics. @@ -551,8 +572,8 @@ The AMDGPU backend implements the following LLVM IR intrinsics. List AMDGPU intrinsics. -AMDGPU Attributes ------------------ +LLVM IR Attributes +------------------ The AMDGPU backend supports the following LLVM IR attributes. @@ -584,13 +605,17 @@ The AMDGPU backend supports the following LLVM IR attributes. for the calling convention. ======================================= ========================================================== -Code Object -=========== +.. _amdgpu-elf-code-object: + +ELF Code Object +=============== The AMDGPU backend generates a standard ELF [ELF]_ relocatable code object that can be linked by ``lld`` to produce a standard ELF shared code object which can be loaded and executed on an AMDGPU target. +.. _amdgpu-elf-header: + Header ------ @@ -648,7 +673,7 @@ The AMDGPU backend uses the following ELF header: All AMDGPU targets use ``ELFDATA2LSB`` for little-endian byte ordering. ``e_ident[EI_OSABI]`` - One of the following AMDGPU architecture specific OS ABIs + One of the following AMDGPU target architecture specific OS ABIs (see :ref:`amdgpu-os-table`): * ``ELFOSABI_NONE`` for *unknown* OS. @@ -660,7 +685,7 @@ The AMDGPU backend uses the following ELF header: * ``ELFOSABI_AMDGPU_MESA3D`` for ``mesa3D`` OS. ``e_ident[EI_ABIVERSION]`` - The ABI version of the AMDGPU architecture specific OS ABI to which the code + The ABI version of the AMDGPU target architecture specific OS ABI to which the code object conforms: * ``ELFABIVERSION_AMDGPU_HSA`` is used to specify the version of AMD HSA @@ -784,6 +809,7 @@ The AMDGPU backend uses the following ELF header: ``EF_AMDGPU_MACH_AMDGCN_GFX1010`` 0x033 ``gfx1010`` ``EF_AMDGPU_MACH_AMDGCN_GFX1011`` 0x034 ``gfx1011`` ``EF_AMDGPU_MACH_AMDGCN_GFX1012`` 0x035 ``gfx1012`` + ``EF_AMDGPU_MACH_AMDGCN_GFX1030`` 0x036 ``gfx1030`` ================================= ========== ============================= Sections @@ -819,8 +845,8 @@ These sections have their standard meanings (see [ELF]_) and are only generated if needed. ``.debug``\ *\** - The standard DWARF sections. See :ref:`amdgpu-dwarf` for information on the - DWARF produced by the AMDGPU backend. + The standard DWARF sections. See :ref:`amdgpu-dwarf-debug-information` for + information on the DWARF produced by the AMDGPU backend. ``.dynamic``, ``.dynstr``, ``.dynsym``, ``.hash`` The standard sections used by a dynamic loader. @@ -855,9 +881,9 @@ section. The set of generated notes and their semantics depend on the code object version; see :ref:`amdgpu-note-records-v2` and :ref:`amdgpu-note-records-v3`. -As required by ``ELFCLASS32`` and ``ELFCLASS64``, minimal zero byte padding +As required by ``ELFCLASS32`` and ``ELFCLASS64``, minimal zero-byte padding must be generated after the ``name`` field to ensure the ``desc`` field is 4 -byte aligned. In addition, minimal zero byte padding must be generated to +byte aligned. In addition, minimal zero-byte padding must be generated to ensure the ``desc`` field size is a multiple of 4 bytes. The ``sh_addralign`` field of the ``.note`` section must be at least 4 to indicate at least 8 byte alignment. @@ -977,7 +1003,7 @@ Global variable or explicitly defined by the runtime. If the symbol resides in local/group memory (LDS) then its section is the - special processor-specific section name ``SHN_AMDGPU_LDS``, and the + special processor specific section name ``SHN_AMDGPU_LDS``, and the ``st_value`` field describes alignment requirements as it does for common symbols. @@ -1073,80 +1099,864 @@ the ``mesa3d`` OS, which does not support ``R_AMDGPU_ABS64``. There is no current OS loader support for 32-bit programs and so ``R_AMDGPU_ABS32`` is not used. -.. _amdgpu-dwarf: +.. _amdgpu-loaded-code-object-path-uniform-resource-identifier: -DWARF ------ +Loaded Code Object Path Uniform Resource Identifier (URI) +--------------------------------------------------------- -Standard DWARF [DWARF]_ Version 5 sections can be generated. These contain -information that maps the code object executable code and data to the source -language constructs. It can be used by tools such as debuggers and profilers. +The AMD GPU code object loader represents the path of the ELF shared object from +which the code object was loaded as a textual Unifom Resource Identifier (URI). +Note that the code object is the in memory loaded relocated form of the ELF +shared object. Multiple code objects may be loaded at different memory +addresses in the same process from the same ELF shared object. -Address Space Mapping -~~~~~~~~~~~~~~~~~~~~~ +The loaded code object path URI syntax is defined by the following BNF syntax: -The following address space mapping is used: +.. code:: - .. table:: AMDGPU DWARF Address Space Mapping - :name: amdgpu-dwarf-address-space-mapping-table + code_object_uri ::== file_uri | memory_uri + file_uri ::== "file://" file_path [ range_specifier ] + memory_uri ::== "memory://" process_id range_specifier + range_specifier ::== [ "#" | "?" ] "offset=" number "&" "size=" number + file_path ::== URI_ENCODED_OS_FILE_PATH + process_id ::== DECIMAL_NUMBER + number ::== HEX_NUMBER | DECIMAL_NUMBER | OCTAL_NUMBER + +**number** + Is a C integral literal where hexadecimal values are prefixed by "0x" or "0X", + and octal values by "0". + +**file_path** + Is the file's path specified as a URI encoded UTF-8 string. In URI encoding, + every character that is not in the regular expression ``[a-zA-Z0-9/_.~-]`` is + encoded as two uppercase hexidecimal digits proceeded by "%". Directories in + the path are separated by "/". + +**offset** + Is a 0-based byte offset to the start of the code object. For a file URI, it + is from the start of the file specified by the ``file_path``, and if omitted + defaults to 0. For a memory URI, it is the memory address and is required. + +**size** + Is the number of bytes in the code object. For a file URI, if omitted it + defaults to the size of the file. It is required for a memory URI. + +**process_id** + Is the identity of the process owning the memory. For Linux it is the C + unsigned integral decimal literal for the process ID (PID). - =================== ================= - DWARF Address Space Memory Space - =================== ================= - 1 Private (Scratch) - 2 Local (group/LDS) - *omitted* Global - *omitted* Constant - *omitted* Generic (Flat) - *not supported* Region (GDS) - =================== ================= +For example: -See :ref:`amdgpu-address-spaces` for information on the address space -terminology used in the table. +.. code:: -An ``address_class`` attribute is generated on pointer type DIEs to specify the -DWARF address space of the value of the pointer when it is in the *private* or -*local* address space. Otherwise the attribute is omitted. + file:///dir1/dir2/file1 + file:///dir3/dir4/file2#offset=0x2000&size=3000 + memory://1234#offset=0x20000&size=3000 + +.. _amdgpu-dwarf-debug-information: + +DWARF Debug Information +======================= + +.. warning:: + + This section describes a **provisional proposal** for AMDGPU DWARF [DWARF]_ + that is not currently fully implemented and is subject to change. + +AMDGPU generates DWARF [DWARF]_ debugging information ELF sections (see +:ref:`amdgpu-elf-code-object`) which contain information that maps the code +object executable code and data to the source language constructs. It can be +used by tools such as debuggers and profilers. It uses features defined in +:doc:`AMDGPUDwarfProposalForHeterogeneousDebugging` that are made available in +DWARF Version 4 and DWARF Version 5 as an LLVM vendor extension. + +This section defines the AMDGPU target architecture specific DWARF mappings. + +.. _amdgpu-dwarf-register-identifier: + +Register Identifier +------------------- + +This section defines the AMDGPU target architecture register numbers used in +DWARF operation expressions (see DWARF Version 5 section 2.5 and +:ref:`amdgpu-dwarf-operation-expressions`) and Call Frame Information +instructions (see DWARF Version 5 section 6.4 and +:ref:`amdgpu-dwarf-call-frame-information`). + +A single code object can contain code for kernels that have different wavefront +sizes. The vector registers and some scalar registers are based on the wavefront +size. AMDGPU defines distinct DWARF registers for each wavefront size. This +simplifies the consumer of the DWARF so that each register has a fixed size, +rather than being dynamic according to the wavefront size mode. Similarly, +distinct DWARF registers are defined for those registers that vary in size +according to the process address size. This allows a consumer to treat a +specific AMDGPU processor as a single architecture regardless of how it is +configured at run time. The compiler explicitly specifies the DWARF registers +that match the mode in which the code it is generating will be executed. + +DWARF registers are encoded as numbers, which are mapped to architecture +registers. The mapping for AMDGPU is defined in +:ref:`amdgpu-dwarf-register-mapping-table`. All AMDGPU targets use the same +mapping. + +.. table:: AMDGPU DWARF Register Mapping + :name: amdgpu-dwarf-register-mapping-table + + ============== ================= ======== ================================== + DWARF Register AMDGPU Register Bit Size Description + ============== ================= ======== ================================== + 0 PC_32 32 Program Counter (PC) when + executing in a 32-bit process + address space. Used in the CFI to + describe the PC of the calling + frame. + 1 EXEC_MASK_32 32 Execution Mask Register when + executing in wavefront 32 mode. + 2-15 *Reserved* *Reserved for highly accessed + registers using DWARF shortcut.* + 16 PC_64 64 Program Counter (PC) when + executing in a 64-bit process + address space. Used in the CFI to + describe the PC of the calling + frame. + 17 EXEC_MASK_64 64 Execution Mask Register when + executing in wavefront 64 mode. + 18-31 *Reserved* *Reserved for highly accessed + registers using DWARF shortcut.* + 32-95 SGPR0-SGPR63 32 Scalar General Purpose + Registers. + 96-127 *Reserved* *Reserved for frequently accessed + registers using DWARF 1-byte ULEB.* + 128 SCC 32 Scalar Condition Code Register. + 129-511 *Reserved* *Reserved for future Scalar + Architectural Registers.* + 512 VCC_32 32 Vector Condition Code Register + when executing in wavefront 32 + mode. + 513-1023 *Reserved* *Reserved for future Vector + Architectural Registers when + executing in wavefront 32 mode.* + 768 VCC_64 32 Vector Condition Code Register + when executing in wavefront 64 + mode. + 769-1023 *Reserved* *Reserved for future Vector + Architectural Registers when + executing in wavefront 64 mode.* + 1024-1087 *Reserved* *Reserved for padding.* + 1088-1129 SGPR64-SGPR105 32 Scalar General Purpose Registers. + 1130-1535 *Reserved* *Reserved for future Scalar + General Purpose Registers.* + 1536-1791 VGPR0-VGPR255 32*32 Vector General Purpose Registers + when executing in wavefront 32 + mode. + 1792-2047 *Reserved* *Reserved for future Vector + General Purpose Registers when + executing in wavefront 32 mode.* + 2048-2303 AGPR0-AGPR255 32*32 Vector Accumulation Registers + when executing in wavefront 32 + mode. + 2304-2559 *Reserved* *Reserved for future Vector + Accumulation Registers when + executing in wavefront 32 mode.* + 2560-2815 VGPR0-VGPR255 64*32 Vector General Purpose Registers + when executing in wavefront 64 + mode. + 2816-3071 *Reserved* *Reserved for future Vector + General Purpose Registers when + executing in wavefront 64 mode.* + 3072-3327 AGPR0-AGPR255 64*32 Vector Accumulation Registers + when executing in wavefront 64 + mode. + 3328-3583 *Reserved* *Reserved for future Vector + Accumulation Registers when + executing in wavefront 64 mode.* + ============== ================= ======== ================================== + +The vector registers are represented as the full size for the wavefront. They +are organized as consecutive dwords (32-bits), one per lane, with the dword at +the least significant bit position corresponding to lane 0 and so forth. DWARF +location expressions involving the ``DW_OP_LLVM_offset`` and +``DW_OP_LLVM_push_lane`` operations are used to select the part of the vector +register corresponding to the lane that is executing the current thread of +execution in languages that are implemented using a SIMD or SIMT execution +model. + +If the wavefront size is 32 lanes then the wavefront 32 mode register +definitions are used. If the wavefront size is 64 lanes then the wavefront 64 +mode register definitions are used. Some AMDGPU targets support executing in +both wavefront 32 and wavefront 64 mode. The register definitions corresponding +to the wavefront mode of the generated code will be used. + +If code is generated to execute in a 32-bit process address space, then the +32-bit process address space register definitions are used. If code is generated +to execute in a 64-bit process address space, then the 64-bit process address +space register definitions are used. The ``amdgcn`` target only supports the +64-bit process address space. + +.. _amdgpu-dwarf-address-class-identifier: + +Address Class Identifier +------------------------ + +The DWARF address class represents the source language memory space. See DWARF +Version 5 section 2.12 which is updated by the propoal in +:ref:`amdgpu-dwarf-segment_addresses`. + +The DWARF address class mapping used for AMDGPU is defined in +:ref:`amdgpu-dwarf-address-class-mapping-table`. + +.. table:: AMDGPU DWARF Address Class Mapping + :name: amdgpu-dwarf-address-class-mapping-table + + ========================= ====== ================= + DWARF AMDGPU + -------------------------------- ----------------- + Address Class Name Value Address Space + ========================= ====== ================= + ``DW_ADDR_none`` 0x0000 Generic (Flat) + ``DW_ADDR_LLVM_global`` 0x0001 Global + ``DW_ADDR_LLVM_constant`` 0x0002 Global + ``DW_ADDR_LLVM_group`` 0x0003 Local (group/LDS) + ``DW_ADDR_LLVM_private`` 0x0004 Private (Scratch) + ``DW_ADDR_AMDGPU_region`` 0x8000 Region (GDS) + ========================= ====== ================= + +The DWARF address class values defined in the proposal at +:ref:`amdgpu-dwarf-segment_addresses` are used. + +In addition, ``DW_ADDR_AMDGPU_region`` is encoded as a vendor extension. This is +available for use for the AMD extension for access to the hardware GDS memory +which is scratchpad memory allocated per device. + +For AMDGPU if no ``DW_AT_address_class`` attribute is present, then the default +address class of ``DW_ADDR_none`` is used. + +See :ref:`amdgpu-dwarf-address-space-identifier` for information on the AMDGPU +mapping of DWARF address classes to DWARF address spaces, including address size +and NULL value. + +.. _amdgpu-dwarf-address-space-identifier: + +Address Space Identifier +------------------------ + +DWARF address spaces correspond to target architecture specific linear +addressable memory areas. See DWARF Version 5 section 2.12 and +:ref:`amdgpu-dwarf-segment_addresses`. + +The DWARF address space mapping used for AMDGPU is defined in +:ref:`amdgpu-dwarf-address-space-mapping-table`. + +.. table:: AMDGPU DWARF Address Space Mapping + :name: amdgpu-dwarf-address-space-mapping-table + + ======================================= ===== ======= ======== ================= ======================= + DWARF AMDGPU Notes + --------------------------------------- ----- ---------------- ----------------- ----------------------- + Address Space Name Value Address Bit Size Address Space + --------------------------------------- ----- ------- -------- ----------------- ----------------------- + .. 64-bit 32-bit + process process + address address + space space + ======================================= ===== ======= ======== ================= ======================= + ``DW_ASPACE_none`` 0x00 8 4 Global *default address space* + ``DW_ASPACE_AMDGPU_generic`` 0x01 8 4 Generic (Flat) + ``DW_ASPACE_AMDGPU_region`` 0x02 4 4 Region (GDS) + ``DW_ASPACE_AMDGPU_local`` 0x03 4 4 Local (group/LDS) + *Reserved* 0x04 + ``DW_ASPACE_AMDGPU_private_lane`` 0x05 4 4 Private (Scratch) *focused lane* + ``DW_ASPACE_AMDGPU_private_wave`` 0x06 4 4 Private (Scratch) *unswizzled wavefront* + *Reserved* 0x07- + 0x1F + ``DW_ASPACE_AMDGPU_private_lane<0-63>`` 0x20- 4 4 Private (Scratch) *specific lane* + 0x5F + ======================================= ===== ======= ======== ================= ======================= + +See :ref:`amdgpu-address-spaces` for information on the AMDGPU address spaces +including address size and NULL value. + +The ``DW_ASPACE_none`` address space is the default target architecture address +space used in DWARF operations that do not specify an address space. It +therefore has to map to the global address space so that the ``DW_OP_addr*`` and +related operations can refer to addresses in the program code. + +The ``DW_ASPACE_AMDGPU_generic`` address space allows location expressions to +specify the flat address space. If the address corresponds to an address in the +local address space, then it corresponds to the wavefront that is executing the +focused thread of execution. If the address corresponds to an address in the +private address space, then it corresponds to the lane that is executing the +focused thread of execution for languages that are implemented using a SIMD or +SIMT execution model. + +.. note:: + + CUDA-like languages such as HIP that do not have address spaces in the + language type system, but do allow variables to be allocated in different + address spaces, need to explicitly specify the ``DW_ASPACE_AMDGPU_generic`` + address space in the DWARF expression operations as the default address space + is the global address space. + +The ``DW_ASPACE_AMDGPU_local`` address space allows location expressions to +specify the local address space corresponding to the wavefront that is executing +the focused thread of execution. + +The ``DW_ASPACE_AMDGPU_private_lane`` address space allows location expressions +to specify the private address space corresponding to the lane that is executing +the focused thread of execution for languages that are implemented using a SIMD +or SIMT execution model. + +The ``DW_ASPACE_AMDGPU_private_wave`` address space allows location expressions +to specify the unswizzled private address space corresponding to the wavefront +that is executing the focused thread of execution. The wavefront view of private +memory is the per wavefront unswizzled backing memory layout defined in +:ref:`amdgpu-address-spaces`, such that address 0 corresponds to the first +location for the backing memory of the wavefront (namely the address is not +offset by ``wavefront-scratch-base``). The following formula can be used to +convert from a ``DW_ASPACE_AMDGPU_private_lane`` address to a +``DW_ASPACE_AMDGPU_private_wave`` address: + +:: + + private-address-wavefront = + ((private-address-lane / 4) * wavefront-size * 4) + + (wavefront-lane-id * 4) + (private-address-lane % 4) + +If the ``DW_ASPACE_AMDGPU_private_lane`` address is dword aligned, and the start +of the dwords for each lane starting with lane 0 is required, then this +simplifies to: + +:: + + private-address-wavefront = + private-address-lane * wavefront-size + +A compiler can use the ``DW_ASPACE_AMDGPU_private_wave`` address space to read a +complete spilled vector register back into a complete vector register in the +CFI. The frame pointer can be a private lane address which is dword aligned, +which can be shifted to multiply by the wavefront size, and then used to form a +private wavefront address that gives a location for a contiguous set of dwords, +one per lane, where the vector register dwords are spilled. The compiler knows +the wavefront size since it generates the code. Note that the type of the +address may have to be converted as the size of a +``DW_ASPACE_AMDGPU_private_lane`` address may be smaller than the size of a +``DW_ASPACE_AMDGPU_private_wave`` address. + +The ``DW_ASPACE_AMDGPU_private_lane`` address space allows location +expressions to specify the private address space corresponding to a specific +lane N. For example, this can be used when the compiler spills scalar registers +to scratch memory, with each scalar register being saved to a different lane's +scratch memory. + +.. _amdgpu-dwarf-lane-identifier: + +Lane identifier +--------------- -An ``DW_OP_xderef`` operation is generated in location list expressions for -variables that are allocated in the *private* and *local* address space. -Otherwise, ``DW_OP_xderef`` is omitted. +DWARF lane identifies specify a target architecture lane position for hardware +that executes in a SIMD or SIMT manner, and on which a source language maps its +threads of execution onto those lanes. The DWARF lane identifier is pushed by +the ``DW_OP_LLVM_push_lane`` DWARF expression operation. See DWARF Version 5 +section 2.5 which is updated by the proposal in +:ref:`amdgpu-dwarf-operation-expressions`. + +For AMDGPU, the lane identifier corresponds to the hardware lane ID of a +wavefront. It is numbered from 0 to the wavefront size minus 1. + +Operation Expressions +--------------------- + +DWARF expressions are used to compute program values and the locations of +program objects. See DWARF Version 5 section 2.5 and +:ref:`amdgpu-dwarf-operation-expressions`. + +DWARF location descriptions describe how to access storage which includes memory +and registers. When accessing storage on AMDGPU, bytes are ordered with least +significant bytes first, and bits are ordered within bytes with least +significant bits first. + +For AMDGPU CFI expressions, ``DW_OP_LLVM_select_bit_piece`` is used to describe +unwinding vector registers that are spilled under the execution mask to memory: +the zero-single location description is the vector register, and the one-single +location description is the spilled memory location description. The +``DW_OP_LLVM_form_aspace_address`` is used to specify the address space of the +memory location description. + +In AMDGPU expressions, ``DW_OP_LLVM_select_bit_piece`` is used by the +``DW_AT_LLVM_lane_pc`` attribute expression where divergent control flow is +controlled by the execution mask. An undefined location description together +with ``DW_OP_LLVM_extend`` is used to indicate the lane was not active on entry +to the subprogram. See :ref:`amdgpu-dwarf-dw-at-llvm-lane-pc` for an example. + +Debugger Information Entry Attributes +------------------------------------- + +This section describes how certain debugger information entry attributes are +used by AMDGPU. See the sections in DWARF Version 5 section 2 which are updated +by the proposal in :ref:`amdgpu-dwarf-debugging-information-entry-attributes`. + +.. _amdgpu-dwarf-dw-at-llvm-lane-pc: + +``DW_AT_LLVM_lane_pc`` +~~~~~~~~~~~~~~~~~~~~~~ + +For AMDGPU, the ``DW_AT_LLVM_lane_pc`` attribute is used to specify the program +location of the separate lanes of a SIMT thread. + +If the lane is an active lane then this will be the same as the current program +location. + +If the lane is inactive, but was active on entry to the subprogram, then this is +the program location in the subprogram at which execution of the lane is +conceptual positioned. + +If the lane was not active on entry to the subprogram, then this will be the +undefined location. A client debugger can check if the lane is part of a valid +work-group by checking that the lane is in the range of the associated +work-group within the grid, accounting for partial work-groups. If it is not, +then the debugger can omit any information for the lane. Otherwise, the debugger +may repeatedly unwind the stack and inspect the ``DW_AT_LLVM_lane_pc`` of the +calling subprogram until it finds a non-undefined location. Conceptually the +lane only has the call frames that it has a non-undefined +``DW_AT_LLVM_lane_pc``. + +The following example illustrates how the AMDGPU backend can generate a DWARF +location list expression for the nested ``IF/THEN/ELSE`` structures of the +following subprogram pseudo code for a target with 64 lanes per wavefront. -Register Mapping -~~~~~~~~~~~~~~~~ +.. code:: + :number-lines: + + SUBPROGRAM X + BEGIN + a; + IF (c1) THEN + b; + IF (c2) THEN + c; + ELSE + d; + ENDIF + e; + ELSE + f; + ENDIF + g; + END + +The AMDGPU backend may generate the following pseudo LLVM MIR to manipulate the +execution mask (``EXEC``) to linearize the control flow. The condition is +evaluated to make a mask of the lanes for which the condition evaluates to true. +First the ``THEN`` region is executed by setting the ``EXEC`` mask to the +logical ``AND`` of the current ``EXEC`` mask with the condition mask. Then the +``ELSE`` region is executed by negating the ``EXEC`` mask and logical ``AND`` of +the saved ``EXEC`` mask at the start of the region. After the ``IF/THEN/ELSE`` +region the ``EXEC`` mask is restored to the value it had at the beginning of the +region. This is shown below. Other approaches are possible, but the basic +concept is the same. -*This section is WIP.* +.. code:: + :number-lines: + + $lex_start: + a; + %1 = EXEC + %2 = c1 + $lex_1_start: + EXEC = %1 & %2 + $if_1_then: + b; + %3 = EXEC + %4 = c2 + $lex_1_1_start: + EXEC = %3 & %4 + $lex_1_1_then: + c; + EXEC = ~EXEC & %3 + $lex_1_1_else: + d; + EXEC = %3 + $lex_1_1_end: + e; + EXEC = ~EXEC & %1 + $lex_1_else: + f; + EXEC = %1 + $lex_1_end: + g; + $lex_end: + +To create the DWARF location list expression that defines the location +description of a vector of lane program locations, the LLVM MIR ``DBG_VALUE`` +pseudo instruction can be used to annotate the linearized control flow. This can +be done by defining an artificial variable for the lane PC. The DWARF location +list expression created for it is used as the value of the +``DW_AT_LLVM_lane_pc`` attribute on the subprogram's debugger information entry. + +A DWARF procedure is defined for each well nested structured control flow region +which provides the conceptual lane program location for a lane if it is not +active (namely it is divergent). The DWARF operation expression for each region +conceptually inherits the value of the immediately enclosing region and modifies +it according to the semantics of the region. + +For an ``IF/THEN/ELSE`` region the divergent program location is at the start of +the region for the ``THEN`` region since it is executed first. For the ``ELSE`` +region the divergent program location is at the end of the ``IF/THEN/ELSE`` +region since the ``THEN`` region has completed. + +The lane PC artificial variable is assigned at each region transition. It uses +the immediately enclosing region's DWARF procedure to compute the program +location for each lane assuming they are divergent, and then modifies the result +by inserting the current program location for each lane that the ``EXEC`` mask +indicates is active. + +By having separate DWARF procedures for each region, they can be reused to +define the value for any nested region. This reduces the total size of the DWARF +operation expressions. + +The following provides an example using pseudo LLVM MIR. + +.. code:: + :number-lines: + + $lex_start: + DEFINE_DWARF %__uint_64 = DW_TAG_base_type[ + DW_AT_name = "__uint64"; + DW_AT_byte_size = 8; + DW_AT_encoding = DW_ATE_unsigned; + ]; + DEFINE_DWARF %__active_lane_pc = DW_TAG_dwarf_procedure[ + DW_AT_name = "__active_lane_pc"; + DW_AT_location = [ + DW_OP_regx PC; + DW_OP_LLVM_extend 64, 64; + DW_OP_regval_type EXEC, %uint_64; + DW_OP_LLVM_select_bit_piece 64, 64; + ]; + ]; + DEFINE_DWARF %__divergent_lane_pc = DW_TAG_dwarf_procedure[ + DW_AT_name = "__divergent_lane_pc"; + DW_AT_location = [ + DW_OP_LLVM_undefined; + DW_OP_LLVM_extend 64, 64; + ]; + ]; + DBG_VALUE $noreg, $noreg, %DW_AT_LLVM_lane_pc, DIExpression[ + DW_OP_call_ref %__divergent_lane_pc; + DW_OP_call_ref %__active_lane_pc; + ]; + a; + %1 = EXEC; + DBG_VALUE %1, $noreg, %__lex_1_save_exec; + %2 = c1; + $lex_1_start: + EXEC = %1 & %2; + $lex_1_then: + DEFINE_DWARF %__divergent_lane_pc_1_then = DW_TAG_dwarf_procedure[ + DW_AT_name = "__divergent_lane_pc_1_then"; + DW_AT_location = DIExpression[ + DW_OP_call_ref %__divergent_lane_pc; + DW_OP_addrx &lex_1_start; + DW_OP_stack_value; + DW_OP_LLVM_extend 64, 64; + DW_OP_call_ref %__lex_1_save_exec; + DW_OP_deref_type 64, %__uint_64; + DW_OP_LLVM_select_bit_piece 64, 64; + ]; + ]; + DBG_VALUE $noreg, $noreg, %DW_AT_LLVM_lane_pc, DIExpression[ + DW_OP_call_ref %__divergent_lane_pc_1_then; + DW_OP_call_ref %__active_lane_pc; + ]; + b; + %3 = EXEC; + DBG_VALUE %3, %__lex_1_1_save_exec; + %4 = c2; + $lex_1_1_start: + EXEC = %3 & %4; + $lex_1_1_then: + DEFINE_DWARF %__divergent_lane_pc_1_1_then = DW_TAG_dwarf_procedure[ + DW_AT_name = "__divergent_lane_pc_1_1_then"; + DW_AT_location = DIExpression[ + DW_OP_call_ref %__divergent_lane_pc_1_then; + DW_OP_addrx &lex_1_1_start; + DW_OP_stack_value; + DW_OP_LLVM_extend 64, 64; + DW_OP_call_ref %__lex_1_1_save_exec; + DW_OP_deref_type 64, %__uint_64; + DW_OP_LLVM_select_bit_piece 64, 64; + ]; + ]; + DBG_VALUE $noreg, $noreg, %DW_AT_LLVM_lane_pc, DIExpression[ + DW_OP_call_ref %__divergent_lane_pc_1_1_then; + DW_OP_call_ref %__active_lane_pc; + ]; + c; + EXEC = ~EXEC & %3; + $lex_1_1_else: + DEFINE_DWARF %__divergent_lane_pc_1_1_else = DW_TAG_dwarf_procedure[ + DW_AT_name = "__divergent_lane_pc_1_1_else"; + DW_AT_location = DIExpression[ + DW_OP_call_ref %__divergent_lane_pc_1_then; + DW_OP_addrx &lex_1_1_end; + DW_OP_stack_value; + DW_OP_LLVM_extend 64, 64; + DW_OP_call_ref %__lex_1_1_save_exec; + DW_OP_deref_type 64, %__uint_64; + DW_OP_LLVM_select_bit_piece 64, 64; + ]; + ]; + DBG_VALUE $noreg, $noreg, %DW_AT_LLVM_lane_pc, DIExpression[ + DW_OP_call_ref %__divergent_lane_pc_1_1_else; + DW_OP_call_ref %__active_lane_pc; + ]; + d; + EXEC = %3; + $lex_1_1_end: + DBG_VALUE $noreg, $noreg, %DW_AT_LLVM_lane_pc, DIExpression[ + DW_OP_call_ref %__divergent_lane_pc; + DW_OP_call_ref %__active_lane_pc; + ]; + e; + EXEC = ~EXEC & %1; + $lex_1_else: + DEFINE_DWARF %__divergent_lane_pc_1_else = DW_TAG_dwarf_procedure[ + DW_AT_name = "__divergent_lane_pc_1_else"; + DW_AT_location = DIExpression[ + DW_OP_call_ref %__divergent_lane_pc; + DW_OP_addrx &lex_1_end; + DW_OP_stack_value; + DW_OP_LLVM_extend 64, 64; + DW_OP_call_ref %__lex_1_save_exec; + DW_OP_deref_type 64, %__uint_64; + DW_OP_LLVM_select_bit_piece 64, 64; + ]; + ]; + DBG_VALUE $noreg, $noreg, %DW_AT_LLVM_lane_pc, DIExpression[ + DW_OP_call_ref %__divergent_lane_pc_1_else; + DW_OP_call_ref %__active_lane_pc; + ]; + f; + EXEC = %1; + $lex_1_end: + DBG_VALUE $noreg, $noreg, %DW_AT_LLVM_lane_pc DIExpression[ + DW_OP_call_ref %__divergent_lane_pc; + DW_OP_call_ref %__active_lane_pc; + ]; + g; + $lex_end: + +The DWARF procedure ``%__active_lane_pc`` is used to update the lane pc elements +that are active, with the current program location. + +Artificial variables %__lex_1_save_exec and %__lex_1_1_save_exec are created for +the execution masks saved on entry to a region. Using the ``DBG_VALUE`` pseudo +instruction, location list entries will be created that describe where the +artificial variables are allocated at any given program location. The compiler +may allocate them to registers or spill them to memory. + +The DWARF procedures for each region use the values of the saved execution mask +artificial variables to only update the lanes that are active on entry to the +region. All other lanes retain the value of the enclosing region where they were +last active. If they were not active on entry to the subprogram, then will have +the undefined location description. + +Other structured control flow regions can be handled similarly. For example, +loops would set the divergent program location for the region at the end of the +loop. Any lanes active will be in the loop, and any lanes not active must have +exited the loop. + +An ``IF/THEN/ELSEIF/ELSEIF/...`` region can be treated as a nest of +``IF/THEN/ELSE`` regions. + +The DWARF procedures can use the active lane artificial variable described in +:ref:`amdgpu-dwarf-amdgpu-dw-at-llvm-active-lane` rather than the actual +``EXEC`` mask in order to support whole or quad wavefront mode. + +.. _amdgpu-dwarf-amdgpu-dw-at-llvm-active-lane: + +``DW_AT_LLVM_active_lane`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The ``DW_AT_LLVM_active_lane`` attribute on a subprogram debugger information +entry is used to specify the lanes that are conceptually active for a SIMT +thread. + +The execution mask may be modified to implement whole or quad wavefront mode +operations. For example, all lanes may need to temporarily be made active to +execute a whole wavefront operation. Such regions would save the ``EXEC`` mask, +update it to enable the necessary lanes, perform the operations, and then +restore the ``EXEC`` mask from the saved value. While executing the whole +wavefront region, the conceptual execution mask is the saved value, not the +``EXEC`` value. + +This is handled by defining an artificial variable for the active lane mask. The +active lane mask artificial variable would be the actual ``EXEC`` mask for +normal regions, and the saved execution mask for regions where the mask is +temporarily updated. The location list expression created for this artificial +variable is used to define the value of the ``DW_AT_LLVM_active_lane`` +attribute. + +``DW_AT_LLVM_augmentation`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For AMDGPU, the ``DW_AT_LLVM_augmentation`` attribute of a compilation unit +debugger information entry has the following value for the augmentation string: + +:: + + [amdgpu:v0.0] + +The "vX.Y" specifies the major X and minor Y version number of the AMDGPU +extensions used in the DWARF of the compilation unit. The version number +conforms to [SEMVER]_. + +Call Frame Information +---------------------- + +DWARF Call Frame Information (CFI) describes how a consumer can virtually +*unwind* call frames in a running process or core dump. See DWARF Version 5 +section 6.4 and :ref:`amdgpu-dwarf-call-frame-information`. + +For AMDGPU, the Common Information Entry (CIE) fields have the following values: + +1. ``augmentation`` string contains the following null-terminated UTF-8 string: + + :: + + [amd:v0.0] + + The ``vX.Y`` specifies the major X and minor Y version number of the AMDGPU + extensions used in this CIE or to the FDEs that use it. The version number + conforms to [SEMVER]_. + +2. ``address_size`` for the ``Global`` address space is defined in + :ref:`amdgpu-dwarf-address-space-identifier`. + +3. ``segment_selector_size`` is 0 as AMDGPU does not use a segment selector. + +4. ``code_alignment_factor`` is 4 bytes. + + .. TODO:: + + Add to :ref:`amdgpu-processor-table` table. + +5. ``data_alignment_factor`` is 4 bytes. + + .. TODO:: + + Add to :ref:`amdgpu-processor-table` table. + +6. ``return_address_register`` is ``PC_32`` for 32-bit processes and ``PC_64`` + for 64-bit processes defined in :ref:`amdgpu-dwarf-register-identifier`. + +7. ``initial_instructions`` Since a subprogram X with fewer registers can be + called from subprogram Y that has more allocated, X will not change any of + the extra registers as it cannot access them. Therefore, the default rule + for all columns is ``same value``. + +For AMDGPU the register number follows the numbering defined in +:ref:`amdgpu-dwarf-register-identifier`. + +For AMDGPU the instructions are variable size. A consumer can subtract 1 from +the return address to get the address of a byte within the call site +instructions. See DWARF Version 5 section 6.4.4. + +Accelerated Access +------------------ + +See DWARF Version 5 section 6.1. + +Lookup By Name Section Header +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +See DWARF Version 5 section 6.1.1.4.1 and :ref:`amdgpu-dwarf-lookup-by-name`. + +For AMDGPU the lookup by name section header table: + +``augmentation_string_size`` (uword) + + Set to the length of the ``augmentation_string`` value which is always a + multiple of 4. + +``augmentation_string`` (sequence of UTF-8 characters) + + Contains the following UTF-8 string null padded to a multiple of 4 bytes: + + :: + + [amdgpu:v0.0] + + The "vX.Y" specifies the major X and minor Y version number of the AMDGPU + extensions used in the DWARF of this index. The version number conforms to + [SEMVER]_. + + .. note:: + + This is different to the DWARF Version 5 definition that requires the first + 4 characters to be the vendor ID. But this is consistent with the other + augmentation strings and does allow multiple vendor contributions. However, + backwards compatibility may be more desirable. + +Lookup By Address Section Header +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +See DWARF Version 5 section 6.1.2. + +For AMDGPU the lookup by address section header table: + +``address_size`` (ubyte) + + Match the address size for the ``Global`` address space defined in + :ref:`amdgpu-dwarf-address-space-identifier`. + +``segment_selector_size`` (ubyte) + + AMDGPU does not use a segment selector so this is 0. The entries in the + ``.debug_aranges`` do not have a segment selector. + +Line Number Information +----------------------- + +See DWARF Version 5 section 6.2 and :ref:`amdgpu-dwarf-line-number-information`. + +AMDGPU does not use the ``isa`` state machine registers and always sets it to 0. +The instruction set must be obtained from the ELF file header ``e_flags`` field +in the ``EF_AMDGPU_MACH`` bit position (see :ref:`ELF Header +`). See DWARF Version 5 section 6.2.2. .. TODO:: - Define DWARF register enumeration. - - If want to present a wavefront state then should expose vector registers as - 64 dword wide (rather than per work-item view that LLVM uses). Either as - separate registers, or a 64x4 byte single register. In either case use a new - ``DW_OP_lane`` op (akin to ``DW_OP_xderef``) to select the current lane usage - in a location expression. This would also allow scalar register spilling to - vector register lanes to be expressed (currently no debug information is - being generated for spilling). If choose a wide single register approach then - use ``DW_OP_lane`` in conjunction with ``DW_OP_piece`` operation to select - the dword part of the register for the current lane. If the separate register - approach then use ``DW_OP_lane`` to select the register. - -Source Text -~~~~~~~~~~~ -Source text for online-compiled programs (e.g. those compiled by the OpenCL -runtime) may be embedded into the DWARF v5 line table using the ``clang --gembed-source`` option, described in table :ref:`amdgpu-debug-options`. + Should the ``isa`` state machine register be used to indicate if the code is + in wavefront32 or wavefront64 mode? Or used to specify the architecture ISA? -For example: +For AMDGPU the line number program header fields have the following values (see +DWARF Version 5 section 6.2.4): -``-gembed-source`` - Enable the embedded source DWARF v5 extension. -``-gno-embed-source`` - Disable the embedded source DWARF v5 extension. +``address_size`` (ubyte) + Matches the address size for the ``Global`` address space defined in + :ref:`amdgpu-dwarf-address-space-identifier`. + +``segment_selector_size`` (ubyte) + AMDGPU does not use a segment selector so this is 0. + +``minimum_instruction_length`` (ubyte) + For GFX9-GFX10 this is 4. + +``maximum_operations_per_instruction`` (ubyte) + For GFX9-GFX10 this is 1. + +Source text for online-compiled programs (for example, those compiled by the +OpenCL language runtime) may be embedded into the DWARF Version 5 line table. +See DWARF Version 5 section 6.2.4.1 which is updated by the proposal in +:ref:`DW_LNCT_LLVM_source +`. - .. table:: AMDGPU Debug Options - :name: amdgpu-debug-options +The Clang option used to control source embedding in AMDGPU is defined in +:ref:`amdgpu-clang-debug-options-table`. + + .. table:: AMDGPU Clang Debug Options + :name: amdgpu-clang-debug-options-table ==================== ================================================== Debug Flag Description @@ -1157,37 +1967,37 @@ For example: when performing online compilation. ==================== ================================================== -This option enables one extended content types in the DWARF v5 Line Number -Program Header, which is used to encode embedded source. +For example: + +``-gembed-source`` + Enable the embedded source. + +``-gno-embed-source`` + Disable the embedded source. + +32-Bit and 64-Bit DWARF Formats +------------------------------- - .. table:: AMDGPU DWARF Line Number Program Header Extended Content Types - :name: amdgpu-dwarf-extended-content-types +See DWARF Version 5 section 7.4 and +:ref:`amdgpu-dwarf-32-bit-and-64-bit-dwarf-formats`. - ============================ ====================== - Content Type Form - ============================ ====================== - ``DW_LNCT_LLVM_source`` ``DW_FORM_line_strp`` - ============================ ====================== +For AMDGPU: -The source field will contain the UTF-8 encoded, null-terminated source text -with ``'\n'`` line endings. When the source field is present, consumers can use -the embedded source instead of attempting to discover the source on disk. When -the source field is absent, consumers can access the file to get the source -text. +* For the ``amdgcn`` target architecture only the 64-bit process address space + is supported. -The above content type appears in the ``file_name_entry_format`` field of the -line table prologue, and its corresponding value appear in the ``file_names`` -field. The current encoding of the content type is documented in table -:ref:`amdgpu-dwarf-extended-content-types-encoding` +* The producer can generate either 32-bit or 64-bit DWARF format. LLVM generates + the 32-bit DWARF format. - .. table:: AMDGPU DWARF Line Number Program Header Extended Content Types Encoding - :name: amdgpu-dwarf-extended-content-types-encoding +Unit Headers +------------ - ============================ ==================== - Content Type Value - ============================ ==================== - ``DW_LNCT_LLVM_source`` 0x2001 - ============================ ==================== +For AMDGPU the following values apply for each of the unit headers described in +DWARF Version 5 sections 7.5.1.1, 7.5.1.2, and 7.5.1.3: + +``address_size`` (ubyte) + Matches the address size for the ``Global`` address space defined in + :ref:`amdgpu-dwarf-address-space-identifier`. .. _amdgpu-code-conventions: @@ -1248,7 +2058,7 @@ Code object metadata is specified in a note record (see :ref:`amdgpu-note-records`) and is required when the target triple OS is ``amdhsa`` (see :ref:`amdgpu-target-triples`). It must contain the minimum information necessary to support the ROCM kernel queries. For example, the -segment sizes needed in a dispatch packet. In addition, a high level language +segment sizes needed in a dispatch packet. In addition, a high-level language runtime may require other information to be included. For example, the AMD OpenCL runtime records kernel argument information. @@ -1508,29 +2318,10 @@ non-AMD key names should be prefixed by "*vendor-name*.". multi-grid synchronization is passed in the kernarg. - "ValueType" string Required Kernel argument value type. Only - present if "ValueKind" is - "ByValue". For vector data - types, the value is for the - element type. Values include: - - - "Struct" - - "I8" - - "U8" - - "I16" - - "U16" - - "F16" - - "I32" - - "U32" - - "F32" - - "I64" - - "U64" - - "F64" + "ValueType" string Unused and deprecated. This should no longer + be emitted, but is accepted for compatibility. + - .. TODO:: - How can it be determined if a - vector type, and what size - vector? "PointeeAlign" integer Alignment in bytes of pointee type for pointer type kernel argument. Must be a power @@ -2007,29 +2798,9 @@ same *vendor-name*. multi-grid synchronization is passed in the kernarg. - ".value_type" string Required Kernel argument value type. Only - present if ".value_kind" is - "by_value". For vector data - types, the value is for the - element type. Values include: - - - "struct" - - "i8" - - "u8" - - "i16" - - "u16" - - "f16" - - "i32" - - "u32" - - "f32" - - "i64" - - "u64" - - "f64" + ".value_type" string Unused and deprecated. This should no longer + be emitted, but is accepted for compatibility. - .. TODO:: - How can it be determined if a - vector type, and what size - vector? ".pointee_align" integer Alignment in bytes of pointee type for pointer type kernel argument. Must be a power @@ -2143,7 +2914,7 @@ CPU host program, or from an HSA kernel executing on a GPU. associated. 3. Space is allocated for the kernel arguments using the ROCm runtime allocator for a memory region with the kernarg property for the kernel agent that will - execute the kernel. It must be at least 16 byte aligned. + execute the kernel. It must be at least 16-byte aligned. 4. Kernel argument values are assigned to the kernel argument memory allocation. The layout is defined in the *HSA Programmer's Language Reference* [HSA]_. For AMDGPU the kernel execution directly accesses the @@ -2181,7 +2952,7 @@ Image and Samplers ~~~~~~~~~~~~~~~~~~ Image and sample handles created by the ROCm runtime are 64-bit addresses of a -hardware 32 byte V# and 48 byte S# object respectively. In order to support the +hardware 32-byte V# and 48 byte S# object respectively. In order to support the HSA ``query_sampler`` operations two extra dwords are used to store the HSA BRIG enumeration values for the queries that are not trivially deducible from the S# representation. @@ -2217,7 +2988,7 @@ that implements the kernel. Kernel Descriptor for GFX6-GFX10 ++++++++++++++++++++++++++++++++ -CP microcode requires the Kernel descriptor to be allocated on 64 byte +CP microcode requires the Kernel descriptor to be allocated on 64-byte alignment. .. table:: Kernel Descriptor for GFX6-GFX10 @@ -2372,19 +3143,19 @@ alignment. defined as the highest SGPR number explicitly referenced plus one, plus - a target-specific number + a target specific number of additional special SGPRs for VCC, FLAT_SCRATCH (GFX7+) and XNACK_MASK (GFX8+), and any additional - target-specific + target specific limitations. It does not include the 16 SGPRs added if a trap handler is enabled. - The target-specific + The target specific limitations and special SGPR layout are defined in the hardware @@ -2919,7 +3690,7 @@ SGPR register initial state is defined in CP checks that the value in the kernel dispatch packet Private Segment Byte Size is - not larger, and requests the + not larger and requests the runtime to increase the queue's scratch size if necessary. The kernel code @@ -3026,7 +3797,7 @@ SGPR register initial state is defined in must be used to set up FLAT SCRATCH for flat addressing (see - :ref:`amdgpu-amdhsa-flat-scratch`). + :ref:`amdgpu-amdhsa-kernel-prolog-flat-scratch`). ========== ========================== ====== ============================== The order of the VGPR registers is defined, but the compiler can specify which @@ -3065,19 +3836,19 @@ The setting of registers is done by GPU CP/ADC/SPI hardware as follows: 2. Work-group Id registers X, Y, Z are set by ADC which supports any combination including none. 3. Scratch Wavefront Offset is set by SPI in a per wavefront basis which is why - its value cannot included with the flat scratch init value which is per + its value cannot be included with the flat scratch init value which is per queue. 4. The VGPRs are set by SPI which only supports specifying either (X), (X, Y) or (X, Y, Z). -Flat Scratch register pair are adjacent SGRRs so they can be moved as a 64-bit +Flat Scratch register pair are adjacent SGPRs so they can be moved as a 64-bit value to the hardware required SGPRn-3 and SGPRn-4 respectively. The global segment can be accessed either using buffer instructions (GFX6 which has V# 64-bit address support), flat instructions (GFX7-GFX10), or global instructions (GFX9-GFX10). -If buffer operations are used then the compiler can generate a V# with the +If buffer operations are used, then the compiler can generate a V# with the following properties: * base address of 0 @@ -3092,7 +3863,25 @@ following properties: Kernel Prolog ~~~~~~~~~~~~~ -.. _amdgpu-amdhsa-m0: +The compiler performs initialization in the kernel prologue depending on the +target and information about things like stack usage in the kernel and called +functions. Some of this initialization requires the compiler to request certain +User and System SGPRs be present in the +:ref:`amdgpu-amdhsa-initial-kernel-execution-state` via the +:ref:`amdgpu-amdhsa-kernel-descriptor`. + +.. _amdgpu-amdhsa-kernel-prolog-cfi: + +CFI ++++ + +1. The CFI return address is undefined. + +2. The CFI CFA is defined using an expression which evaluates to a location + description that comprises one memory location description for the + ``DW_ASPACE_AMDGPU_private_lane`` address space address ``0``. + +.. _amdgpu-amdhsa-kernel-prolog-m0: M0 ++ @@ -3107,15 +3896,35 @@ GFX9-GFX10 The M0 register is not used for range checking LDS accesses and so does not need to be initialized in the prolog. -.. _amdgpu-amdhsa-flat-scratch: +.. _amdgpu-amdhsa-kernel-prolog-stack-pointer: + +Stack Pointer ++++++++++++++ + +If the kernel has function calls it must set up the ABI stack pointer described +in :ref:`amdgpu-amdhsa-function-call-convention-non-kernel-functions` by setting +SGPR32 to the unswizzled scratch offset of the address past the last local +allocation. + +.. _amdgpu-amdhsa-kernel-prolog-frame-pointer: + +Frame Pointer ++++++++++++++ + +If the kernel needs a frame pointer for the reasons defined in +``SIFrameLowering`` then SGPR33 is used and is always set to ``0`` in the +kernel prolog. If a frame pointer is not required then all uses of the frame +pointer are replaced with immediate ``0`` offsets. + +.. _amdgpu-amdhsa-kernel-prolog-flat-scratch: Flat Scratch ++++++++++++ -If the kernel may use flat operations to access scratch memory, the prolog code -must set up FLAT_SCRATCH register pair (FLAT_SCRATCH_LO/FLAT_SCRATCH_HI which -are in SGPRn-4/SGPRn-3). Initialization uses Flat Scratch Init and Scratch -Wavefront Offset SGPR registers (see +If the kernel or any function it calls may use flat operations to access +scratch memory, the prolog code must set up the FLAT_SCRATCH register pair +(FLAT_SCRATCH_LO/FLAT_SCRATCH_HI which are in SGPRn-4/SGPRn-3). Initialization +uses Flat Scratch Init and Scratch Wavefront Offset SGPR registers (see :ref:`amdgpu-amdhsa-initial-kernel-execution-state`): GFX6 @@ -3146,6 +3955,52 @@ GFX9-GFX10 FLAT_SCRATCH pair for use as the flat scratch base in flat memory instructions. +.. _amdgpu-amdhsa-kernel-prolog-private-segment-buffer: + +Private Segment Buffer +++++++++++++++++++++++ + +A set of four SGPRs beginning at a four-aligned SGPR index are always selected +to serve as the scratch V# for the kernel as follows: + + - If it is known during instruction selection that there is stack usage, + SGPR0-3 is reserved for use as the scratch V#. Stack usage is assumed if + optimizations are disabled (``-O0``), if stack objects already exist (for + locals, etc.), or if there are any function calls. + + - Otherwise, four high numbered SGPRs beginning at a four-aligned SGPR index + are reserved for the tentative scratch V#. These will be used if it is + determined that spilling is needed. + + - If no use is made of the tentative scratch V#, then it is unreserved, + and the register count is determined ignoring it. + - If use is made of the tentative scratch V#, then its register numbers + are shifted to the first four-aligned SGPR index after the highest one + allocated by the register allocator, and all uses are updated. The + register count includes them in the shifted location. + - In either case, if the processor has the SGPR allocation bug, the + tentative allocation is not shifted or unreserved in order to ensure + the register count is higher to workaround the bug. + + .. note:: + + This approach of using a tentative scratch V# and shifting the register + numbers if used avoids having to perform register allocation a second + time if the tentative V# is eliminated. This is more efficient and + avoids the problem that the second register allocation may perform + spilling which will fail as there is no longer a scratch V#. + +When the kernel prolog code is being emitted it is known whether the scratch V# +described above is actually used. If it is, the prolog code must set it up by +copying the Private Segment Buffer to the scratch V# registers and then adding +the Private Segment Wavefront Offset to the queue base address in the V#. The +result is a V# with a base address pointing to the beginning of the wavefront +scratch backing memory. + +The Private Segment Buffer is always requested, but the Private Segment +Wavefront Offset is only requested if it is used (see +:ref:`amdgpu-amdhsa-initial-kernel-execution-state`). + .. _amdgpu-amdhsa-memory-model: Memory Model @@ -3317,13 +4172,13 @@ For GFX10: Private address space uses ``buffer_load/store`` using the scratch V# (GFX6-GFX8), or ``scratch_load/store`` (GFX9-GFX10). Since only a single thread -is accessing the memory, atomic memory orderings are not meaningful and all +is accessing the memory, atomic memory orderings are not meaningful, and all accesses are treated as non-atomic. Constant address space uses ``buffer/global_load`` instructions (or equivalent scalar memory instructions). Since the constant address space contents do not change during the execution of a kernel dispatch it is not legal to perform -stores, and atomic memory orderings are not meaningful and all access are +stores, and atomic memory orderings are not meaningful, and all access are treated as non-atomic. A memory synchronization scope wider than work-group is not meaningful for the @@ -3344,7 +4199,7 @@ instructions and is treated as acquire and release respectively. AMDGPU backend only uses scalar memory operations to access memory that is proven to not change during the execution of the kernel dispatch. This includes constant address space and global address space for program scope const -variables. Therefore the kernel machine code does not have to maintain the +variables. Therefore, the kernel machine code does not have to maintain the scalar L1 cache to ensure it is coherent with the vector L1 cache. The scalar and vector L1 caches are invalidated between kernel dispatches by CP since constant address space data may change between kernel dispatch executions. See @@ -5573,6 +6428,409 @@ the ``s_trap`` instruction with the following usage: reserved ``s_trap 0xff`` Reserved. =================== =============== =============== ======================= +.. _amdgpu-amdhsa-function-call-convention: + +Call Convention +~~~~~~~~~~~~~~~ + +.. note:: + + This section is currently incomplete and has inakkuracies. It is WIP that will + be updated as information is determined. + +See :ref:`amdgpu-dwarf-address-space-identifier` for information on swizzled +addresses. Unswizzled addresses are normal linear addresses. + +.. _amdgpu-amdhsa-function-call-convention-kernel-functions: + +Kernel Functions +++++++++++++++++ + +This section describes the call convention ABI for the outer kernel function. + +See :ref:`amdgpu-amdhsa-initial-kernel-execution-state` for the kernel call +convention. + +The following is not part of the AMDGPU kernel calling convention but describes +how the AMDGPU implements function calls: + +1. Clang decides the kernarg layout to match the *HSA Programmer's Language + Reference* [HSA]_. + + - All structs are passed directly. + - Lambda values are passed *TBA*. + + .. TODO:: + + - Does this really follow HSA rules? Or are structs >16 bytes passed + by-value struct? + - What is ABI for lambda values? + +4. The kernel performs certain setup in its prolog, as described in + :ref:`amdgpu-amdhsa-kernel-prolog`. + +.. _amdgpu-amdhsa-function-call-convention-non-kernel-functions: + +Non-Kernel Functions +++++++++++++++++++++ + +This section describes the call convention ABI for functions other than the +outer kernel function. + +If a kernel has function calls then scratch is always allocated and used for +the call stack which grows from low address to high address using the swizzled +scratch address space. + +On entry to a function: + +1. SGPR0-3 contain a V# with the following properties (see + :ref:`amdgpu-amdhsa-kernel-prolog-private-segment-buffer`): + + * Base address pointing to the beginning of the wavefront scratch backing + memory. + * Swizzled with dword element size and stride of wavefront size elements. + +2. The FLAT_SCRATCH register pair is setup. See + :ref:`amdgpu-amdhsa-kernel-prolog-flat-scratch`. +3. GFX6-8: M0 register set to the size of LDS in bytes. See + :ref:`amdgpu-amdhsa-kernel-prolog-m0`. +4. The EXEC register is set to the lanes active on entry to the function. +5. MODE register: *TBD* +6. VGPR0-31 and SGPR4-29 are used to pass function input arguments as described + below. +7. SGPR30-31 return address (RA). The code address that the function must + return to when it completes. The value is undefined if the function is *no + return*. +8. SGPR32 is used for the stack pointer (SP). It is an unswizzled scratch + offset relative to the beginning of the wavefront scratch backing memory. + + The unswizzled SP can be used with buffer instructions as an unswizzled SGPR + offset with the scratch V# in SGPR0-3 to access the stack in a swizzled + manner. + + The unswizzled SP value can be converted into the swizzled SP value by: + + | swizzled SP = unswizzled SP / wavefront size + + This may be used to obtain the private address space address of stack + objects and to convert this address to a flat address by adding the flat + scratch aperture base address. + + The swizzled SP value is always 4 bytes aligned for the ``r600`` + architecture and 16 byte aligned for the ``amdgcn`` architecture. + + .. note:: + + The ``amdgcn`` value is selected to avoid dynamic stack alignment for the + OpenCL language which has the largest base type defined as 16 bytes. + + On entry, the swizzled SP value is the address of the first function + argument passed on the stack. Other stack passed arguments are positive + offsets from the entry swizzled SP value. + + The function may use positive offsets beyond the last stack passed argument + for stack allocated local variables and register spill slots. If necessary, + the function may align these to greater alignment than 16 bytes. After these + the function may dynamically allocate space for such things as runtime sized + ``alloca`` local allocations. + + If the function calls another function, it will place any stack allocated + arguments after the last local allocation and adjust SGPR32 to the address + after the last local allocation. + +9. All other registers are unspecified. +10. Any necessary ``waitcnt`` has been performed to ensure memory is available + to the function. + +On exit from a function: + +1. VGPR0-31 and SGPR4-29 are used to pass function result arguments as + described below. Any registers used are considered clobbered registers. +2. The following registers are preserved and have the same value as on entry: + + * FLAT_SCRATCH + * EXEC + * GFX6-8: M0 + * All SGPR registers except the clobbered registers of SGPR4-31. + * VGPR40-47 + VGPR56-63 + VGPR72-79 + VGPR88-95 + VGPR104-111 + VGPR120-127 + VGPR136-143 + VGPR152-159 + VGPR168-175 + VGPR184-191 + VGPR200-207 + VGPR216-223 + VGPR232-239 + VGPR248-255 + + *Except the argument registers, the VGPR cloberred and the preserved + registers are intermixed at regular intervals in order to + get a better occupancy.* + + For the AMDGPU backend, an inter-procedural register allocation (IPRA) + optimization may mark some of clobbered SGPR and VGPR registers as + preserved if it can be determined that the called function does not change + their value. + +2. The PC is set to the RA provided on entry. +3. MODE register: *TBD*. +4. All other registers are clobbered. +5. Any necessary ``waitcnt`` has been performed to ensure memory accessed by + function is available to the caller. + +.. TODO:: + + - On gfx908 are all ACC registers clobbered? + + - How are function results returned? The address of structured types is passed + by reference, but what about other types? + +The function input arguments are made up of the formal arguments explicitly +declared by the source language function plus the implicit input arguments used +by the implementation. + +The source language input arguments are: + +1. Any source language implicit ``this`` or ``self`` argument comes first as a + pointer type. +2. Followed by the function formal arguments in left to right source order. + +The source language result arguments are: + +1. The function result argument. + +The source language input or result struct type arguments that are less than or +equal to 16 bytes, are decomposed recursively into their base type fields, and +each field is passed as if a separate argument. For input arguments, if the +called function requires the struct to be in memory, for example because its +address is taken, then the function body is responsible for allocating a stack +location and copying the field arguments into it. Clang terms this *direct +struct*. + +The source language input struct type arguments that are greater than 16 bytes, +are passed by reference. The caller is responsible for allocating a stack +location to make a copy of the struct value and pass the address as the input +argument. The called function is responsible to perform the dereference when +accessing the input argument. Clang terms this *by-value struct*. + +A source language result struct type argument that is greater than 16 bytes, is +returned by reference. The caller is responsible for allocating a stack location +to hold the result value and passes the address as the last input argument +(before the implicit input arguments). In this case there are no result +arguments. The called function is responsible to perform the dereference when +storing the result value. Clang terms this *structured return (sret)*. + +*TODO: correct the ``sret`` definition.* + +.. TODO:: + + Is this definition correct? Or is ``sret`` only used if passing in registers, and + pass as non-decomposed struct as stack argument? Or something else? Is the + memory location in the caller stack frame, or a stack memory argument and so + no address is passed as the caller can directly write to the argument stack + location? But then the stack location is still live after return. If an + argument stack location is it the first stack argument or the last one? + +Lambda argument types are treated as struct types with an implementation defined +set of fields. + +.. TODO:: + + Need to specify the ABI for lambda types for AMDGPU. + +For AMDGPU backend all source language arguments (including the decomposed +struct type arguments) are passed in VGPRs unless marked ``inreg`` in which case +they are passed in SGPRs. + +The AMDGPU backend walks the function call graph from the leaves to determine +which implicit input arguments are used, propagating to each caller of the +function. The used implicit arguments are appended to the function arguments +after the source language arguments in the following order: + +.. TODO:: + + Is recursion or external functions supported? + +1. Work-Item ID (1 VGPR) + + The X, Y and Z work-item ID are packed into a single VGRP with the following + layout. Only fields actually used by the function are set. The other bits + are undefined. + + The values come from the initial kernel execution state. See + :ref:`amdgpu-amdhsa-vgpr-register-set-up-order-table`. + + .. table:: Work-item implicit argument layout + :name: amdgpu-amdhsa-workitem-implicit-argument-layout-table + + ======= ======= ============== + Bits Size Field Name + ======= ======= ============== + 9:0 10 bits X Work-Item ID + 19:10 10 bits Y Work-Item ID + 29:20 10 bits Z Work-Item ID + 31:30 2 bits Unused + ======= ======= ============== + +2. Dispatch Ptr (2 SGPRs) + + The value comes from the initial kernel execution state. See + :ref:`amdgpu-amdhsa-sgpr-register-set-up-order-table`. + +3. Queue Ptr (2 SGPRs) + + The value comes from the initial kernel execution state. See + :ref:`amdgpu-amdhsa-sgpr-register-set-up-order-table`. + +4. Kernarg Segment Ptr (2 SGPRs) + + The value comes from the initial kernel execution state. See + :ref:`amdgpu-amdhsa-sgpr-register-set-up-order-table`. + +5. Dispatch id (2 SGPRs) + + The value comes from the initial kernel execution state. See + :ref:`amdgpu-amdhsa-sgpr-register-set-up-order-table`. + +6. Work-Group ID X (1 SGPR) + + The value comes from the initial kernel execution state. See + :ref:`amdgpu-amdhsa-sgpr-register-set-up-order-table`. + +7. Work-Group ID Y (1 SGPR) + + The value comes from the initial kernel execution state. See + :ref:`amdgpu-amdhsa-sgpr-register-set-up-order-table`. + +8. Work-Group ID Z (1 SGPR) + + The value comes from the initial kernel execution state. See + :ref:`amdgpu-amdhsa-sgpr-register-set-up-order-table`. + +9. Implicit Argument Ptr (2 SGPRs) + + The value is computed by adding an offset to Kernarg Segment Ptr to get the + global address space pointer to the first kernarg implicit argument. + +The input and result arguments are assigned in order in the following manner: + +.. note:: + + There are likely some errors and omissions in the following description that + need correction. + + .. TODO:: + + Check the clang source code to decipher how function arguments and return + results are handled. Also see the AMDGPU specific values used. + +* VGPR arguments are assigned to consecutive VGPRs starting at VGPR0 up to + VGPR31. + + If there are more arguments than will fit in these registers, the remaining + arguments are allocated on the stack in order on naturally aligned + addresses. + + .. TODO:: + + How are overly aligned structures allocated on the stack? + +* SGPR arguments are assigned to consecutive SGPRs starting at SGPR0 up to + SGPR29. + + If there are more arguments than will fit in these registers, the remaining + arguments are allocated on the stack in order on naturally aligned + addresses. + +Note that decomposed struct type arguments may have some fields passed in +registers and some in memory. + +.. TODO:: + + So, a struct which can pass some fields as decomposed register arguments, will + pass the rest as decomposed stack elements? But an argument that will not start + in registers will not be decomposed and will be passed as a non-decomposed + stack value? + +The following is not part of the AMDGPU function calling convention but +describes how the AMDGPU implements function calls: + +1. SGPR33 is used as a frame pointer (FP) if necessary. Like the SP it is an + unswizzled scratch address. It is only needed if runtime sized ``alloca`` + are used, or for the reasons defined in ``SIFrameLowering``. +2. Runtime stack alignment is supported. SGPR34 is used as a base pointer (BP) + to access the incoming stack arguments in the function. The BP is needed + only when the function requires the runtime stack alignment. + +3. Allocating SGPR arguments on the stack are not supported. + +4. No CFI is currently generated. See + :ref:`amdgpu-dwarf-call-frame-information`. + + .. note:: + + CFI will be generated that defines the CFA as the unswizzled address + relative to the wave scratch base in the unswizzled private address space + of the lowest address stack allocated local variable. + + ``DW_AT_frame_base`` will be defined as the swizzled address in the + swizzled private address space by dividing the CFA by the wavefront size + (since CFA is always at least dword aligned which matches the scratch + swizzle element size). + + If no dynamic stack alignment was performed, the stack allocated arguments + are accessed as negative offsets relative to ``DW_AT_frame_base``, and the + local variables and register spill slots are accessed as positive offsets + relative to ``DW_AT_frame_base``. + +5. Function argument passing is implemented by copying the input physical + registers to virtual registers on entry. The register allocator can spill if + necessary. These are copied back to physical registers at call sites. The + net effect is that each function call can have these values in entirely + distinct locations. The IPRA can help avoid shuffling argument registers. +6. Call sites are implemented by setting up the arguments at positive offsets + from SP. Then SP is incremented to account for the known frame size before + the call and decremented after the call. + + .. note:: + + The CFI will reflect the changed calculation needed to compute the CFA + from SP. + +7. 4 byte spill slots are used in the stack frame. One slot is allocated for an + emergency spill slot. Buffer instructions are used for stack accesses and + not the ``flat_scratch`` instruction. + + .. TODO:: + + Explain when the emergency spill slot is used. + +.. TODO:: + + Possible broken issues: + + - Stack arguments must be aligned to required alignment. + - Stack is aligned to max(16, max formal argument alignment) + - Direct argument < 64 bits should check register budget. + - Register budget calculation should respect ``inreg`` for SGPR. + - SGPR overflow is not handled. + - struct with 1 member unpeeling is not checking size of member. + - ``sret`` is after ``this`` pointer. + - Caller is not implementing stack realignment: need an extra pointer. + - Should say AMDGPU passes FP rather than SP. + - Should CFI define CFA as address of locals or arguments. Difference is + apparent when have implemented dynamic alignment. + - If ``SCRATCH`` instruction could allow negative offsets, then can make FP be + highest address of stack frame and use negative offset for locals. Would + allow SP to be the same as FP and could support signal-handler-like as now + have a real SP for the top of the stack. + - How is ``sret`` passed on the stack? In argument stack area? Can it overlay + arguments? + AMDPAL ------ @@ -5594,7 +6852,7 @@ passed from the application/runtime to a hardware shader. Compute User Data ~~~~~~~~~~~~~~~~~ -Compute shader user data mappings are simpler than graphics shaders, and have a +Compute shader user data mappings are simpler than graphics shaders and have a fixed mapping. Note that there are always 10 available *user data entries* in registers - @@ -5775,22 +7033,6 @@ This section describes general syntax for instructions and operands. Instructions ~~~~~~~~~~~~ -.. toctree:: - :hidden: - - AMDGPU/AMDGPUAsmGFX7 - AMDGPU/AMDGPUAsmGFX8 - AMDGPU/AMDGPUAsmGFX9 - AMDGPU/AMDGPUAsmGFX900 - AMDGPU/AMDGPUAsmGFX904 - AMDGPU/AMDGPUAsmGFX906 - AMDGPU/AMDGPUAsmGFX908 - AMDGPU/AMDGPUAsmGFX10 - AMDGPUModifierSyntax - AMDGPUOperandSyntax - AMDGPUInstructionSyntax - AMDGPUInstructionNotation - An instruction has the following :doc:`syntax`: | ``<``\ *opcode*\ ``> <``\ *operand0*\ ``>, <``\ *operand1*\ ``>,... @@ -5806,27 +7048,27 @@ Links to detailed instruction syntax description may be found in the following table. Note that features under development are not included in this description. - ==================================== ====================================== - Core ISA ISA Extensions - ==================================== ====================================== - :doc:`GFX7` \- - :doc:`GFX8` \- - :doc:`GFX9` :doc:`gfx900` + =================================== ======================================= + Core ISA ISA Extensions + =================================== ======================================= + :doc:`GFX7` \- + :doc:`GFX8` \- + :doc:`GFX9` :doc:`gfx900` - :doc:`gfx902` + :doc:`gfx902` - :doc:`gfx904` + :doc:`gfx904` - :doc:`gfx906` + :doc:`gfx906` - :doc:`gfx908` + :doc:`gfx908` - :doc:`gfx909` + :doc:`gfx909` - :doc:`GFX10` gfx1011 + :doc:`GFX10` :doc:`gfx1011` - gfx1012 - ==================================== ====================================== + :doc:`gfx1012` + =================================== ======================================= For more information about instructions, their semantics and supported combinations of operands, refer to one of instruction set architecture manuals @@ -6558,22 +7800,23 @@ effort required to accurately calculate GPR usage. Additional Documentation ======================== -.. [AMD-RADEON-HD-2000-3000] `AMD R6xx shader ISA `__ -.. [AMD-RADEON-HD-4000] `AMD R7xx shader ISA `__ -.. [AMD-RADEON-HD-5000] `AMD Evergreen shader ISA `__ -.. [AMD-RADEON-HD-6000] `AMD Cayman/Trinity shader ISA `__ .. [AMD-GCN-GFX6] `AMD Southern Islands Series ISA `__ .. [AMD-GCN-GFX7] `AMD Sea Islands Series ISA `_ .. [AMD-GCN-GFX8] `AMD GCN3 Instruction Set Architecture `__ .. [AMD-GCN-GFX9] `AMD "Vega" Instruction Set Architecture `__ .. [AMD-GCN-GFX10] `AMD "RDNA 1.0" Instruction Set Architecture `__ -.. [AMD-ROCm] `ROCm: Open Platform for Development, Discovery and Education Around GPU Computing `__ +.. [AMD-RADEON-HD-2000-3000] `AMD R6xx shader ISA `__ +.. [AMD-RADEON-HD-4000] `AMD R7xx shader ISA `__ +.. [AMD-RADEON-HD-5000] `AMD Evergreen shader ISA `__ +.. [AMD-RADEON-HD-6000] `AMD Cayman/Trinity shader ISA `__ +.. [AMD-ROCm] `AMD ROCm Platform `__ .. [AMD-ROCm-github] `ROCm github `__ -.. [HSA] `Heterogeneous System Architecture (HSA) Foundation `__ -.. [ELF] `Executable and Linkable Format (ELF) `__ +.. [CLANG-ATTR] `Attributes in Clang `__ .. [DWARF] `DWARF Debugging Information Format `__ -.. [YAML] `YAML Ain't Markup Language (YAML™) Version 1.2 `__ +.. [ELF] `Executable and Linkable Format (ELF) `__ +.. [HRF] `Heterogeneous-race-free Memory Models `__ +.. [HSA] `Heterogeneous System Architecture (HSA) Foundation `__ .. [MsgPack] `Message Pack `__ .. [OpenCL] `The OpenCL Specification Version 2.0 `__ -.. [HRF] `Heterogeneous-race-free Memory Models `__ -.. [CLANG-ATTR] `Attributes in Clang `__ +.. [SEMVER] `Semantic Versioning `__ +.. [YAML] `YAML Ain't Markup Language (YAML™) Version 1.2 `__ diff --git a/gnu/llvm/llvm/docs/AliasAnalysis.rst b/gnu/llvm/llvm/docs/AliasAnalysis.rst index 14decfeca6e..191addca79e 100644 --- a/gnu/llvm/llvm/docs/AliasAnalysis.rst +++ b/gnu/llvm/llvm/docs/AliasAnalysis.rst @@ -19,7 +19,7 @@ indicating that two pointers always point to the same object, might point to the same object, or are known to never point to the same object. The LLVM `AliasAnalysis -`__ class is the +`__ class is the primary interface used by clients and implementations of alias analyses in the LLVM system. This class is the common interface between clients of alias analysis information and the implementations providing it, and is designed to @@ -36,7 +36,7 @@ points about what exactly results mean. ``AliasAnalysis`` Class Overview ================================ -The `AliasAnalysis `__ +The `AliasAnalysis `__ class defines the interface that the various alias analysis implementations should support. This class exports two important enums: ``AliasResult`` and ``ModRefResult`` which represent the result of an alias query or a mod/ref @@ -77,7 +77,7 @@ possible) C code: C[1] = A[9-i]; /* One byte store */ } -In this case, the ``basicaa`` pass will disambiguate the stores to ``C[0]`` and +In this case, the ``basic-aa`` pass will disambiguate the stores to ``C[0]`` and ``C[1]`` because they are accesses to two distinct locations one byte apart, and the accesses are each one byte. In this case, the Loop Invariant Code Motion (LICM) pass can use store motion to remove the stores from the loop. In @@ -264,7 +264,7 @@ Interfaces which may be specified --------------------------------- All of the `AliasAnalysis -`__ virtual methods +`__ virtual methods default to providing :ref:`chaining ` to another alias analysis implementation, which ends up returning conservatively correct information (returning "May" Alias and "Mod/Ref" for alias and mod/ref queries @@ -278,7 +278,7 @@ implementing, you just override the interfaces you can improve. With only one special exception (the :ref:`-no-aa ` pass) every alias analysis pass chains to another alias analysis implementation (for -example, the user can specify "``-basicaa -ds-aa -licm``" to get the maximum +example, the user can specify "``-basic-aa -ds-aa -licm``" to get the maximum benefit from both alias analyses). The alias analysis class automatically takes care of most of this for methods that you don't override. For methods that you do override, in code paths that return a conservative MayAlias or @@ -435,7 +435,7 @@ Using the ``AliasSetTracker`` class Many transformations need information about alias **sets** that are active in some scope, rather than information about pairwise aliasing. The -`AliasSetTracker `__ +`AliasSetTracker `__ class is used to efficiently build these Alias Sets from the pairwise alias analysis information provided by the ``AliasAnalysis`` interface. @@ -515,10 +515,10 @@ The ``-no-aa`` pass is just like what it sounds: an alias analysis that never returns any useful information. This pass can be useful if you think that alias analysis is doing something wrong and are trying to narrow down a problem. -The ``-basicaa`` pass -^^^^^^^^^^^^^^^^^^^^^ +The ``-basic-aa`` pass +^^^^^^^^^^^^^^^^^^^^^^ -The ``-basicaa`` pass is an aggressive local analysis that *knows* many +The ``-basic-aa`` pass is an aggressive local analysis that *knows* many important facts: * Distinct globals, stack allocations, and heap allocations can never alias. diff --git a/gnu/llvm/llvm/docs/Atomics.rst b/gnu/llvm/llvm/docs/Atomics.rst index 00f29c285b3..7d57740ded7 100644 --- a/gnu/llvm/llvm/docs/Atomics.rst +++ b/gnu/llvm/llvm/docs/Atomics.rst @@ -562,7 +562,7 @@ various reasons, it is not practical to emit the instructions inline. There's two typical examples of this. -Some CPUs support multiple instruction sets which can be swiched back and forth +Some CPUs support multiple instruction sets which can be switched back and forth on function-call boundaries. For example, MIPS supports the MIPS16 ISA, which has a smaller instruction encoding than the usual MIPS32 ISA. ARM, similarly, has the Thumb ISA. In MIPS16 and earlier versions of Thumb, the atomic diff --git a/gnu/llvm/llvm/docs/BigEndianNEON.rst b/gnu/llvm/llvm/docs/BigEndianNEON.rst index 242eb0e73d2..aa564c14dee 100644 --- a/gnu/llvm/llvm/docs/BigEndianNEON.rst +++ b/gnu/llvm/llvm/docs/BigEndianNEON.rst @@ -12,7 +12,7 @@ Generating code for big endian ARM processors is for the most part straightforwa The aim of this document is to explain the problem with NEON loads and stores, and the solution that has been implemented in LLVM. -In this document the term "vector" refers to what the ARM ABI calls a "short vector", which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is sligtly different to A64. Apart from that, the same concepts apply. +In this document the term "vector" refers to what the ARM ABI calls a "short vector", which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is slightly different to A64. Apart from that, the same concepts apply. Example: C-level intrinsics -> assembly --------------------------------------- diff --git a/gnu/llvm/llvm/docs/BitCodeFormat.rst b/gnu/llvm/llvm/docs/BitCodeFormat.rst index dce84620fd7..6e491c6e285 100644 --- a/gnu/llvm/llvm/docs/BitCodeFormat.rst +++ b/gnu/llvm/llvm/docs/BitCodeFormat.rst @@ -1058,7 +1058,16 @@ The integer codes are mapped to well-known attributes as follows. * code 56: ``nocf_check`` * code 57: ``optforfuzzing`` * code 58: ``shadowcallstack`` +* code 59: ``speculative_load_hardening`` +* code 60: ``immarg`` +* code 61: ``willreturn`` +* code 62: ``nofree`` +* code 63: ``nosync`` * code 64: ``sanitize_memtag`` +* code 65: ``preallocated`` +* code 66: ``no_merge`` +* code 67: ``null_pointer_is_valid`` +* code 68: ``noundef`` .. note:: The ``allocsize`` attribute has a special encoding for its arguments. Its two @@ -1107,6 +1116,14 @@ TYPE_CODE_HALF Record The ``HALF`` record (code 10) adds a ``half`` (16-bit floating point) type to the type table. +TYPE_CODE_BFLOAT Record +^^^^^^^^^^^^^^^^^^^^^^^ + +``[BFLOAT]`` + +The ``BFLOAT`` record (code 23) adds a ``bfloat`` (16-bit brain floating point) +type to the type table. + TYPE_CODE_FLOAT Record ^^^^^^^^^^^^^^^^^^^^^^ diff --git a/gnu/llvm/llvm/docs/BlockFrequencyTerminology.rst b/gnu/llvm/llvm/docs/BlockFrequencyTerminology.rst index 41f89f8ce96..a424be2aa7f 100644 --- a/gnu/llvm/llvm/docs/BlockFrequencyTerminology.rst +++ b/gnu/llvm/llvm/docs/BlockFrequencyTerminology.rst @@ -82,7 +82,7 @@ by a cut edge should equal ``UINT64_MAX``. In other words, mass is conserved as it "falls" through the DAG. If a function's basic block graph is a DAG, then block masses are valid block -frequencies. This works poorly in practise though, since downstream users rely +frequencies. This works poorly in practice though, since downstream users rely on adding block frequencies together without hitting the maximum. Loop Scale diff --git a/gnu/llvm/llvm/docs/BranchWeightMetadata.rst b/gnu/llvm/llvm/docs/BranchWeightMetadata.rst index e09587179ec..902ba87316e 100644 --- a/gnu/llvm/llvm/docs/BranchWeightMetadata.rst +++ b/gnu/llvm/llvm/docs/BranchWeightMetadata.rst @@ -15,7 +15,7 @@ The first operator is always a ``MDString`` node with the string "branch_weights". Number of operators depends on the terminator type. Branch weights might be fetch from the profiling file, or generated based on -`__builtin_expect`_ instruction. +`__builtin_expect`_ and `__builtin_expect_with_probability`_ instruction. All weights are represented as an unsigned 32-bit values, where higher value indicates greater chance to be taken. @@ -78,6 +78,27 @@ block and entry counts which may not be accurate with sampling. i32 } +``InvokeInst`` +^^^^^^^^^^^^^^^^^^ + +Invoke instruction may have branch weight metadata with one or two weights. +The second weight is optional and corresponds to the unwind branch. +If only one weight is set then it contains the execution count of the call +and used in SamplePGO mode only as described for the call instruction. If both +weights are specified then the second weight contains count of unwind branch +taken and the first weights contains the execution count of the call minus +the count of unwind branch taken. Both weights specified are used to calculate +BranchProbability as for BranchInst and for SamplePGO the sum of both weights +is used. + +.. code-block:: none + + !0 = metadata !{ + metadata !"branch_weights", + i32 + [ , i32 ] + } + Other ^^^^^ @@ -123,6 +144,47 @@ case is assumed to be likely taken. case 5: // This case is likely to be taken. } +.. _\__builtin_expect_with_probability: + +Built-in ``expect.with.probability`` Instruction +================================================ + +``__builtin_expect_with_probability(long exp, long c, double probability)`` has +the same semantics as ``__builtin_expect``, but the caller provides the +probability that ``exp == c``. The last argument ``probability`` must be +constant floating-point expression and be in the range [0.0, 1.0] inclusive. +The usage is also similar as ``__builtin_expect``, for example: + +``if`` statement +^^^^^^^^^^^^^^^^ + +If the expect comparison value ``c`` is equal to 1(true), and probability +value ``probability`` is set to 0.8, that means the probability of condition +to be true is 80% while that of false is 20%. + +.. code-block:: c++ + + if (__builtin_expect_with_probability(x > 0, 1, 0.8)) { + // This block is likely to be taken with probability 80%. + } + +``switch`` statement +^^^^^^^^^^^^^^^^^^^^ + +This is basically the same as ``switch`` statement in ``__builtin_expect``. +The probability that ``exp`` is equal to the expect value is given in +the third argument ``probability``, while the probability of other value is +the average of remaining probability(``1.0 - probability``). For example: + +.. code-block:: c++ + + switch (__builtin_expect_with_probability(x, 5, 0.7)) { + default: break; // Take this case with probability 10% + case 0: break; // Take this case with probability 10% + case 3: break; // Take this case with probability 10% + case 5: break; // This case is likely to be taken with probability 70% + } + CFG Modifications ================= diff --git a/gnu/llvm/llvm/docs/Bugpoint.rst b/gnu/llvm/llvm/docs/Bugpoint.rst index 19efaf2bdee..2dd504520d5 100644 --- a/gnu/llvm/llvm/docs/Bugpoint.rst +++ b/gnu/llvm/llvm/docs/Bugpoint.rst @@ -121,7 +121,7 @@ non-obvious ways. Here are some hints and tips: miscompilation. Programs should be temporarily modified to disable outputs that are likely to vary from run to run. -* In the `crash debugger`_, ``bugpoint`` does not distiguish different crashes +* In the `crash debugger`_, ``bugpoint`` does not distinguish different crashes during reduction. Thus, if new crash or miscompilation happens, ``bugpoint`` will continue with the new crash instead. If you would like to stick to particular crash, you should write check scripts to validate the error diff --git a/gnu/llvm/llvm/docs/BuildingADistribution.rst b/gnu/llvm/llvm/docs/BuildingADistribution.rst index 9ad6fc2f7bc..4be86bef903 100644 --- a/gnu/llvm/llvm/docs/BuildingADistribution.rst +++ b/gnu/llvm/llvm/docs/BuildingADistribution.rst @@ -194,7 +194,6 @@ that are already documented include: *LLVM_TARGETS_TO_BUILD*, #. ``all`` - All LLVM available component libraries #. ``Native`` - The LLVM target for the Native system - #. ``AllTargetsAsmPrinters`` - All the included target ASM printers libraries #. ``AllTargetsAsmParsers`` - All the included target ASM parsers libraries #. ``AllTargetsDescs`` - All the included target descriptions libraries #. ``AllTargetsDisassemblers`` - All the included target dissassemblers libraries diff --git a/gnu/llvm/llvm/docs/CMake.rst b/gnu/llvm/llvm/docs/CMake.rst index a86ebb3a37b..1f908d3e95b 100644 --- a/gnu/llvm/llvm/docs/CMake.rst +++ b/gnu/llvm/llvm/docs/CMake.rst @@ -383,7 +383,7 @@ LLVM-specific variables This feature allows to have one build for only LLVM and another for clang+llvm using the same source checkout. The full list is: - ``clang;clang-tools-extra;compiler-rt;debuginfo-tests;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;llgo;openmp;parallel-libs;polly;pstl`` + ``clang;clang-tools-extra;compiler-rt;debuginfo-tests;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;openmp;parallel-libs;polly;pstl`` **LLVM_EXTERNAL_PROJECTS**:STRING Semicolon-separated list of additional external projects to build as part of @@ -422,7 +422,7 @@ LLVM-specific variables **LLVM_USE_SANITIZER**:STRING Define the sanitizer used to build LLVM binaries and tests. Possible values are ``Address``, ``Memory``, ``MemoryWithOrigins``, ``Undefined``, ``Thread``, - and ``Address;Undefined``. Defaults to empty string. + ``DataFlow``, and ``Address;Undefined``. Defaults to empty string. **LLVM_ENABLE_LTO**:STRING Add ``-flto`` or ``-flto=`` flags to the compile and link command @@ -601,7 +601,7 @@ LLVM-specific variables **LLVM_BUILD_INSTRUMENTED_COVERAGE**:BOOL If enabled, `source-based code coverage - `_ instrumentation + `_ instrumentation is enabled while building llvm. **LLVM_CCACHE_BUILD**:BOOL @@ -631,6 +631,18 @@ LLVM-specific variables If enabled, the Z3 constraint solver is activated for the Clang static analyzer. A recent version of the z3 library needs to be available on the system. +**LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO**:BOOL + Rewrite absolute source paths in debug info to relative ones. The source prefix + can be adjusted via the LLVM_SOURCE_PREFIX variable. + +**LLVM_USE_RELATIVE_PATHS_IN_FILES**:BOOL + Rewrite absolute source paths in sources and debug info to relative ones. The + source prefix can be adjusted via the LLVM_SOURCE_PREFIX variable. + +**LLVM_INSTALL_UTILS**:BOOL + If enabled, utility binaries like ``FileCheck`` and ``not`` will be installed + to CMAKE_INSTALL_PREFIX. + CMake Caches ============ diff --git a/gnu/llvm/llvm/docs/CMakePrimer.rst b/gnu/llvm/llvm/docs/CMakePrimer.rst index 72ebffa5bdd..abfd08017fb 100644 --- a/gnu/llvm/llvm/docs/CMakePrimer.rst +++ b/gnu/llvm/llvm/docs/CMakePrimer.rst @@ -333,7 +333,7 @@ When defining a CMake command handling arguments is very useful. The examples in this section will all use the CMake ``function`` block, but this all applies to the ``macro`` block as well. -CMake commands can have named arguments that are requried at every call site. In +CMake commands can have named arguments that are required at every call site. In addition, all commands will implicitly accept a variable number of extra arguments (In C parlance, all commands are varargs functions). When a command is invoked with extra arguments (beyond the named ones) CMake will store the full diff --git a/gnu/llvm/llvm/docs/CodeGenerator.rst b/gnu/llvm/llvm/docs/CodeGenerator.rst index e38464a0f80..875a96ca4e2 100644 --- a/gnu/llvm/llvm/docs/CodeGenerator.rst +++ b/gnu/llvm/llvm/docs/CodeGenerator.rst @@ -1272,7 +1272,7 @@ compatible with a given physical, this code can be used: Sometimes, mostly for debugging purposes, it is useful to change the number of physical registers available in the target architecture. This must be done -statically, inside the ``TargetRegsterInfo.td`` file. Just ``grep`` for +statically, inside the ``TargetRegisterInfo.td`` file. Just ``grep`` for ``RegisterClass``, the last parameter of which is a list of registers. Just commenting some out is one simple way to avoid them being used. A more polite way is to explicitly exclude some registers from the *allocation order*. See the @@ -2418,7 +2418,7 @@ to spill registers r3-r10. This allows callees blind to the call signature, such as thunks and vararg functions, enough space to cache the argument registers. Therefore, the parameter area is minimally 32 bytes (64 bytes in 64 bit mode.) Also note that since the parameter area is a fixed offset from the -top of the frame, that a callee can access its spilt arguments using fixed +top of the frame, that a callee can access its split arguments using fixed offsets from the stack pointer (or base pointer.) Combining the information about the linkage, parameter areas and alignment. A diff --git a/gnu/llvm/llvm/docs/CodeReview.rst b/gnu/llvm/llvm/docs/CodeReview.rst new file mode 100644 index 00000000000..3350b21a983 --- /dev/null +++ b/gnu/llvm/llvm/docs/CodeReview.rst @@ -0,0 +1,237 @@ +===================================== +LLVM Code-Review Policy and Practices +===================================== + +LLVM's code-review policy and practices help maintain high code quality across +the project. Specifically, our code review process aims to: + + * Improve readability and maintainability. + * Improve robustness and prevent the introduction of defects. + * Best leverage the experience of other contributors for each proposed change. + * Help grow and develop new contributors, through mentorship by community leaders. + +It is important for all contributors to understand our code-review +practices and participate in the code-review process. + +General Policies +================ + +What Code Should Be Reviewed? +----------------------------- + +All developers are required to have significant changes reviewed before they +are committed to the repository. + +Must Code Be Reviewed Prior to Being Committed? +----------------------------------------------- + +Code can be reviewed either before it is committed or after. We expect +significant patches to be reviewed before being committed. Smaller patches +(or patches where the developer owns the component) that meet +likely-community-consensus requirements (as apply to all patch approvals) can +be committed prior to an explicit review. In situations where there is any +uncertainty, a patch should be reviewed prior to being committed. + +Please note that the developer responsible for a patch is also +responsible for making all necessary review-related changes, including +those requested during any post-commit review. + +Can Code Be Reviewed After It Is Committed? +------------------------------------------- + +Post-commit review is encouraged, and can be accomplished using any of the +tools detailed below. There is a strong expectation that authors respond +promptly to post-commit feedback and address it. Failure to do so is cause for +the patch to be reverted. + +In addition, if substantial problems are identified, it is expected that the +patch is reverted and fixed offline. Before being recommitted, the patch +generally undergoes further review, including by the community member who +identified the problem and, in cases where the patch triggered a +hardware-specific buildbot failure, a community member with access to hardware +similar to that on the buildbot that the patch previously caused to fail. + +Please note: The bar for post-commit feedback is not higher than for pre-commit +feedback. Don't delay unnecessarily in providing feedback. However, if you see +something after code has been committed about which you would have commented +pre-commit (had you noticed it earlier), please feel free to provide that +feedback at any time. + +That having been said, if a substantial period of time has passed since the +original change was committed, it may be better to create a new patch to +address the issues than comment on the original commit. The original patch +author, for example, might no longer be an active contributor to the project. + +What Tools Are Used for Code Review? +------------------------------------ + +Code reviews are conducted, in order of preference, on our web-based +code-review tool (see :doc:`Phabricator`), by email on the relevant project's +commit mailing list, on the project's development list, or on the bug tracker. + +When Is an RFC Required? +------------------------ + +Some changes are too significant for just a code review. Changes that should +change the LLVM Language Reference (e.g., adding new target-independent +intrinsics), adding language extensions in Clang, and so on, require an RFC +(Request for Comment) email on the project's ``*-dev`` mailing list first. For +changes that promise significant impact on users and/or downstream code bases, +reviewers can request an RFC achieving consensus before proceeding with code +review. That having been said, posting initial patches can help with +discussions on an RFC. + +Code-Review Workflow +==================== + +Code review can be an iterative process, which continues until the patch is +ready to be committed. Specifically, once a patch is sent out for review, it +needs an explicit approval before it is committed. Do not assume silent +approval, or solicit objections to a patch with a deadline. + +Acknowledge All Reviewer Feedback +--------------------------------- + +All comments by reviewers should be acknowledged by the patch author. It is +generally expected that suggested changes will be incorporated into a future +revision of the patch unless the author and/or other reviewers can articulate a +good reason to do otherwise (and then the reviewers must agree). If a new patch +does not address all outstanding feedback, the author should explicitly state +that when providing the updated patch. When using the web-based code-review +tool, such notes can be provided in the "Diff" description (which is different +from the description of the "Differential Revision" as a whole used for the +commit message). + +If you suggest changes in a code review, but don't wish the suggestion to be +interpreted this strongly, please state so explicitly. + +Aim to Make Efficient Use of Everyone's Time +-------------------------------------------- + +Aim to limit the number of iterations in the review process. For example, when +suggesting a change, if you want the author to make a similar set of changes at +other places in the code, please explain the requested set of changes so that +the author can make all of the changes at once. If a patch will require +multiple steps prior to approval (e.g., splitting, refactoring, posting data +from specific performance tests), please explain as many of these up front as +possible. This allows the patch author and reviewers to make the most efficient +use of their time. + +LGTM - How a Patch Is Accepted +------------------------------ + +A patch is approved to be committed when a reviewer accepts it, and this is +almost always associated with a message containing the text "LGTM" (which +stands for Looks Good To Me). Only approval from a single reviewer is required. + +When providing an unqualified LGTM (approval to commit), it is the +responsibility of the reviewer to have reviewed all of the discussion and +feedback from all reviewers ensuring that all feedback has been addressed and +that all other reviewers will almost surely be satisfied with the patch being +approved. If unsure, the reviewer should provide a qualified approval, (e.g., +"LGTM, but please wait for @someone, @someone_else"). You may also do this if +you are fairly certain that a particular community member will wish to review, +even if that person hasn't done so yet. + +Note that, if a reviewer has requested a particular community member to review, +and after a week that community member has yet to respond, feel free to ping +the patch (which literally means submitting a comment on the patch with the +word, "Ping."), or alternatively, ask the original reviewer for further +suggestions. + +If it is likely that others will want to review a recently-posted patch, +especially if there might be objections, but no one else has done so yet, it is +also polite to provide a qualified approval (e.g., "LGTM, but please wait for a +couple of days in case others wish to review"). If approval is received very +quickly, a patch author may also elect to wait before committing (and this is +certainly considered polite for non-trivial patches). Especially given the +global nature of our community, this waiting time should be at least 24 hours. +Please also be mindful of weekends and major holidays. + +Our goal is to ensure community consensus around design decisions and +significant implementation choices, and one responsibility of a reviewer, when +providing an overall approval for a patch, is to be reasonably sure that such +consensus exists. If you're not familiar enough with the community to know, +then you shouldn't be providing final approval to commit. A reviewer providing +final approval should have commit access to the LLVM project. + +Every patch should be reviewed by at least one technical expert in the areas of +the project affected by the change. + +Splitting Requests and Conditional Acceptance +--------------------------------------------- + +Reviewers may request certain aspects of a patch to be broken out into separate +patches for independent review. Reviewers may also accept a patch +conditioned on the author providing a follow-up patch addressing some +particular issue or concern (although no committed patch should leave the +project in a broken state). Moreover, reviewers can accept a patch conditioned on +the author applying some set of minor updates prior to committing, and when +applicable, it is polite for reviewers to do so. + +Don't Unintentionally Block a Review +------------------------------------ + +If you review a patch, but don't intend for the review process to block on your +approval, please state that explicitly. Out of courtesy, we generally wait on +committing a patch until all reviewers are satisfied, and if you don't intend +to look at the patch again in a timely fashion, please communicate that fact in +the review. + +Who Can/Should Review Code? +=========================== + +Non-Experts Should Review Code +------------------------------ + +You do not need to be an expert in some area of the code base to review patches; +it's fine to ask questions about what some piece of code is doing. If it's not +clear to you what is going on, you're unlikely to be the only one. Please +remember that it is not in the long-term best interest of the community to have +components that are only understood well by a small number of people. Extra +comments and/or test cases can often help (and asking for comments in the test +cases is fine as well). + +Moreover, authors are encouraged to interpret questions as a reason to reexamine +the readability of the code in question. Structural changes, or further +comments, may be appropriate. + +If you're new to the LLVM community, you might also find this presentation helpful: +.. _How to Contribute to LLVM, A 2019 LLVM Developers' Meeting Presentation: https://youtu.be/C5Y977rLqpw + +A good way for new contributors to increase their knowledge of the code base is +to review code. It is perfectly acceptable to review code and explicitly +defer to others for approval decisions. + +Experts Should Review Code +-------------------------- + +If you are an expert in an area of the compiler affected by a proposed patch, +then you are highly encouraged to review the code. If you are a relevant code +owner, and no other experts are reviewing a patch, you must either help arrange +for an expert to review the patch or review it yourself. + +Code Reviews, Speed, and Reciprocity +------------------------------------ + +Sometimes code reviews will take longer than you might hope, especially for +larger features. Common ways to speed up review times for your patches are: + +* Review other people's patches. If you help out, everybody will be more + willing to do the same for you; goodwill is our currency. +* Ping the patch. If it is urgent, provide reasons why it is important to you to + get this patch landed and ping it every couple of days. If it is + not urgent, the common courtesy ping rate is one week. Remember that you're + asking for valuable time from other professional developers. +* Ask for help on IRC. Developers on IRC will be able to either help you + directly, or tell you who might be a good reviewer. +* Split your patch into multiple smaller patches that build on each other. The + smaller your patch is, the higher the probability that somebody will take a quick + look at it. When doing this, it is helpful to add "[N/M]" (for 1 <= N <= M) to + the title of each patch in the series, so it is clear that there is an order + and what that order is. + +Developers should participate in code reviews as both reviewers and +authors. If someone is kind enough to review your code, you should return the +favor for someone else. Note that anyone is welcome to review and give feedback +on a patch, but approval of patches should be consistent with the policy above. diff --git a/gnu/llvm/llvm/docs/CodingStandards.rst b/gnu/llvm/llvm/docs/CodingStandards.rst index 0478bd27078..99fb6af02a2 100644 --- a/gnu/llvm/llvm/docs/CodingStandards.rst +++ b/gnu/llvm/llvm/docs/CodingStandards.rst @@ -70,19 +70,31 @@ Each toolchain provides a good reference for what it accepts: C++ Standard Library -------------------- -Use the C++ standard library facilities whenever they are available for -a particular task. LLVM and related projects emphasize and rely on the standard -library facilities as much as possible. - -We avoid some standard facilities, like the I/O streams, and instead use LLVM's -streams library (raw_ostream_). More detailed information on these subjects is -available in the :doc:`ProgrammersManual`. +Instead of implementing custom data structures, we encourage the use of C++ +standard library facilities or LLVM support libraries whenever they are +available for a particular task. LLVM and related projects emphasize and rely +on the standard library facilities and the LLVM support libraries as much as +possible. LLVM support libraries (for example, `ADT `_) -implement functionality missing in the standard library. Such libraries are -usually implemented in the ``llvm`` namespace and follow the expected standard -interface, when there is one. +implement specialized data structures or functionality missing in the standard +library. Such libraries are usually implemented in the ``llvm`` namespace and +follow the expected standard interface, when there is one. + +When both C++ and the LLVM support libraries provide similar functionality, and +there isn't a specific reason to favor the C++ implementation, it is generally +preferable to use the LLVM library. For example, ``llvm::DenseMap`` should +almost always be used instead of ``std::map`` or ``std::unordered_map``, and +``llvm::SmallVector`` should usually be used instead of ``std::vector``. + +We explicitly avoid some standard facilities, like the I/O streams, and instead +use LLVM's streams library (raw_ostream_). More detailed information on these +subjects is available in the :doc:`ProgrammersManual`. + +For more information about LLVM's data structures and the tradeoffs they make, +please consult [that section of the programmer's +manual](https://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task). Guidelines for Go code ---------------------- @@ -308,6 +320,46 @@ Preferred: /// Builds a B-tree in order to do foo. See paper by... void example() { ... } +Error and Warning Messages +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Clear diagnostic messages are important to help users identify and fix issues in +their inputs. Use succinct but correct English prose that gives the user the +context needed to understand what went wrong. Also, to match error message +styles commonly produced by other tools, start the first sentence with a +lower-case letter, and finish the last sentence without a period, if it would +end in one otherwise. Sentences which end with different punctuation, such as +"did you forget ';'?", should still do so. + +For example this is a good error message: + +.. code-block:: none + + error: file.o: section header 3 is corrupt. Size is 10 when it should be 20 + +This is a bad message, since it does not provide useful information and uses the +wrong style: + +.. code-block:: none + + error: file.o: Corrupt section header. + +As with other coding standards, individual projects, such as the Clang Static +Analyzer, may have preexisting styles that do not conform to this. If a +different formatting scheme is used consistently throughout the project, use +that style instead. Otherwise, this standard applies to all LLVM tools, +including clang, clang-tidy, and so on. + +If the tool or project does not have existing functions to emit warnings or +errors, use the error and warning handlers provided in ``Support/WithColor.h`` +to ensure they are printed in the appropriate style, rather than printing to +stderr directly. + +When using ``report_fatal_error``, follow the same standards for the message as +regular error messages. Assertion messages and ``llvm_unreachable`` calls do not +necessarily need to follow these same styles as they are automatically +formatted, and thus these guidelines may not be suitable. + ``#include`` Style ^^^^^^^^^^^^^^^^^^ @@ -617,15 +669,15 @@ copy. .. code-block:: c++ // Typically there's no reason to copy. - for (const auto &Val : Container) { observe(Val); } - for (auto &Val : Container) { Val.change(); } + for (const auto &Val : Container) observe(Val); + for (auto &Val : Container) Val.change(); // Remove the reference if you really want a new copy. for (auto Val : Container) { Val.change(); saveSomewhere(Val); } // Copy pointers, but make it clear that they're pointers. - for (const auto *Ptr : Container) { observe(*Ptr); } - for (auto *Ptr : Container) { Ptr->change(); } + for (const auto *Ptr : Container) observe(*Ptr); + for (auto *Ptr : Container) Ptr->change(); Beware of non-determinism due to ordering of pointers ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -647,7 +699,7 @@ Beware of non-deterministic sorting order of equal elements ``std::sort`` uses a non-stable sorting algorithm in which the order of equal elements is not guaranteed to be preserved. Thus using ``std::sort`` for a -container having equal elements may result in non-determinstic behavior. +container having equal elements may result in non-deterministic behavior. To uncover such instances of non-determinism, LLVM has introduced a new llvm::sort wrapper function. For an EXPENSIVE_CHECKS build this will randomly shuffle the container before sorting. Default to using ``llvm::sort`` instead @@ -750,6 +802,49 @@ your private interface remains private and undisturbed by outsiders. It's okay to put extra implementation methods in a public class itself. Just make them private (or protected) and all is well. +Use Namespace Qualifiers to Implement Previously Declared Functions +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When providing an out of line implementation of a function in a source file, do +not open namespace blocks in the source file. Instead, use namespace qualifiers +to help ensure that your definition matches an existing declaration. Do this: + +.. code-block:: c++ + + // Foo.h + namespace llvm { + int foo(const char *s); + } + + // Foo.cpp + #include "Foo.h" + using namespace llvm; + int llvm::foo(const char *s) { + // ... + } + +Doing this helps to avoid bugs where the definition does not match the +declaration from the header. For example, the following C++ code defines a new +overload of ``llvm::foo`` instead of providing a definition for the existing +function declared in the header: + +.. code-block:: c++ + + // Foo.cpp + #include "Foo.h" + namespace llvm { + int foo(char *s) { // Mismatch between "const char *" and "char *" + } + } // end namespace llvm + +This error will not be caught until the build is nearly complete, when the +linker fails to find a definition for any uses of the original function. If the +function were instead defined with a namespace qualifier, the error would have +been caught immediately when the definition was compiled. + +Class method implementations must already name the class and new overloads +cannot be introduced out of line, so this recommendation does not apply to them. + .. _early exits: Use Early Exits and ``continue`` to Simplify Code @@ -789,7 +884,7 @@ It is much preferred to format the code like this: .. code-block:: c++ Value *doSomething(Instruction *I) { - // Terminators never need 'something' done to them because ... + // Terminators never need 'something' done to them because ... if (I->isTerminator()) return 0; @@ -801,7 +896,7 @@ It is much preferred to format the code like this: // This is really just here for example. if (!doOtherThing(I)) return 0; - + ... some long code .... } @@ -905,7 +1000,7 @@ Or better yet (in this case) as: Type = Context.getsigjmp_bufType(); else Type = Context.getjmp_bufType(); - + if (Type.isNull()) { Error = Signed ? ASTContext::GE_Missing_sigjmp_buf : ASTContext::GE_Missing_jmp_buf; @@ -915,7 +1010,7 @@ Or better yet (in this case) as: The idea is to reduce indentation and the amount of code you have to keep track of when reading the code. - + Turn Predicate Loops into Predicate Functions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -986,7 +1081,7 @@ In general, names should be in camel case (e.g. ``TextFileReader`` and * **Variable names** should be nouns (as they represent state). The name should be camel case, and start with an upper case letter (e.g. ``Leader`` or ``Boats``). - + * **Function names** should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. ``openFile()`` or ``isFoo()``). @@ -996,7 +1091,7 @@ In general, names should be in camel case (e.g. ``TextFileReader`` and discriminator for a union, or an indicator of a subclass. When an enum is used for something like this, it should have a ``Kind`` suffix (e.g. ``ValueKind``). - + * **Enumerators** (e.g. ``enum { Foo, Bar }``) and **public member variables** should start with an upper-case letter, just like types. Unless the enumerators are defined in their own small namespace or inside a class, @@ -1012,7 +1107,7 @@ In general, names should be in camel case (e.g. ``TextFileReader`` and MaxSize = 42, Density = 12 }; - + As an exception, classes that mimic STL classes can have member names in STL's style of lower-case words separated by underscores (e.g. ``begin()``, ``push_back()``, and ``empty()``). Classes that provide multiple @@ -1098,8 +1193,14 @@ builds), ``llvm_unreachable`` becomes a hint to compilers to skip generating code for this branch. If the compiler does not support this, it will fall back to the "abort" implementation. -Neither assertions or ``llvm_unreachable`` will abort the program on a release -build. If the error condition can be triggered by user input then the +Use ``llvm_unreachable`` to mark a specific point in code that should never be +reached. This is especially desirable for addressing warnings about unreachable +branches, etc., but can be used whenever reaching a particular code path is +unconditionally a bug (not originating from user input; see below) of some kind. +Use of ``assert`` should always include a testable predicate (as opposed to +``assert(false)``). + +If the error condition can be triggered by user input then the recoverable error mechanism described in :doc:`ProgrammersManual` should be used instead. In cases where this is not practical, ``report_fatal_error`` may be used. @@ -1201,12 +1302,15 @@ loops wherever possible for all newly added code. For example: for (Instruction &I : *BB) ... use I ... +Usage of ``std::for_each()``/``llvm::for_each()`` functions is discouraged, +unless the the callable object already exists. + Don't evaluate ``end()`` every time through a loop ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In cases where range-based ``for`` loops can't be used and it is necessary to write an explicit iterator-based loop, pay close attention to whether -``end()`` is re-evaluted on each loop iteration. One common mistake is to +``end()`` is re-evaluated on each loop iteration. One common mistake is to write a loop in this style: .. code-block:: c++ @@ -1258,7 +1362,7 @@ prefer it. The use of ``#include `` in library files is hereby **forbidden**, because many common implementations transparently inject a `static constructor`_ into every translation unit that includes it. - + Note that using the other stream headers (```` for example) is not problematic in this regard --- just ````. However, ``raw_ostream`` provides various APIs that are better performing for almost every use than @@ -1390,7 +1494,7 @@ being closed by a ``}``. For example: public: explicit Grokable() { ... } virtual ~Grokable() = 0; - + ... }; @@ -1439,8 +1543,8 @@ as possible, and only use them for class declarations. For example: }; } // end anonymous namespace - static void runHelper() { - ... + static void runHelper() { + ... } bool StringSort::operator<(const char *RHS) const { @@ -1468,6 +1572,53 @@ you have no immediate way to tell if this function is local to the file. In contrast, when the function is marked static, you don't need to cross-reference faraway places in the file to tell that the function is local. +Don't Use Braces on Simple Single-Statement Bodies of if/else/loop Statements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When writing the body of an ``if``, ``else``, or loop statement, omit the braces to +avoid unnecessary line noise. However, braces should be used in cases where the +omission of braces harm the readability and maintainability of the code. + +Readability is harmed when a single statement is accompanied by a comment that loses +its meaning if hoisted above the ``if`` or loop statement. Similarly, braces should +be used when single-statement body is complex enough that it becomes difficult to see +where the block containing the following statement began. An ``if``/``else`` chain or +a loop is considered a single statement for this rule, and this rule applies recursively. +This list is not exhaustive, for example, readability is also harmed if an +``if``/``else`` chain starts using braced bodies partway through and does not continue +on with braced bodies. + +Maintainability is harmed if the body of an ``if`` ends with a (directly or indirectly) +nested ``if`` statement with no ``else``. Braces on the outer ``if`` would help to avoid +running into a "dangling else" situation. + + +Note that comments should only be hoisted for loops and +``if``, and not in ``else if`` or ``else``, where it would be unclear whether the comment +belonged to the preceeding condition, or the ``else``. + +.. code-block:: c++ + + // Omit the braces, since the body is simple and clearly associated with the if. + if (isa(D)) + handleFunctionDecl(D); + else if (isa(D)) + handleVarDecl(D); + else { + // In this else case, it is necessary that we explain the situation with this + // surprisingly long comment, so it would be unclear without the braces whether + // the following statement is in the scope of the else. + handleOtherDecl(D); + } + + // This should also omit braces. The for loop contains only a single statement, + // so it shouldn't have braces. The if also only contains a single statement (the + // for loop), so it also should omit braces. + if (isa(D)) + for (auto *A : D.attrs()) + handleAttr(A); + + See Also ======== diff --git a/gnu/llvm/llvm/docs/CommandGuide/FileCheck.rst b/gnu/llvm/llvm/docs/CommandGuide/FileCheck.rst index 0072c9c0347..0a0c2c5dd25 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/FileCheck.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/FileCheck.rst @@ -39,15 +39,31 @@ and from the command line. match. By default, these patterns are prefixed with "``CHECK:``". If you'd like to use a different prefix (e.g. because the same input file is checking multiple different tool or options), the - :option:`--check-prefix` argument allows you to specify one or more - prefixes to match. Multiple prefixes are useful for tests which might - change for different run options, but most lines remain the same. + :option:`--check-prefix` argument allows you to specify (without the trailing + "``:``") one or more prefixes to match. Multiple prefixes are useful for tests + which might change for different run options, but most lines remain the same. + + FileCheck does not permit duplicate prefixes, even if one is a check prefix + and one is a comment prefix (see :option:`--comment-prefixes` below). .. option:: --check-prefixes prefix1,prefix2,... An alias of :option:`--check-prefix` that allows multiple prefixes to be specified as a comma separated list. +.. option:: --comment-prefixes prefix1,prefix2,... + + By default, FileCheck ignores any occurrence in ``match-filename`` of any check + prefix if it is preceded on the same line by "``COM:``" or "``RUN:``". See the + section `The "COM:" directive`_ for usage details. + + These default comment prefixes can be overridden by + :option:`--comment-prefixes` if they are not appropriate for your testing + environment. However, doing so is not recommended in LLVM's LIT-based test + suites, which should be easier to maintain if they all follow a consistent + comment style. In that case, consider proposing a change to the default + comment prefixes instead. + .. option:: --input-file filename File to check (defaults to stdin). @@ -87,16 +103,37 @@ and from the command line. -verify``. With this option FileCheck will verify that input does not contain warnings not covered by any ``CHECK:`` patterns. -.. option:: --dump-input +.. option:: --dump-input Dump input to stderr, adding annotations representing currently enabled - diagnostics. Do this either 'always', on 'fail', or 'never'. Specify 'help' - to explain the dump format and quit. + diagnostics. When there are multiple occurrences of this option, the + ```` that appears earliest in the list below has precedence. The + default is ``fail``. + + * ``help`` - Explain input dump and quit + * ``always`` - Always dump input + * ``fail`` - Dump input on failure + * ``never`` - Never dump input + +.. option:: --dump-input-context -.. option:: --dump-input-on-failure + In the dump requested by ``--dump-input``, print ```` input lines before + and ```` input lines after any lines specified by ``--dump-input-filter``. + When there are multiple occurrences of this option, the largest specified + ```` has precedence. The default is 5. - When the check fails, dump all of the original input. This option is - deprecated in favor of `--dump-input=fail`. +.. option:: --dump-input-filter + + In the dump requested by ``--dump-input``, print only input lines of kind + ```` plus any context specified by ``--dump-input-context``. When + there are multiple occurrences of this option, the ```` that appears + earliest in the list below has precedence. The default is ``error`` when + ``--dump-input=fail``, and it's ``all`` when ``--dump-input=always``. + + * ``all`` - All input lines + * ``annotation-full`` - Input lines with annotations + * ``annotation`` - Input lines with starting points of annotations + * ``error`` - Input lines with starting points of error annotations .. option:: --enable-var-scope @@ -112,10 +149,11 @@ and from the command line. Sets a filecheck pattern variable ``VAR`` with value ``VALUE`` that can be used in ``CHECK:`` lines. -.. option:: -D#= +.. option:: -D#,= - Sets a filecheck numeric variable ``NUMVAR`` to the result of evaluating - ```` that can be used in ``CHECK:`` lines. See section + Sets a filecheck numeric variable ``NUMVAR`` of matching format ``FMT`` to + the result of evaluating ```` that can be used in + ``CHECK:`` lines. See section ``FileCheck Numeric Variables and Expressions`` for details on supported numeric expressions. @@ -125,15 +163,15 @@ and from the command line. .. option:: -v - Print good directive pattern matches. However, if ``-input-dump=fail`` or - ``-input-dump=always``, add those matches as input annotations instead. + Print good directive pattern matches. However, if ``-dump-input=fail`` or + ``-dump-input=always``, add those matches as input annotations instead. .. option:: -vv Print information helpful in diagnosing internal FileCheck issues, such as discarded overlapping ``CHECK-DAG:`` matches, implicit EOF pattern matches, and ``CHECK-NOT:`` patterns that do not have matches. Implies ``-v``. - However, if ``-input-dump=fail`` or ``-input-dump=always``, just add that + However, if ``-dump-input=fail`` or ``-dump-input=always``, just add that information as input annotations instead. .. option:: --allow-deprecated-dag-overlap @@ -235,6 +273,57 @@ circumstances, for example, testing different architectural variants with In this case, we're testing that we get the expected code generation with both 32-bit and 64-bit code generation. +The "COM:" directive +~~~~~~~~~~~~~~~~~~~~ + +Sometimes you want to disable a FileCheck directive without removing it +entirely, or you want to write comments that mention a directive by name. The +"``COM:``" directive makes it easy to do this. For example, you might have: + +.. code-block:: llvm + + ; X32: pinsrd_1: + ; X32: pinsrd $1, 4(%esp), %xmm0 + + ; COM: FIXME: X64 isn't working correctly yet for this part of codegen, but + ; COM: X64 will have something similar to X32: + ; COM: + ; COM: X64: pinsrd_1: + ; COM: X64: pinsrd $1, %edi, %xmm0 + +Without "``COM:``", you would need to use some combination of rewording and +directive syntax mangling to prevent FileCheck from recognizing the commented +occurrences of "``X32:``" and "``X64:``" above as directives. Moreover, +FileCheck diagnostics have been proposed that might complain about the above +occurrences of "``X64``" that don't have the trailing "``:``" because they look +like directive typos. Dodging all these problems can be tedious for a test +author, and directive syntax mangling can make the purpose of test code unclear. +"``COM:``" avoids all these problems. + +A few important usage notes: + +* "``COM:``" within another directive's pattern does *not* comment out the + remainder of the pattern. For example: + + .. code-block:: llvm + + ; X32: pinsrd $1, 4(%esp), %xmm0 COM: This is part of the X32 pattern! + + If you need to temporarily comment out part of a directive's pattern, move it + to another line. The reason is that FileCheck parses "``COM:``" in the same + manner as any other directive: only the first directive on the line is + recognized as a directive. + +* For the sake of LIT, FileCheck treats "``RUN:``" just like "``COM:``". If this + is not suitable for your test environment, see :option:`--comment-prefixes`. + +* FileCheck does not recognize "``COM``", "``RUN``", or any user-defined comment + prefix as a comment directive if it's combined with one of the usual check + directive suffixes, such as "``-NEXT:``" or "``-NOT:``", discussed below. + FileCheck treats such a combination as plain text instead. If it needs to act + as a comment directive for your test environment, define it as such with + :option:`--comment-prefixes`. + The "CHECK-NEXT:" directive ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -588,27 +677,71 @@ numeric expression constraint based on those variables via a numeric substitution. This allows ``CHECK:`` directives to verify a numeric relation between two numbers, such as the need for consecutive registers to be used. -The syntax to define a numeric variable is ``[[#:]]`` where -```` is the name of the numeric variable to define to the matching -value. +The syntax to define a numeric variable is ``[[#%,:]]`` where: + +* ``%`` is an optional scanf-style matching format specifier to + indicate what number format to match (e.g. hex number). Currently accepted + format specifiers are ``%u``, ``%d``, ``%x`` and ``%X``. If absent, the + format specifier defaults to ``%u``. + +* ```` is the name of the numeric variable to define to the matching + value. For example: .. code-block:: llvm - ; CHECK: mov r[[#REG:]], 42 + ; CHECK: mov r[[#REG:]], 0x[[#%X,IMM:]] + +would match ``mov r5, 0xF0F0`` and set ``REG`` to the value ``5`` and ``IMM`` +to the value ``0xF0F0``. + +The syntax of a numeric substitution is +``[[#%: ]]`` where: + +* ``%`` is the same matching format specifier as for defining numeric + variables but acting as a printf-style format to indicate how a numeric + expression value should be matched against. If absent, the format specifier + is inferred from the matching format of the numeric variable(s) used by the + expression constraint if any, and defaults to ``%u`` if no numeric variable + is used. In case of conflict between matching formats of several numeric + variables the format specifier is mandatory. + +* ```` is the constraint describing how the value to match must + relate to the value of the numeric expression. The only currently accepted + constraint is ``==`` for an exact match and is the default if + ```` is not provided. No matching constraint must be specified + when the ```` is empty. + +* ```` is an expression. An expression is in turn recursively defined + as: + + * a numeric operand, or + * an expression followed by an operator and a numeric operand. -would match ``mov r5, 42`` and set ``REG`` to the value ``5``. + A numeric operand is a previously defined numeric variable, an integer + literal, or a function. Spaces are accepted before, after and between any of + these elements. Numeric operands have 64-bit precision. Overflow and underflow + are rejected. There is no support for operator precedence, but parentheses + can be used to change the evaluation order. -The syntax of a numeric substitution is ``[[#]]`` where ```` is an -expression. An expression is recursively defined as: +The supported operators are: -* a numeric operand, or -* an expression followed by an operator and a numeric operand. + * ``+`` - Returns the sum of its two operands. + * ``-`` - Returns the difference of its two operands. -A numeric operand is a previously defined numeric variable, or an integer -literal. The supported operators are ``+`` and ``-``. Spaces are accepted -before, after and between any of these elements. +The syntax of a function call is ``()`` where: + +* ``name`` is a predefined string literal. Accepted values are: + + * add - Returns the sum of its two operands. + * div - Returns the quotient of its two operands. + * max - Returns the largest of its two operands. + * min - Returns the smallest of its two operands. + * mul - Returns the product of its two operands. + * sub - Returns the difference of its two operands. + +* ```` is a comma separated list of expressions. For example: @@ -616,6 +749,8 @@ For example: ; CHECK: load r[[#REG:]], [r0] ; CHECK: load r[[#REG+1]], [r1] + ; CHECK: Loading from 0x[[#%x,ADDR:]] + ; CHECK-SAME: to 0x[[#ADDR + 7]] The above example would match the text: @@ -623,6 +758,7 @@ The above example would match the text: load r5, [r0] load r6, [r1] + Loading from 0xa0463440 to 0xa0463447 but would not match the text: @@ -630,8 +766,10 @@ but would not match the text: load r5, [r0] load r7, [r1] + Loading from 0xa0463440 to 0xa0463443 -due to ``7`` being unequal to ``5 + 1``. +Due to ``7`` being unequal to ``5 + 1`` and ``a0463443`` being unequal to +``a0463440 + 7``. The syntax also supports an empty expression, equivalent to writing {{[0-9]+}}, for cases where the input must contain a numeric value but the value itself @@ -644,10 +782,24 @@ does not matter: to check that a value is synthesized rather than moved around. A numeric variable can also be defined to the result of a numeric expression, -in which case the numeric expression is checked and if verified the variable is -assigned to the value. The unified syntax for both defining numeric variables -and checking a numeric expression is thus ``[[#: ]]`` with each -element as described previously. +in which case the numeric expression constraint is checked and if verified the +variable is assigned to the value. The unified syntax for both defining numeric +variables and checking a numeric expression is thus +``[[#%,: ]]`` with each element as +described previously. One can use this syntax to make a testcase more +self-describing by using variables instead of values: + +.. code-block:: gas + + ; CHECK: mov r[[#REG_OFFSET:]], 0x[[#%X,FIELD_OFFSET:12]] + ; CHECK-NEXT: load r[[#]], [r[[#REG_BASE:]], r[[#REG_OFFSET]]] + +which would match: + +.. code-block:: gas + + mov r4, 0xC + load r6, [r5, r4] The ``--enable-var-scope`` option has the same effect on numeric variables as on string variables. diff --git a/gnu/llvm/llvm/docs/CommandGuide/dsymutil.rst b/gnu/llvm/llvm/docs/CommandGuide/dsymutil.rst index 4aa9c1c7c49..78954fcc8d8 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/dsymutil.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/dsymutil.rst @@ -18,7 +18,12 @@ its symbol table. By default, the linked debug information is placed in a OPTIONS ------- -.. option:: --arch= +.. option:: --accelerator= + + Specify the desired type of accelerator table. Valid options are 'Apple', + 'Dwarf' and 'Default'. + +.. option:: --arch Link DWARF debug information only for specified CPU architecture types. Architectures may be specified by name. When using this option, an error will @@ -32,17 +37,25 @@ OPTIONS Dump the *executable*'s debug-map (the list of the object files containing the debug information) in YAML format and exit. Not DWARF link will take place. -.. option:: -f, --flat +.. option:: --flat, -f Produce a flat dSYM file. A ``.dwarf`` extension will be appended to the - executable name unless the output file is specified using the -o option. + executable name unless the output file is specified using the ``-o`` option. + +.. option:: --gen-reproducer + + Generate a reproducer consisting of the input object files. -.. option:: -z, --minimize +.. option:: --help, -h + + Print this help output. + +.. option:: --minimize, -z When used when creating a dSYM file, this option will suppress the emission of the .debug_inlines, .debug_pubnames, and .debug_pubtypes sections since dsymutil currently has better equivalents: .apple_names and .apple_types. When - used in conjunction with --update option, this option will cause redundant + used in conjunction with ``--update`` option, this option will cause redundant accelerator tables to be removed. .. option:: --no-odr @@ -57,20 +70,26 @@ OPTIONS Don't check the timestamp for swiftmodule files. -.. option:: -j , --num-threads= +.. option:: --num-threads , -j Specifies the maximum number (``n``) of simultaneous threads to use when linking multiple architectures. -.. option:: -o +.. option:: --object-prefix-map - Specifies an alternate ``path`` to place the dSYM bundle. The default dSYM - bundle path is created by appending ``.dSYM`` to the executable name. + Remap object file paths (but no source paths) before processing. Use + this for Clang objects where the module cache location was remapped using + ``-fdebug-prefix-map``; to help dsymutil find the Clang module cache. -.. option:: --oso-prepend-path= +.. option:: --oso-prepend-path Specifies a ``path`` to prepend to all debug symbol object file paths. +.. option:: --out , -o + + Specifies an alternate ``path`` to place the dSYM bundle. The default dSYM + bundle path is created by appending ``.dSYM`` to the executable name. + .. option:: --papertrail When running dsymutil as part of your build system, it can be desirable for @@ -78,11 +97,35 @@ OPTIONS output stream. When enabled warnings are embedded in the linked DWARF debug information. +.. option:: --remarks-output-format + + Specify the format to be used when serializing the linked remarks. + +.. option:: --remarks-prepend-path + + Specify a directory to prepend the paths of the external remark files. + +.. option:: --statistics + + Print statistics about the contribution of each object file to the linked + debug info. This prints a table after linking with the object file name, the + size of the debug info in the object file (in bytes) and the size contributed + (in bytes) to the linked dSYM. The table is sorted by the output size listing + the obj ect files with the largest contribution first. + +.. option:: --symbol-map + + Update the existing dSYMs inplace using symbol map specified. + .. option:: -s, --symtab Dumps the symbol table found in *executable* or object file(s) and exits. -.. option:: --toolchain +.. option:: -S + + Output textual assembly instead of a binary dSYM companion file. + +.. option:: --toolchain Embed the toolchain in the dSYM bundle's property list. @@ -92,11 +135,19 @@ OPTIONS other DWARF optimizations. This option will rebuild the '.apple_names' and '.apple_types' hashed accelerator tables. -.. option:: -v, --verbose +.. option:: --use-reproducer + + Use the object files from the given reproducer path. + +.. option:: --verbose Display verbose information when linking. -.. option:: --version +.. option:: --verify + + Run the DWARF verifier on the linked DWARF debug info. + +.. option:: -v, --version Display the version of the tool. diff --git a/gnu/llvm/llvm/docs/CommandGuide/lit.rst b/gnu/llvm/llvm/docs/CommandGuide/lit.rst index 40aeecdf2c8..d29d293f32d 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/lit.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/lit.rst @@ -158,6 +158,12 @@ EXECUTION OPTIONS SELECTION OPTIONS ----------------- +.. option:: --max-failures N + + Stop execution after the given number ``N`` of failures. + An integer argument should be passed on the command line + prior to execution. + .. option:: --max-tests=N Run at most ``N`` tests and then terminate. @@ -165,10 +171,8 @@ SELECTION OPTIONS .. option:: --max-time=N Spend at most ``N`` seconds (approximately) running tests and then terminate. - -.. option:: --shuffle - - Run the tests in a random order. + Note that this is not an alias for :option:`--timeout`; the two are + different kinds of maximums. .. option:: --num-shards=M @@ -176,7 +180,7 @@ SELECTION OPTIONS "shards", and run only one of them. Must be used with the ``--run-shard=N`` option, which selects the shard to run. The environment variable ``LIT_NUM_SHARDS`` can also be used in place of this - option. These two options provide a coarse mechanism for paritioning large + option. These two options provide a coarse mechanism for partitioning large testsuites, for parallel execution on separate machines (say in a large testing farm). @@ -187,6 +191,16 @@ SELECTION OPTIONS must be in the range ``1..M``. The environment variable ``LIT_RUN_SHARD`` can also be used in place of this option. +.. option:: --shuffle + + Run the tests in a random order. + +.. option:: --timeout=N + + Spend at most ``N`` seconds (approximately) running each individual test. + ``0`` means no time limit, and ``0`` is the default. Note that this is not an + alias for :option:`--max-time`; the two are different kinds of maximums. + .. option:: --filter=REGEXP Run only those tests whose name matches the regular expression specified in @@ -251,12 +265,17 @@ convenient and flexible support for out-of-tree builds. TEST STATUS RESULTS ------------------- -Each test ultimately produces one of the following six results: +Each test ultimately produces one of the following eight results: **PASS** The test succeeded. +**FLAKYPASS** + + The test succeeded after being re-run more than once. This only applies to + tests containing an ``ALLOW_RETRIES:`` annotation. + **XFAIL** The test failed, but that is expected. This is used for test formats which allow @@ -283,6 +302,11 @@ Each test ultimately produces one of the following six results: The test is not supported in this environment. This is used by test formats which can report unsupported tests. +**TIMEOUT** + + The test was run, but it timed out before it was able to complete. This is + considered a failure. + Depending on the test format tests may produce additional information about their status (generally only for failures). See the :ref:`output-options` section for more information. @@ -400,11 +424,12 @@ be used to define subdirectories of optional tests, or to change other configuration parameters --- for example, to change the test format, or the suffixes which identify test files. -PRE-DEFINED SUBSTITUTIONS -~~~~~~~~~~~~~~~~~~~~~~~~~~ +SUBSTITUTIONS +~~~~~~~~~~~~~ -:program:`lit` provides various patterns that can be used with the RUN command. -These are defined in TestRunner.py. The base set of substitutions are: +:program:`lit` allows patterns to be substituted inside RUN commands. It also +provides the following base set of substitutions, which are defined in +TestRunner.py: ======================= ============== Macro Substitution @@ -443,6 +468,14 @@ Other substitutions are provided that are variations on this base set and further substitution patterns can be defined by each test module. See the modules :ref:`local-configuration-files`. +By default, substitutions are expanded exactly once, so that if e.g. a +substitution ``%build`` is defined in top of another substitution ``%cxx``, +``%build`` will expand to ``%cxx`` textually, not to what ``%cxx`` expands to. +However, if the ``recursiveExpansionLimit`` property of the ``TestingConfig`` +is set to a non-negative integer, substitutions will be expanded recursively +until that limit is reached. It is an error if the limit is reached and +expanding substitutions again would yield a different result. + More detailed information on substitutions can be found in the :doc:`../TestingGuide`. diff --git a/gnu/llvm/llvm/docs/CommandGuide/llc.rst b/gnu/llvm/llvm/docs/CommandGuide/llc.rst index 4575e4a543a..9b07b0b29d4 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llc.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llc.rst @@ -112,6 +112,14 @@ End-user Options Enable optimizations that assume no NAN values. +.. option:: --enable-no-signed-zeros-fp-math + + Enable FP math optimizations that assume the sign of 0 is insignificant. + +.. option:: --enable-no-trapping-fp-math + + Enable setting the FP exceptions build attribute not to use exceptions. + .. option:: --enable-unsafe-fp-math Enable optimizations that make unsafe assumptions about IEEE math (e.g. that diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-addr2line.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-addr2line.rst index 4f5881dc8e8..646a159cd24 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-addr2line.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-addr2line.rst @@ -17,17 +17,24 @@ GNU's :program:`addr2line`. Here are some of those differences: -- Defaults not to print function names. Use `-f`_ to enable that. +- ``llvm-addr2line`` interprets all addresses as hexadecimal and ignores an + optional ``0x`` prefix, whereas ``llvm-symbolizer`` attempts to determine + the base from the literal's prefix and defaults to decimal if there is no + prefix. -- Defaults not to demangle function names. Use `-C`_ to switch the - demangling on. +- ``llvm-addr2line`` defaults not to print function names. Use `-f`_ to enable + that. -- Defaults not to print inlined frames. Use `-i`_ to show inlined - frames for a source code location in an inlined function. +- ``llvm-addr2line`` defaults not to demangle function names. Use `-C`_ to + switch the demangling on. -- Uses `--output-style=GNU`_ by default. +- ``llvm-addr2line`` defaults not to print inlined frames. Use `-i`_ to show + inlined frames for a source code location in an inlined function. -- Parses options from the environment variable ``LLVM_ADDR2LINE_OPTS``. +- ``llvm-addr2line`` uses `--output-style=GNU`_ by default. + +- ``llvm-addr2line`` parses options from the environment variable + ``LLVM_ADDR2LINE_OPTS`` instead of from ``LLVM_SYMBOLIZER_OPTS``. SEE ALSO -------- diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-cxxfilt.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-cxxfilt.rst index 5d257b98895..b50252aea1e 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-cxxfilt.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-cxxfilt.rst @@ -46,16 +46,21 @@ OPTIONS .. option:: --help, -h - Print a summary of command line options. + Print a summary of command line options. .. option:: --help-list - Print an uncategorized summary of command line options. + Print an uncategorized summary of command line options. + +.. option:: --no-strip-underscore, -n + + Do not strip a leading underscore. This is the default for all platforms + except Mach-O based hosts. .. option:: --strip-underscore, -_ - Discard a single leading underscore, if present, from each input name before - demangling. + Strip a single leading underscore, if present, from each input name before + demangling. On by default on Mach-O based platforms. .. option:: --types, -t diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-dwarfdump.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-dwarfdump.rst index b8de0847aaa..d0c7be44213 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-dwarfdump.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-dwarfdump.rst @@ -105,10 +105,15 @@ OPTIONS When displaying debug info entries, only show children to a maximum depth of . +.. option:: --show-section-sizes + + Show the sizes of all debug sections, expressed in bytes. + .. option:: --statistics Collect debug info quality metrics and print the results - as machine-readable single-line JSON output. + as machine-readable single-line JSON output. The output + format is described in the section below (:ref:`stats-format`). .. option:: --summarize-types @@ -144,7 +149,7 @@ OPTIONS Display the version of the tool. -.. option:: --debug-abbrev, --debug-addr, --debug-aranges, --debug-cu-index, --debug-frame [=], --debug-gnu-pubnames, --debug-gnu-pubtypes, --debug-info [=], --debug-line [=], --debug-line-str, --debug-loc [=], --debug-loclists [=], --debug-macro, --debug-names, --debug-pubnames, --debug-pubtypes, --debug-ranges, --debug-rnglists, --debug-str, --debug-str-offsets, --debug-tu-index, --debug-types, --eh-frame [=], --gdb-index, --apple-names, --apple-types, --apple-namespaces, --apple-objc +.. option:: --debug-abbrev, --debug-addr, --debug-aranges, --debug-cu-index, --debug-frame[=], --debug-gnu-pubnames, --debug-gnu-pubtypes, --debug-info [=], --debug-line [=], --debug-line-str, --debug-loc [=], --debug-loclists [=], --debug-macro, --debug-names, --debug-pubnames, --debug-pubtypes, --debug-ranges, --debug-rnglists, --debug-str, --debug-str-offsets, --debug-tu-index, --debug-types [=], --eh-frame [=], --gdb-index, --apple-names, --apple-types, --apple-namespaces, --apple-objc Dump the specified DWARF section by name. Only the `.debug_info` section is shown by default. Some entries @@ -158,6 +163,30 @@ OPTIONS Read command-line options from ``. +.. _stats-format: + +FORMAT OF STATISTICS OUTPUT +--------------------------- + +The ::option:`--statistics` option generates single-line JSON output +representing quality metrics of the processed debug info. These metrics are +useful to compare changes between two compilers, particularly for judging +the effect that a change to the compiler has on the debug info quality. + +The output is formatted as key-value pairs. The first pair contains a version +number. The following naming scheme is used for the keys: + + - `variables` ==> local variables and parameters + - `local vars` ==> local variables + - `params` ==> formal parameters + +For aggregated values, the following keys are used: + + - `sum_of_all_variables(...)` ==> the sum applied to all variables + - `#bytes` ==> the number of bytes + - `#variables - entry values ...` ==> the number of variables excluding + the entry values etc. + EXIT STATUS ----------- diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-exegesis.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-exegesis.rst index 81e92e7736d..321cdf5a6da 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-exegesis.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-exegesis.rst @@ -175,7 +175,8 @@ OPTIONS .. option:: -opcode-index= - Specify the opcode to measure, by index. See example 1 for details. + Specify the opcode to measure, by index. Specifying `-1` will result + in measuring every existing opcode. See example 1 for details. Either `opcode-index`, `opcode-name` or `snippets-file` must be set. .. option:: -opcode-name=,,... @@ -184,10 +185,10 @@ OPTIONS a comma-separated list. See example 1 for details. Either `opcode-index`, `opcode-name` or `snippets-file` must be set. - .. option:: -snippets-file= +.. option:: -snippets-file= - Specify the custom code snippet to measure. See example 2 for details. - Either `opcode-index`, `opcode-name` or `snippets-file` must be set. + Specify the custom code snippet to measure. See example 2 for details. + Either `opcode-index`, `opcode-name` or `snippets-file` must be set. .. option:: -mode=[latency|uops|inverse_throughput|analysis] @@ -195,6 +196,17 @@ OPTIONS to specify at least one of the `-analysis-clusters-output-file=` and `-analysis-inconsistencies-output-file=`. +.. option:: -repetition-mode=[duplicate|loop|min] + + Specify the repetition mode. `duplicate` will create a large, straight line + basic block with `num-repetitions` copies of the snippet. `loop` will wrap + the snippet in a loop which will be run `num-repetitions` times. The `loop` + mode tends to better hide the effects of the CPU frontend on architectures + that cache decoded instructions, but consumes a register for counting + iterations. If performing an analysis over many opcodes, it may be best + to instead use the `min` mode, which will run each other mode, and produce + the minimal measured result. + .. option:: -num-repetitions= Specify the number of repetitions of the asm snippet. diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-extract.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-extract.rst index cd8828b2372..17d2e9df1dd 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-extract.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-extract.rst @@ -26,6 +26,28 @@ standard output, unless the **-o** option is specified (see below). OPTIONS ------- +**--alias** *alias-name* + + Extract the alias named *function-name* from the LLVM bitcode. May be + specified multiple times to extract multiple alias at once. + +**--ralias** *alias-regular-expr* + + Extract the alias matching *alias-regular-expr* from the LLVM bitcode. + All alias matching the regular expression will be extracted. May be + specified multiple times. + +**--bb** *basic-block-specifier* + + Extract basic blocks(s) specicified in *basic-block-specifier*. May be + specified multiple times. Each specifier pair will create + a function. If multiple basic blocks are specified in one pair, the first + block in the sequence should dominate the rest. + +**--delete** + + Delete specified Globals from Module. + **-f** Enable binary output on terminals. Normally, :program:`llvm-extract` will @@ -55,6 +77,14 @@ OPTIONS bitcode. All global variables matching the regular expression will be extracted. May be specified multiple times. +**--keep-const-init** + + Preserve the values of constant globals. + +**--recursive** + + Recursively extract all called functions + **-help** Print a summary of command line options. diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-lipo.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-lipo.rst index 7e661153a65..20b2984fc9b 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-lipo.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-lipo.rst @@ -70,4 +70,4 @@ COMMANDS BUGS ---- -To report bugs, please visit . +To report bugs, please visit . diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-locstats.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-locstats.rst index 227c069aca9..3186566e449 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-locstats.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-locstats.rst @@ -43,6 +43,11 @@ OPTIONS make histogram of location buckets generated (requires matplotlib) +.. option:: --compare + + compare the debug location coverage on two files provided, and draw + a plot showing the difference (requires matplotlib) + EXIT STATUS ----------- @@ -94,6 +99,19 @@ Generate a plot as an image file. .. image:: locstats-draw-plot.png :align: center +EXAMPLE 3 +-------------- + +Generate a plot as an image file showing the difference in the debug location +coverage. + +.. code-block:: none + + llvm-locstats --compare file1.out file1.withentryvals.out + +.. image:: locstats-compare.png + :align: center + SEE ALSO -------- diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-mca.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-mca.rst index efe29c4da4b..092aa2beb6c 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-mca.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-mca.rst @@ -40,6 +40,10 @@ Or for Intel syntax: $ clang foo.c -O2 -target x86_64-unknown-unknown -mllvm -x86-asm-syntax=intel -S -o - | llvm-mca -mcpu=btver2 +(:program:`llvm-mca` detects Intel syntax by the presence of an `.intel_syntax` +directive at the beginning of the input. By default its output syntax matches +that of its input.) + Scheduling models are not just used to compute instruction latencies and throughput, but also to understand what processor resources are available and how to simulate them. @@ -384,10 +388,10 @@ IPC is computed dividing the total number of simulated instructions by the total number of cycles. Field *Block RThroughput* is the reciprocal of the block throughput. Block -throuhgput is a theoretical quantity computed as the maximum number of blocks +throughput is a theoretical quantity computed as the maximum number of blocks (i.e. iterations) that can be executed per simulated clock cycle in the absence -of loop carried dependencies. Block throughput is is superiorly -limited by the dispatch rate, and the availability of hardware resources. +of loop carried dependencies. Block throughput is superiorly limited by the +dispatch rate, and the availability of hardware resources. In the absence of loop-carried data dependencies, the observed IPC tends to a theoretical maximum which can be computed by dividing the number of instructions diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-nm.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-nm.rst index 71efac7fa7a..607c871ff7a 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-nm.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-nm.rst @@ -219,7 +219,7 @@ OPTIONS .. option:: --special-syms - Ignored. For GNU compatibility only. + Do not filter special symbols from the output. .. option:: --undefined-only, -u @@ -246,6 +246,10 @@ MACH-O SPECIFIC OPTIONS Add symbols from the dyldinfo, if they are not already in the symbol table. This is the default. +.. option:: --add-inlinedinfo + + Add symbols from the inlined libraries, TBD file inputs only. + .. option:: --arch= Dump the symbols from the specified architecture(s). diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-objcopy.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-objcopy.rst index 9237d739ad5..c5cff2ee256 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-objcopy.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-objcopy.rst @@ -130,6 +130,45 @@ multiple file formats. Set the alignment of section ``
`` to ```. Can be specified multiple times to update multiple sections. +.. option:: --set-section-flags
=[,,...] + + Set section properties in the output of section ``
`` based on the + specified ```` values. Can be specified multiple times to update multiple + sections. + + Supported flag names are `alloc`, `load`, `noload`, `readonly`, `exclude`, + `debug`, `code`, `data`, `rom`, `share`, `contents`, `merge` and `strings`. Not + all flags are meaningful for all object file formats. + + For ELF objects, the flags have the following effects: + + - `alloc` = add the `SHF_ALLOC` flag. + - `load` = if the section has `SHT_NOBITS` type, mark it as a `SHT_PROGBITS` + section. + - `readonly` = if this flag is not specified, add the `SHF_WRITE` flag. + - `exclude` = add the `SHF_EXCLUDE` flag. + - `code` = add the `SHF_EXECINSTR` flag. + - `merge` = add the `SHF_MERGE` flag. + - `strings` = add the `SHF_STRINGS` flag. + - `contents` = if the section has `SHT_NOBITS` type, mark it as a `SHT_PROGBITS` + section. + + For COFF objects, the flags have the following effects: + + - `alloc` = add the `IMAGE_SCN_CNT_UNINITIALIZED_DATA` and `IMAGE_SCN_MEM_READ` + flags, unless the `load` flag is specified. + - `noload` = add the `IMAGE_SCN_LNK_REMOVE` and `IMAGE_SCN_MEM_READ` flags. + - `readonly` = if this flag is not specified, add the `IMAGE_SCN_MEM_WRITE` + flag. + - `exclude` = add the `IMAGE_SCN_LNK_REMOVE` and `IMAGE_SCN_MEM_READ` flags. + - `debug` = add the `IMAGE_SCN_CNT_INITIALIZED_DATA`, + `IMAGE_SCN_MEM_DISCARDABLE` and `IMAGE_SCN_MEM_READ` flags. + - `code` = add the `IMAGE_SCN_CNT_CODE`, `IMAGE_SCN_MEM_EXECUTE` and + `IMAGE_SCN_MEM_READ` flags. + - `data` = add the `IMAGE_SCN_CNT_INITIALIZED_DATA` and `IMAGE_SCN_MEM_READ` + flags. + - `share` = add the `IMAGE_SCN_MEM_SHARED` and `IMAGE_SCN_MEM_READ` flags. + .. option:: --strip-all-gnu Remove all symbols, debug sections and relocations from the output. This option @@ -182,10 +221,6 @@ multiple file formats. Display the version of the :program:`llvm-objcopy` executable. -.. option:: @ - - Read command-line options and commands from response file ``. - .. option:: --wildcard, -w Allow wildcard syntax for symbol-related flags. On by default for @@ -210,12 +245,9 @@ multiple file formats. The order of wildcards does not matter. For example, ``-w -N '*' -N '!x'`` is the same as ``-w -N '!x' -N '*'``. -COFF-SPECIFIC OPTIONS ---------------------- +.. option:: @ -The following options are implemented only for COFF objects. If used with other -objects, :program:`llvm-objcopy` will either emit an error or silently ignore -them. + Read command-line options and commands from response file ``. ELF-SPECIFIC OPTIONS -------------------- @@ -385,7 +417,8 @@ them. Write the output as the specified format. See `SUPPORTED FORMATS`_ for a list of valid ```` values. If unspecified, the output format is assumed to - be the same as the input file's format. + be the same as the value specified for :option:`--input-target` or the input + file's format if that option is also unspecified. .. option:: --prefix-alloc-sections @@ -406,27 +439,6 @@ them. specified ```` values. See :option:`--set-section-flags` for a list of supported flags. Can be specified multiple times to rename multiple sections. -.. option:: --set-section-flags
=[,,...] - - Set section properties in the output of section ``
`` based on the - specified ```` values. Can be specified multiple times to update multiple - sections. - - Following is a list of supported flags and their effects: - - - `alloc` = add the `SHF_ALLOC` flag. - - `load` = if the section has `SHT_NOBITS` type, mark it as a `SHT_PROGBITS` - section. - - `readonly` = if this flag is not specified, add the `SHF_WRITE` flag. - - `code` = add the `SHF_EXECINSTR` flag. - - `merge` = add the `SHF_MERGE` flag. - - `strings` = add the `SHF_STRINGS` flag. - - `contents` = if the section has `SHT_NOBITS` type, mark it as a `SHT_PROGBITS` - section. - - The following flags are also accepted, but are ignored for GNU compatibility: - `noload`, `debug`, `data`, `rom`, `share`. - .. option:: --set-start-addr Set the start address of the output to ````. Overrides any previously @@ -534,7 +546,7 @@ Otherwise, it exits with code 0. BUGS ---- -To report bugs, please visit . +To report bugs, please visit . There is a known issue with :option:`--input-target` and :option:`--target` causing only ``binary`` and ``ihex`` formats to have any effect. Other values diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-objdump.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-objdump.rst index 1b8273beb56..df4cf746abb 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-objdump.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-objdump.rst @@ -33,7 +33,7 @@ combined with other commands: Disassemble all sections found in the input files. -.. option:: --disassemble-functions= +.. option:: --disassemble-symbols= Disassemble only the specified symbols. Takes demangled symbol names when :option:`--demangle` is specified, otherwise takes mangled symbol names. @@ -85,6 +85,10 @@ combined with other commands: Display the symbol table. +.. option:: -T, --dynamic-syms + + Display the contents of the dynamic symbol table. + .. option:: -u, --unwind-info Display the unwind info of the input(s). @@ -119,6 +123,17 @@ OPTIONS Demangle symbol names in the output. +.. option:: --debug-vars= + + Print the locations (in registers or memory) of source-level variables + alongside disassembly. ``format`` may be ``unicode`` or ``ascii``, defaulting + to ``unicode`` if omitted. + +.. option:: --debug-vars-indent= + + Distance to indent the source-level variable display, relative to the start + of the disassembly. Defaults to 40 characters. + .. option:: -j, --section= Perform commands on the specified sections only. For Mach-O use @@ -321,10 +336,17 @@ MACH-O ONLY OPTIONS AND COMMANDS Display weak binding information. +XCOFF ONLY OPTIONS AND COMMANDS +--------------------------------- + +.. option:: --symbol-description + + Add symbol description to disassembly output. + BUGS ---- -To report bugs, please visit . +To report bugs, please visit . SEE ALSO -------- diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-profdata.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-profdata.rst index 4ebf88f0253..13a66dc48ce 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-profdata.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-profdata.rst @@ -67,7 +67,7 @@ OPTIONS Specify an input file name along with a weight. The profile counts of the supplied ``filename`` will be scaled (multiplied) by the supplied - ``weight``, where where ``weight`` is a decimal integer >= 1. + ``weight``, where ``weight`` is a decimal integer >= 1. Input files specified without using this option are assigned a default weight of 1. Examples are shown below. @@ -102,6 +102,13 @@ OPTIONS Emit the profile using a binary encoding. For instrumentation-based profile the output format is the indexed binary format. + .. option:: -extbinary + + Emit the profile using an extensible binary encoding. This option can only + be used with sample-based profile. The extensible binary encoding can be + more compact with compression enabled and can be loaded faster than the + default binary encoding. + .. option:: -text Emit the profile in text mode. This option can also be used with both @@ -132,6 +139,28 @@ OPTIONS invalid profiles is excluded from the final merged product. The default failure mode is 'any'. +.. option:: -prof-sym-list=path + + Specify a file which contains a list of symbols to generate profile symbol + list in the profile. This option can only be used with sample-based profile + in extbinary format. The entries in this file are newline-separated. + +.. option:: -compress-all-sections=[true|false] + + Compress all sections when writing the profile. This option can only be used + with sample-based profile in extbinary format. + +.. option:: -use-md5=[true|false] + + Use MD5 to represent string in name table when writing the profile. + This option can only be used with sample-based profile in extbinary format. + +.. option:: -gen-partial-profile=[true|false] + + Mark the profile to be a partial profile which only provides partial profile + coverage for the optimized target. This option can only be used with + sample-based profile in extbinary format. + EXAMPLES ^^^^^^^^ Basic Usage @@ -242,6 +271,16 @@ OPTIONS Only show context sensitive profile counts. The default is to filter all context sensitive profile counts. +.. option:: -show-prof-sym-list=[true|false] + + Show profile symbol list if it exists in the profile. This option is only + meaningful for sample-based profile in extbinary format. + +.. option:: -show-sec-info-only=[true|false] + + Show basic information about each section in the profile. This option is + only meaningful for sample-based profile in extbinary format. + .. program:: llvm-profdata overlap .. _profdata-overlap: diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-readelf.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-readelf.rst index 2868d0b5989..f74f02c9a66 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-readelf.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-readelf.rst @@ -52,7 +52,7 @@ OPTIONS Display the dynamic table. -.. option:: --elf-cg-profile +.. option:: --cg-profile Display the callgraph profile section. diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-readobj.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-readobj.rst index 46a4b87d3fb..51cd266ff79 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-readobj.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-readobj.rst @@ -168,7 +168,7 @@ The following options are implemented only for the ELF file format. Display the dynamic table. -.. option:: --elf-cg-profile +.. option:: --cg-profile Display the callgraph profile section. diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-size.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-size.rst index 08426db4a32..b229bc63d40 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-size.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-size.rst @@ -195,4 +195,4 @@ Otherwise, it exits with code 0. BUGS ---- -To report bugs, please visit . +To report bugs, please visit . diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-strings.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-strings.rst index f2d04c4190b..e2fe4cb88c9 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-strings.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-strings.rst @@ -127,4 +127,4 @@ Otherwise, it exits with code 0. BUGS ---- -To report bugs, please visit . +To report bugs, please visit . diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-strip.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-strip.rst index 0e95996310d..a40537bd51c 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-strip.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-strip.rst @@ -101,10 +101,6 @@ multiple file formats. Display the version of the :program:`llvm-strip` executable. -.. option:: @ - - Read command-line options and commands from response file ``. - .. option:: --wildcard, -w Allow wildcard syntax for symbol-related flags. On by default for @@ -129,6 +125,10 @@ multiple file formats. The order of wildcards does not matter. For example, ``-w -N '*' -N '!x'`` is the same as ``-w -N '!x' -N '*'``. +.. option:: @ + + Read command-line options and commands from response file ``. + COFF-SPECIFIC OPTIONS --------------------- @@ -181,6 +181,10 @@ them. segments. Note that many tools will not be able to use an object without section headers. +.. option:: -T + + Remove Swift symbols. + EXIT STATUS ----------- @@ -190,7 +194,7 @@ Otherwise, it exits with code 0. BUGS ---- -To report bugs, please visit . +To report bugs, please visit . SEE ALSO -------- diff --git a/gnu/llvm/llvm/docs/CommandGuide/llvm-symbolizer.rst b/gnu/llvm/llvm/docs/CommandGuide/llvm-symbolizer.rst index bb60246c835..5c8465af04a 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/llvm-symbolizer.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/llvm-symbolizer.rst @@ -147,6 +147,28 @@ Example 4 - CODE and DATA prefixes: bar 6295592 4 +Example 5 - path-style options: + +This example uses the same source file as above, but the source file's +full path is /tmp/foo/test.cpp and is compiled as follows. The first case +shows the default absolute path, the second --basenames, and the third +shows --relativenames. + +.. code-block:: console + + $ pwd + /tmp + $ clang -g foo/test.cpp -o test.elf + $ llvm-symbolizer --obj=test.elf 0x4004a0 + main + /tmp/foo/test.cpp:15:0 + $ llvm-symbolizer --obj=test.elf 0x4004a0 --basenames + main + test.cpp:15:0 + $ llvm-symbolizer --obj=test.elf 0x4004a0 --relativenames + main + foo/test.cpp:15:0 + OPTIONS ------- @@ -158,8 +180,15 @@ OPTIONS .. option:: --basenames, -s - Strip directories when printing the file path. + Print just the file's name without any directories, instead of the + absolute path. + +.. option:: --relativenames + Print the file's path relative to the compilation directory, instead + of the absolute path. If the command-line to the compiler included + the full path, this will be the same as the default. + .. _llvm-symbolizer-opt-C: .. option:: --demangle, -C @@ -181,7 +210,7 @@ OPTIONS .. _llvm-symbolizer-opt-f: -.. option:: --functions [], -f +.. option:: --functions [=], -f Specify the way function names are printed (omit function name, print short function name, or print full linkage name, respectively). Defaults to @@ -227,6 +256,9 @@ OPTIONS topmost caller when inlined frames are not shown and :option:`--use-symbol-table` is on. + * Prints an address's debug-data discriminator when it is non-zero. One way to + produce discriminators is to compile with clang's -fdebug-info-for-profiling. + .. code-block:: console $ llvm-symbolizer --obj=inlined.elf 0x4004be 0x400486 -p @@ -244,46 +276,50 @@ OPTIONS baz() at /tmp/test.cpp:11 foo() at /tmp/test.cpp:6 + $ clang -g -fdebug-info-for-profiling test.cpp -o profiling.elf + $ llvm-symbolizer --output-style=GNU --obj=profiling.elf 0x401167 -p -i=0 + main at /tmp/test.cpp:15 (discriminator 2) + .. option:: --pretty-print, -p Print human readable output. If :option:`--inlining` is specified, the enclosing scope is prefixed by (inlined by). -.. code-block:: console + .. code-block:: console - $ llvm-symbolizer --obj=inlined.elf 0x4004be --inlining --pretty-print - baz() at /tmp/test.cpp:11:18 - (inlined by) main at /tmp/test.cpp:15:0 + $ llvm-symbolizer --obj=inlined.elf 0x4004be --inlining --pretty-print + baz() at /tmp/test.cpp:11:18 + (inlined by) main at /tmp/test.cpp:15:0 .. option:: --print-address, --addresses, -a Print address before the source code location. Defaults to false. -.. code-block:: console + .. code-block:: console - $ llvm-symbolizer --obj=inlined.elf --print-address 0x4004be - 0x4004be - baz() - /tmp/test.cpp:11:18 - main - /tmp/test.cpp:15:0 + $ llvm-symbolizer --obj=inlined.elf --print-address 0x4004be + 0x4004be + baz() + /tmp/test.cpp:11:18 + main + /tmp/test.cpp:15:0 - $ llvm-symbolizer --obj=inlined.elf 0x4004be --pretty-print --print-address - 0x4004be: baz() at /tmp/test.cpp:11:18 - (inlined by) main at /tmp/test.cpp:15:0 + $ llvm-symbolizer --obj=inlined.elf 0x4004be --pretty-print --print-address + 0x4004be: baz() at /tmp/test.cpp:11:18 + (inlined by) main at /tmp/test.cpp:15:0 .. option:: --print-source-context-lines Print ``N`` lines of source context for each symbolized address. -.. code-block:: console + .. code-block:: console - $ llvm-symbolizer --obj=test.elf 0x400490 --print-source-context-lines=2 - baz() - /tmp/test.cpp:11:0 - 10 : volatile int k = 42; - 11 >: return foz() + k; - 12 : } + $ llvm-symbolizer --obj=test.elf 0x400490 --print-source-context-lines=2 + baz() + /tmp/test.cpp:11:0 + 10 : volatile int k = 42; + 11 >: return foz() + k; + 12 : } .. _llvm-symbolizer-opt-use-symbol-table: @@ -296,19 +332,19 @@ OPTIONS Print verbose line and column information. -.. code-block:: console + .. code-block:: console - $ llvm-symbolizer --obj=inlined.elf --verbose 0x4004be - baz() - Filename: /tmp/test.cpp - Function start line: 9 - Line: 11 - Column: 18 - main - Filename: /tmp/test.cpp - Function start line: 14 - Line: 15 - Column: 0 + $ llvm-symbolizer --obj=inlined.elf --verbose 0x4004be + baz() + Filename: /tmp/test.cpp + Function start line: 9 + Line: 11 + Column: 18 + main + Filename: /tmp/test.cpp + Function start line: 14 + Line: 15 + Column: 0 .. option:: --version @@ -329,18 +365,18 @@ MACH-O SPECIFIC OPTIONS the input (see example below). If the architecture is not specified in either way, the address will not be symbolized. Defaults to empty string. -.. code-block:: console + .. code-block:: console - $ cat addr.txt - /tmp/mach_universal_binary:i386 0x1f84 - /tmp/mach_universal_binary:x86_64 0x100000f24 + $ cat addr.txt + /tmp/mach_universal_binary:i386 0x1f84 + /tmp/mach_universal_binary:x86_64 0x100000f24 - $ llvm-symbolizer < addr.txt - _main - /tmp/source_i386.cc:8 + $ llvm-symbolizer < addr.txt + _main + /tmp/source_i386.cc:8 - _main - /tmp/source_x86_64.cc:8 + _main + /tmp/source_x86_64.cc:8 .. option:: --dsym-hint diff --git a/gnu/llvm/llvm/docs/CommandGuide/locstats-compare.png b/gnu/llvm/llvm/docs/CommandGuide/locstats-compare.png new file mode 100644 index 0000000000000000000000000000000000000000..1f0a3af65e4a6f8bb38e418fd421e161ecd857b6 GIT binary patch literal 58210 zcmeFZWmr^y6fQc7ijAlsA)tgvw@9miv@K|@4MFc>E#QtYnMqbqfn@865=BADAc(;6bk3w z#S3tRV?6pS{BzFknS{bcc(`AD{Skh?WG$|0heF}$B7e@L38k9AK^}Wi75i6KhW1Xn zwgxB*U3+VDD|>Sjy?c%Zwss~~miO41*_k;R?-|?MTl2E8{LdFKTiF`1EQ^$8qfqxy z5+Y9(oWCuNxVZ;8Of{_UJ{nqb*LkEbO>~Rx15w>K+qB5PHj$qupW8@Dp!MY>B=ASL z+TP$%GjWW-Sz(6azV_jwMWfz@$T`y zJ2Po5>(w)G)$mYiD*n#*-&54I59-Q)Pn81x&$Iut1`r+pKZt{A;W19y!I5@2bXHeeT4;4DdAQwuk;LRj# zdhhqEU&cSPwXu;~pR7|XGF2266U%hj#Gdc3J*1+elQ3usVH+d$mGiDDDgnqfkdiV;n2wYeWhiDk$}ZxfP+oXv z8Br*56u0GY$NuK5!^x4$@y?J{6t`9E@7h{8J7ZZ{8G-%o+9}*-{PrS73Z0Oc$aFSq zvd+(Jsy+ZsjfWR>c3wM$K{;pc6K!nAXq8*5etLSkq=ZB#tVxk!E6MiC$PnevrmG61 zoW|CeGfIY<$x`8MggQm$16`G}$&#Vv%jNp|`mM<76`WVOLde+Bo2k5-G=xHpTZwp| zNBtDi@FQf}!bV#yv_x_ooE)xl88qEaPDxp)Sgn2)&a7GJygvDMg>vIpXQ!Mj|GLOi zCt>u~Hby&oLUDVccl%&5H`BN?f!B8WqvOhO`uQt_w^hbI6ELLc)qOs;*v4e3ZdzrM zqEN#;J3r5&#wl`C^7ULNKhgGNC^C3#G}3)|bbqA6Df3n83wo`} z(z|!>DkO+p+Meqa_BvV@i(Pi#88D((&iQuv4s#X>m#J}U6c^!a?eE_$Rqxot8zo#; zletW~s6(05m0rAf;d->*uw9EM^pKZ#kTI^TXHkpC^QctIWrhHGL119u#@3dCib@2w zJuXgvKa@c^!=O2AV||@%wb!m)Ahq@bo)nr{vpmV`cu_k;wIIda!((QA{2m@2o{z8Z zLe1%MuBxoLd6v1kdCPz@S|LT6*zYhDL#}d%S)&7j=JwsYjI^}0u)*n$%Y#wu29m`F z!I2Ku|rz}pC?zS@rAFhID+@HvIm)YL33FVD=+r%Q&?r>mD(4pzC9xLEyQu3GNPRxe&P z)N<2ljpPu!M*1iuJUsj^85sc)Q5vkk+|m9fI%#XmzG}0LFGHj3$G30a6iTgiL+KSI zWrdCl>vo}B4WGe5p^m1ml0Itr@>-m|+;KT-***AyOv@&0D0dKxcJ;8ey*+2Ufye&- zKJka^WKH=24diZ&>Mm|>Zu)T5hWi(;kwnbiymiYi%jjTh9=pCi)iA4K1QFb_yV#fA zyeUZi;DMS(T)6Ou>%^X(o;-n?Xg1@Hdwv^K&;9=vnH$!igM;mus2Yg?5p;=s^DRfp z`I~9rJ^sm0-(4^iYWv2cuaKp}hB4!FTr%!lZJAnGS$Y1IQuIeC1^a99*xg3ft5Zc7 zEskbPrgFPVm1~jBd{^?_X4pP1OtnFvKAfN|EWfCT%X4o6x0aQ$hJm|AGMw3h$X8c7 zPH=?(k$FEW6z{2n?ZxLWU%t%2c&^voA>4hCs*H6iu%GYZ@r=`Qp77xp5~^kO2c*HO zrNHKwRIUQOaB4x4c!IS0=wVp zs-<@2S4XQHj`nOMhzsh%7*!KsjWew$exs9iN8My0CPJw##;P@8J2-NeN2@BT4_Ek* zm{=Yx3eL8u7mEKD6T@XYE$*?|%B=PMEtX%NjBfFWf&hppUWJytcx4Z>4vqCADRyHg#F|n(=o6E3;NTTZs zOQp_=6^#UhlA)#xllswe$(a54&oc$9fVMqd$x>W4lOjdNozDO&&`HQW!1`bvtg81@ zRK1$RnC!BJ9z1y7ogx!VJuom}GXC?8TD5zbVcWO#6q)F#f}-l<9d!xf=ytE;ZOlJZ zwZlpSUNW?|6QNMk!cS?90fBc$OfU2$Nd&iS&NPK`T&-m#WKw%gZq}LLlW#Nid=oOz zSezXo#viWU(2RvrKC72D=S;3+;*1Onq|K|?&K%O$JZrqAKYn+ z;cJ~zHL?MSVQyz5_SL;g!uhw-h`Yw!-Q9o8>r|k<+Q?z5{@T=3kkBK5J%iG+GJ{M^ zb8~ZoJ9fQARate06KAnx%#$O?VZN(QTwI*BtE%`>b+rCIe3o$*qP_OQ?!2WbFmcg!_ zzLvFRKv1+*v#U&B`4s~CB();b5l4>_+qLnhcDZRk44N~< zzfxk$8YsMmk9ao84XTve`8TC=wwX0bUrtO+s1+Cnz-lHJ78aTtz}-7F91FT^B(=o~ zFwp52E5kl+E;%Uyv=DMs{|Mv}@*v@J%yL{E&5jrTkO5diuQ2D;e!>H9@x4wKwQ6&f zi1o?w;jXfV#y4iI$_R_GoQg6rv_iGJ3vvhOq}=KQNvKSrnVFf-goU?%;Zn>E7MVFI zdU@910k(#RtdD6M8>c}vQOwcc*& z0Rls>Ryb#|P0L+eT#O`#;L(~em({2SV0sr6+(Lt9LIlqiFu7xzy>Z$Cu3H^I9D0(a z?!c|6UcY`_Qe3>FC;e6L_oweFt}mca&Jp-JXHaY2s*u-p-G{vPbN3`JU%t#9EECsb{9NnsDO?i*-L@p>E- z?oZbOGc@h^{`B&dE8SE<{0SUJZPWdpSfkLfwRYC4W##3jKfTYWf@IT3fTWd-M_x&H%Oon3!T)A~$w+l;B8cSXfF@614?@YlY)- zlg+Jd9y@Frur~zBQ{y~M+q&SH+>uw5VfbHTcvKrGmJ=v`Z{qp6z zMDT-113rfZYKhPO{ypz6-J+H#FlrC;^Yf#mq=d>zgYd(Jfr3;Bm0XD9=qWci(8@Ml zjPKE>DyQwf?xR+0P6vFeH%pbHVFTiAp+7%S@bt*8KpU!A_dtOW)1%1trQIq3$D1Bo zono%QC3{P4^h237)n?n{Fp%!%VU6WI9E+tpO9P2@es>U7ORty_A{oY*{@dru;zDoc zV1ZFk%8M9!ZEbBRPV^X5V{@~VQQNo9eEkMap!3Mds;jH9*gfvU&32()xNGD#fhnPL zb8~^)IBZNyNc>QF7EzST#>PhfD#af-nPR3AlU>1Xw7}`nCicSeYRzf2<#1`d?={i| z!0-bg*xUQFahb3Vt}A7;(^zZ@ZJfJ2jZ|0n=4i#Sm& zKJO{3iuF7&nSv`P!~g|ofhy3l9hDVrXk?KH^?IO*kY3@hUhsC6+b#*L*FclO2tWT~ z%D_}ZP`gqe(8`3PWy{IfZU(!=)%Wku)wZ{@U~J!Axb`CrmVT@aAzTP`Ue=iS?E{Np zI{nx;i!^u4z1?o;;xSw|;qEk6xgn4&0GMNe`-`|_-RY_~N3FhBiP5tH4h{}Q{VzvZ zulli#xvw5>%?B@Q>~G8jK-3uwv5v4_O@wF~XfhJax|b?597HY_8AfBVy|UP5s=h32eS5nVgWU%{WyE;@9PlX}GcyKmZtnBv&!=lv zI3BE2tZqTAYiw<8P0)ZEUIdE=RYw%oGNh`i3d&ywlqeI(Lf|f*f!lcG{3^(HoW;Qb z?*IMEmm5r)I3wwmvW&xQ9386RNv9YlksDEtKb{9aKe`r)4&1pIOczbnB8?qxD>Je1VWLW>E#zwk^9iii` zS4gl63JUHoVfvr%waw2MQ%TI5?QxZHWz0+JH}-%}VL=q5yyj*4EZJ967e^ z`t?^mfS&+9zTxNRM^w0cvLqcap1XEHT6^P#aqVvHKl8bqF7oLnf)c>87{dn6qP&On z^@*Iy%pRanKgn3HQmL<@qoOiwXPV~cIupTK=xhw8Wr~djIqv=8mK&50@3U-fJLU-7 z0j+&iW;tD)VA4m<#t1UV*y(1q_2UAbvcto12>emeGu{N>E+B zKiv86RB~0W4n-D2N>I|!z%D@=ZOtVHEr5*Z&e5#+cP1UZ3s8xXM-~YOIGD&or}yIj z{ml9D{gpCE5;8tVX-iAX0rH^h$V+}!84~#dBY5cLB3_!%D4IA;h~Dq7YuK>gb~ zI%4VYQ7f7MhBfEeT@_Lqt5LrVq=xt+S<+!-$LOPv?RZSHzLpBvH#TD=j<;u8S4C}v8V9! zPoXOaBSIcoBxeX;dZW?k*ZTU2dwYBC+PBEavO&zusy<+3l!hW!Gqf@iiqrs>R>o z1rLh{9nu<&pUSxJR% z?FEmuU$}$$`X4~kf(A)Yzu>w14BQ5iN9Jiz8KZRX{`=HXoeP97pUA&@Wng4PDBU6`Wo6~w3`Hqm_f?|% zKYu;}_?MKEle2Yl!bq`Hg;;#jP*aO4cUsM1H)#6X*eF3juh0QS-F6A{5uXag9hH-l z6L3u_P>W@O6ToIk9$SBx40(9}&Ye5J)7A6y^RfG2z%cOhYiMa{0cv%^T4liX&#H|< zDJLKxpkZNQ;o;-U6!jzIbzb|P`9?AEc>rvwey393A^xpfiIE&eP4)H9J3Bkk zjNv!1)8X2la^Q7MFDxJx96`8$^05R&UZPk~AFM*O85vI`zsrxNFeV0ETwDY;wLP{& zU6@mo{b$=^I2yu2LXrU3B+(#;80-J#SE<`Mm7h$7W|$YLvT=Ro4vQ`N2qgfTLqJSS zN2gyehg2HJWwqtuvR6RIm7SeS1Ml+a$ze)urWC-gM2>^0(b}iv>ROJl4e$!h0P|d- z&~78XT(nhn{=*XF3_~TdusBg1MuCWW#;1Bd&Ffq3akv09tqXKvk=w2%0P+j?6mH>E zL5~AODh%f7zC$PtBJp!_a?1MdK(ND^%m6kHfcw8D@`d`8zKF@q1j}Tw#;b;!4wNlq zC8BtXc_$|)kwS!EI~*&!;Ghbk=LPJ!ytw$sVym$npz;g3H7D|iJIhus7Fr--lRS?P z=79tDf>EW%?A3A*IZJcz-V>la=p@LlSvP(p)Vz;e^7@$0c;UcaB0?JiTM0x1jRcsK zFFO-NTUEJ%8Yx1kwVFK-AW4S3Hi2tKYNku2T;g+AM9%I?NJtP`3=9papOXWtpc5Ra zB%~5kCfQh9cNCg*PcJQHiBWhcAfm-Aw<-nR*x1*{9xe!mWr}QE4jlgrp^oOX9)FUp zQ6}G=DvJTc0Avq z<{cd!*=98~G>9R^*4DPEsHIg9>Y~s4_jABIxPm}r%K#GdT913befxGpvAq?nlGM35 zWAJmJyz2Z!Sq%ITg+<^HnyLgP-U#=FMocTjJB1Z<^Cwn$A}I3wIX&zUCPyt}3PfgrP8(QAS1ZZ@ z>fX8=A0Lkx%AJW~1-&Ik?c~YH$#md;!#S{K#|PUW!oE;fZ8R~E2)Gsk2~O3m^)=aD z87bSb8mso8S4jI}ipjAcXOK_&2tR!HINTYrb$8N-t5YknjH!DJ#OI*|R%PW61gb)= zmVlo=DSO`a5^R`G+F;oN_K)zng|9bo3JL!Pd^M8<)cUd$xMXsLj|bdHL5yMyXI#|3ZD3 z)WEX;0@aeHT40EfF{NCsY&QM+Iq-*jK+w21ET53U3f?9s&w(^y87hNaJ+)Xiyb$WE z8_|%XU2{@W1PlU&$^*-MS{NvAZ;A{lLI7({Pb!exhJ}fq<+d8lg3Yv>S_=sYF>l7% zq_R`h!pc9Qn~f9&ZH0*5>FH@|iNPNRejwNhZru2iZ4Oxkj)(o^pG%0~FDoXyapODq zg6Yb+S|t3=dDVN9es^)QfNzeJ+6Y5Na)sZB74%R8WvdLV!_uv#BoQbk*ywUPI^zN! zw))oAd5_>ifPX|az!UR8Bp}ft-@au5ftC2t-=W#0(nn`t{^wumDlJiYc5(XE>(@!Z z6;nXqMn;zy(Q8*%A_%j$=L{rC3KG6;r|0+4LpY3NJf!9P&o?+Ey!L5;4nIPrWMmW} zB8r?=wV1T4H9&E_g3u^f_M(w^`t&KVH3bEQ5afJ+{)iwlQNP~56ZkE)1b_hs3Q$Ny zL>d@4s^Ig!LinJE|HqFVek|2#kS`_>NUkUQvx?9P5ET&_-ifdhixc#)$F>kVEc8eK zM@3u$I7v^oIyc8-h-5i;_ex?`aDM3p1xNLWvEa8u#W1M$S}wwH0?m|(1>>dud`O(QzFh5G#6V53f^JF}xM*R_ni(LQ>1k+Ytg7xH zk+8;k|L56_bbu4k(S0Y!hrMNXMt*i6pTIp2hf1Fbnj5mOMbB5s6Kt7R7K4RyV0TX_fWyc^ue_ii#o-s_1i>pr_oy47`eT zg>-rFey@S&BKGUoFVoS=G5`@ylddHG#Z0+G-&hwcG4v*ySg#_R0HUEp06R3Xx|$2+ zfPslg2C+^v6w(vmS^*=vudX6n2_a#Z(&K#w=l0E;31GtwWzq8R3{Z9;jjRXK5#J&A z<~zkGdPC@5al%#k`1nK`01ZaCSQ>!x!dOks^B{7I&XSunlE!~N;=4`-a05p$%Xbk% zR%v{tpGcM4;mpdLD|eXx*47Gx)()?zsHiK;RL-SmV?!`o4$|pL+6NT5;}J8UoO9mv zw$nrMt1UlWy^*a764;3V$9HCBC8wj~WwuH_WxE+D&s?yIG7td-03F7n?HT9#Uw`}y z$Js1g6{r(jAf=Z3^M!{>tdxNm+{VX`*Y-N*YS<7u*-M1IPFfkMFoU9w+$kVcwzlW~ zjNtA+Vuc#_QhB!b1rbmPqQDD{_%NVA-i8~&@Bfu09)O&abB^j zk06#Mi~F~`{r-lu`0Lg0$FN6h>&ZBH_&l%ayGDoS_-~!l}N`X3qhnxXPa0D z?FvU3h;@!JZJ_IDKy^0FO6SgmB@p@cV4y-r4!ie5*5AHy;~wzLyWuyqs@)OS&eqzx)W`#b+1J?E98heH7)&_LdsvV*K;zRP zM!Ct8l6|}{Wj8P4F~eSc1N{tSiB=*5Vi@3rQ}_2dnMigTbyZ-r$W0P9fJw*#eWRHH zU(i_4nOfCM{cl9#ht92p57I!J>O2)yA@)rHtq2>SW&|(Bsv`GBBK!8~=sy zAmIFkP~onDt_L0kz!X9ad1eB?HQWczVghphV67H!d&sH=$;82GkBWnxW%ZZB&PZFj z5y<5F`ucwL172P=C^KyZ($GLW*j@E18L43KyThUcY7(kWxS2Mhh9FIv>gq&eV`I_O zq@<*qzs@+>dYxGAF9&nEUpTK@?@x?1y7cc7FT*7+{rPn3^XJdU#}f_y4m^%c{Lc$NPN4xul*rJywsugHFDP7X1u z8rUg3w!VUvAfTYg#lgKUj)v#G38H>{mQDcHm+|nzp*<){k#ZS{kxlAyrEC`?N?ezeNLJ6zGg2MjcA%lRx$fUD~$b0CgotGefDh*GO{w#z$ zcoOr6t2HGLDWH1^;7mtPF9~M6>wI$f4<<1wDXCXbsQzhF9-edv&L~#hXMxAa6ah3W zrU7H1^wM#0abegrARl3^6rkS#695Uoq}9(we88hn0{#x{A328b%I0vE_M&Ro6?*t2 zM6EbFDuKwbhjxMl@vk&+RH%_60Zv3C8{@UBR~4kC{h>=l2N3~t3Q}E6Ml#16%`B$S z^Fcboi;I~^&lPqUyAMp-cx$c`u`2DdsWLZb+nd|kUI3njhvdtC1G))3PCslP3_@TM z_Zn?4>B`HaK_WhsfS%e9A~8cvpylP2RaG;yv&amEdZEY4Fc0+8Yme@da+xN9B^Egg zca#IB*L-GfwY-kbcko_%^7X|4dgSEmZM#75oBe)&>3@u9K>D<(>M|&0y@aTmo|{X9 z^Q(b*h<(iA0qu5r&GJI%uPOd`EdjtiFnI*+5d$-`%zwS~`XGv2kokWhBY*)fj8v2W z;j*o&0bV2zF*t+8J^)z=I+aSD;s-KKfQU^{YH$#w$LQq5O&+HBWhghlfB)X7q($=P zWZ+_+x4JPVC+0<*U^es|A{(Gbn+Pl`>hM!?Qc@c9O^~SqWG(?XJ0d5=0`KOhnGKiP zK%itG$Du1@XvV-H5&_N1ot2SHD1quokFRB^P?prod&f`_P`62N*(H5ROaz@xW;_q5dO%1l0%k?>_~s=>zw@$bMcP z%7B)BLtrSiOa$vwAm6Ug>V_-Lnx1~mVH}*qJ?bnBzed&$ne#xbf6!GWM73ZH6OfTH zsjI6a_^}We=TNI;5vD~wFgUmnEGyUvft3N`QC{e1?VT31P&HPqfT1GdxU}>! zQq`?0*L}gNv}25hBJ=U%#TXvD=OAG*;Ck54b=-$3iu;%YE62=#$Td#Ugj&gm{2@jA z!{0`HPBTpe`XI6EAy$59N95W@C0u)&Xrz2uDRXS2{@9>Zm+@vzCO)&IG5X*85 zhG7Pcfh~we0*@6&=Y!p)u?X#=pw40o^-T{b-q)5xI!LdT z^=j>7_q{w_BO{|Du=5GGp*7x51Oy*u737j73G@->w{t%eAcqL;51Sv|fHZ9%^Y9Rl zxo-x*t88FU2|g8>YgqjJ@gpmY2bkJOqw|eBDQj7OjKu-U5F;EJm|S9p!fdl}Uu0uLlYRJ!gL~ONn9TrZry{2sj5dF;tJDv;qj6 z`dhO6x;9zBOY6Z`MqUbJgaqKU9yW}rDTGPAFM{3RGh7=RGW!61@KWoEw=O5h6a^v* zJ6~XpV(1EFA#jQx3xbJU3w>X6JLn1^o$0R;5ysGnUK%dz&dbkdgQk}`{Fs!SOiUvg z!umiq_S<4rG^C|mk~sb*(o(nvO|{J`Kva-!{u;UMrXVDJV`5@#rvKt^_Cv^+inAA6 z3>gwVuiq7dzVRgF*8%Z05>D2!S$kQ_u-R2g#C0f-^Qs-57-Prtt30`0_wLRAE~(iV zk|B0~6t(WjBIOII0U)XP1q6`#0`k@%`VBH|p#OA{&S{nQSqGXJz!HFA=B?Hi@`X@rG1pPX2<^`v5#}nub$iwN8)8^%| z0!OEN^hgO-xf_}nmdtV$WC(|@I|Na?2KYIH zFhFd0$PHs=ijbr?IJi(4MO}ACoQhx|qOPGK6Q-92c9OvpY%GWYOf-eTiv<`}K@>fx zRk(Vl_Ty|zU~8g|j*f_h3jS&<27st##uDi;1K=YaW~7G->Z}LuWVN)lMoLohGtA^M z)#C$0dWVab0g>aRVFmVw!}_Es(yBq|qo{Y0=dmjg5Os6TIBjm0&;p3tU3n?coG^M= z5MTiC>Iy1zL$M)y_{hV~+WI93U&LkV=}~}=%g}HG6QZ<Ihe1mI!(h}vN3bi0M4 zeJ;O&{1t#Sg1qg5htg=<<3Pv>jhd5#Or(`}48#=V8=Cn0$R)r}Vs3%=6EJGzq(SkI zA6+1q_NQ;c)=Y!9@I5cd{Vsqc=qdpx+RJnCit4}W5}m>1gJJF8>4uva69UWbyjyo7`V#)a!Jp8&eF zC9etWM@V`YSk;O>qXZp)18A5)onDx340aLx%7Tn#J>=w604>x9WFZvHai}kH!oF7< zH|adMuUx&_0~d-MhVnA9;dbZl-7Lgqff)$oiiqDDX6HgVL-H3aFoY>=g3mW&e|+G8 zG$p|;=~CAAFu=DSSptQK7{4%Q>#(<`i*)b6`N29Z!rY`n-Dd)1sWxN5AQAog_3HuD zSL6UlyL6~xSlhn<(k8%~qIm35u9Nep0jL>VDYV>;MOb8>=Q;3HxlDV+q3Mm-->`k= zHkL%gMrN6H-tz!fxXjZ$stXv&QhaLWKw3JF#yaM=(+>Miw6h+qq4(bfWJRECR2 zZsZz;AV0-_e zM+ZkceS%5&CCJ5C*9AI7xKF6=;i;*q#G}Z>-u?UcVMgO? zNIvc>uoFi;4=oB}!O}86{LBUA0cZ@NnJ1c@`NL4b5^XQ`-M`$&| z^pR!*lA{ntoG{$1F_aHA1*j4jamnAm-$R-SOlpO!aS<-C*TCw>hJ~7ewvKroW`nj; zsPXhb3P%wC#z!FTMtuV?)^UxDR{_y8KwOf6P#9jJTAluH11%rbw?=00XNNXBY0TS%dBgLFN`_4Uh47J?}s}*zI>c_N1gSZjGmD zarGrXQN)|`D7;Tlx)E81fRx?v*i|G@vIwAo$WIN~nhEm`4;dL5F*8Wd5~ULWJzV$= zGQ|!3;@kGz$kFlQe=TI>>Hj*afBx+U?XwTXkFF!4`b70&p0zggFJRgjT)UqFXVzH3 zP7Otd3JI)bk#|qyMwd=iLs1Tf{RSw$F98}8Oi7tDyO)2~QVR%Z(#pn$z(^p7Wv>fh zjCgyUJ(&qSY-?|qMYr6zf?DB*dI6jF8HJ3^?|rz3bZjA$fe&N?@&Ze8ed>h!Q~2+% zUr&pRvl0-e`-JXd-bsI0%b?s z-q7Z71ES|ooi6>v`IGY{1~jW;zMd$Of#7E6ok#3iI+V$%l?v?U?U+39CF6|5GmgAb^3`v6KrZAd!sFmOZ(MpBN zh*Y3|${m`Bzx4$deOAQ>H0b0)u*Cw(Vp@uIh*i<>$t68fwL z)jBlGW-kxi=?WnI*V~8Bh3oV2dXF>&?Mgg(?N%xUiH?0!yiTem&+m!P+vxE%GWo4K#8Qi`p9#x}2h9n2Wo<7wUFeGZ-Efu`KC zLdE4oEv59&vVVI^K1*Kc?JbCLHCcDcT%BP>NpubNQ*0|_KHLw_Ow@Z*q>wAY*BZ5( zEgG5VMQyg_7MGzF?6|?SS$fpmE7!fotVVjMUwp80yi-9^`2{$g$7}3Q`g7d+ z+Ir^gwnjb|U4A%0%OV@(rnDNPR%TfByykSkLi1JEm~6L@mp1a}9qx$~w`EfLEQ2to zeUBL7%=5r~5!s@J4DDUAmq9tp+w&i4w^yr2fD#)x%pH8jGViTuT|bXkwyJdWJ$1-Y z*>u67iYqPmd1bHm3m>xW-!&IZekT#DHf8sg%AO?tFpxCa`{GH$pI5@1q9Nb>h-I!> zmCdlMu#mH8_2388N>0N+iyL%mBJBcWVt1I6A`D)9yib%p6brJTtyxyS+H$5Kb z@6|a)F)^Lqji#2x_6v?ObL}w;MWhbLkBqXCQd1eY zw#zTyajZ1b|20x!KmP-!Sz%Bl>ZlGwzcQPsIOa(wCWb3>Z4q$@FlUh9jj&e1z5ZZfe1$?GBdI2K^~U|vjrhTv zC9h<;Jmt|_J83~%A|p|zgL9t_`BacS-o49_r?c(4T-t!@hp31UM`E51|U90&;&JZj#R_*C$?7x0r z9aZo*LE6&o5)IkDaNsBbm)*`YyWzM~qhe}R#w(SYP!C-z4HcmcpbD7qmHL|3?kyKL z7vqILPK>`ZrICx26V2lmuR7a| zBbN61rKW&9PYeI)Y<|s_{1`XE%lKHATqAd~#OUMoSsQ^}cM1S1xyJA1BzssQ&5E$7 z?BSVa<*lJN!n_U#OH8W+b$;Q~^Aozh%JR=qnmt2OfWpxY^ykA%F6L4BuqEb&EI)!fatiORhvw8$Q6EasPc^{Ylz< zT#c8qhZMiN0tnKLEo%(y&a#lRc;{COFg;zBx9ctYGa~93wsXn9(#!vmdXp?EjuwpG z2#vMu6ek<qL5}zR;0I?O4qBS+$avCCtk(!%Zx6 zFlol+iFL71uMv+WM|fQ?NBj0m&?&ApdzJ2f1ikswHHGdDS#2>j_wbxb%(o2>JVy)# zhSI}7A0DJxwKH#QZ+BW9-YRrg%-Sc;4LFv|9;``Xe?zm~x9H)py`cE-6U;kR)%Emm zt7Igp@e@2yRyJZ%sg&Pd6tL{9e=EwMkgn$Qgkwcsf~4(tj#i_Lz^( zaQ$+TTXhiDWB(Intcj`3F$0cRQ)*iHsC#w^kS0orgT+5|y zeUHt(+Ues*=Q^XUNn_w16fH!W4W%TrT}o47I5)!3YcpGq+p^J-WzusrJ5|l0S3P&P zvx8f!Z97&%{+N~=Q+i3;c#rSamV0U+GDui?UaE-d8@5sw*~Okge@qe#`?BzJ!tKSPf8plsdzcld_fYe<-d|P=~>6=Imx-b+AVX2#&66) z=yY?2`(XLWTSMvnCozKtj6&||>SA0jDSo~+hxrLqL&His3bX4sLRs#l73B-5FcHQ?H#MYWQNw3G|3x zmS^ZBOtQtRGc=q|znmn+`4g;WWvVg-kr|mha>o0Aa9FTIp&81lzQ9-P7q(P4d()n3!k~^x zx9rfW1Rnz?D?BbYh_~=qJ53Kf6$I2In+z=W*j8c-?HCU6$mKt6#M8?ODkv@%_9U@X zEBU38Af<|?QRD3lcEJ{7(VMHxpzci5NLk5y=(RNBprSB9io3RYgOW`Cth}DyJIVex zZxhmV{5}a0@b#^%6ye~g<6pY<>vx?7rlon=z2-j!RTrwLFB_KY|JnqQ7xWrZZWXL1Ke`wwk2RPFSJEMk3mZfrYx-*{8qs zGz{N&S@7al@pEHJu_$kh720}f&t&hwnUaP}##T00i#Fcoom#2g?)}($q43YiA8O(h zHY6DdsoZ5bE2D(m;y@?;Hw)17LFH=tZVJ5m#)H)Hv7k5^1!>05(b3->njfGyiwZeA zyKAyr4&_ReWGcNpsM-gVpX{*zl&7)iEEm0HemN>=T+wbqp$>oK(En#-4a>Bvmg|AK z{gNP2l&GKH;QM&_hQT6}z(Zwyo1<~Z;TjUZ`^Rqg1df^NUql5p>f;KFiCyV7WD$+b z2pCt$JWsh>KTS-Fk38sT+kPfITWzcQQ0l(@fKjTfNg#G_Qn6ZNwlmoIasSZYo(_8T zl-E1!4eR^1F_rx)>Uwo?ukPQt_)*z?lKhPhIgOPZ(?p(B!vZ)mT7bv zYGkDE^Ypk}w{t_s{K^Q9(;ZsQU32e13w3v!{qd^90ST@K+hp72;7y)z$Gl)3rDA)D zKX*R`-&V5f%6qi6ZJ*EKE=1DPdgAHpOYvmp^9=RuSk>-Dy?mlzLq;Iae$!f;b?VRm!Dw5ipuCg)b+@ zo2B+$9Id?a^cUZaN>gTXLD$bO1U^juPOs8X5*LBT))l?8ewPKliof^W9%ePyVJT~n z;^`+e=HEa+MtupTK@Xi|7Zw$EavUFqQ|obSgg8u^y* zydn}29r;94^BQT1uddsiR^&-W#s=-%&-cTIPG~5tq6N;uBN!SAO?CCa=O#3d4@MFR#YO%bjD2;`+1V@geW^s0hETyHBuD zoBqPyefiyUDB*+MzYg40?YCT_;+D@vay)M+X6h)bI!g8?AZvEt^_ZT4W-fBywHJ0m zB-b)BGZQ6hc~$ZauL!#Dc|)^8JO<;`;k+c|e3ewGUG$ij*+pyiS0e46-M;J6P!SMMRQX(gEo*CTY4}>RyL#c%pem$ zK>CNRXbQ6zs^NL4F9Q1KQ0Vtv6(fz&@uBKJ7R5pw^MvQ+9sBLZS+S{sZ(ay8(i|!5 ztr*{C%6L;1ZvGj7QxQX)4#8}N9cr@*Qvl=O5v0K6}yRkAGUR;*F zX;Lky)nCYTR!mQJqCVU0hF{&9#S9IPrBSqp41CjN_2haq5$RK9F;Z1kRhK|r3xhXi z+?K+Ogi;=-mLp+Rak<+I4ma63IA$K0aIkaSzxnBPU_cZrE@`o^?x;VTF(zeSS<|Rz zkH>hl@XWC0H~4=}E`54vX-UtcH9UM<_EzkyBkzCd&ejL%-i}G7dvWSXj4~-#oeZL`f+u zX&H98zv^_&DKPc(1qaQ1w^Q9eUTF7HyVd*G$zVyhWKSgwIDm`)QEm#H>@U;Ic(rQG&iixJwcY7(20rjdX5kyX%_1-tD*rn|hZ zXJtq+UwLzN1(b=17pORoP|s?26J3iW^A2BM`kpSq)|0J>WA@hR-h^s`v^0xWbsN{{ z-HeP3xgY*| zut7JrW|y0b>)K&rV1hKATY9<4=AGQS-^q)twsWV|uDfmeUNO&m;-@0mTuPH#TMCIR zN2_UFJf`{tBBDvWdSN;R9!VOHar`b<#pAf@S@qx-E_B>EAybPtB@lz~o?6&ezc@q| zpnm6iZK=vmj=5LN5vdJrfnRxz`!-F>Mw<4%I9lZzp@ z^HzF`nEKAGKFR&r`PgfM-aLy5zxwdri&&l@7mj*yQ`z~&`2?Bf2P))+=K&vf9Q*pc z)*_NFbf#t~I<{1Qkn8R&eae)Uk@npp+K~OYI#kYVuVeUja(EUher;I|<)%Ac zs?1&A{!)&#na=A1<$LiOk!a^&>OVDiawmYT@K-opc(N1tj-k)|X^%9ptX*f zICY_*1nbO~UA`}3ii!k)sz3kCdnFW$x!IdyZUPD*5Gp$vci*{JLt^Z26&n$U3G-da z!SCkt=zfwP>ZVyxG<0@UZ_+a`T&Znn`O|SCpkrZh-^8jn;ZnVH6z(m3Dt`C7K@1p6 z-C9}pH&>GN!Hh&7aionJ{=E!yOd%FG2s z^w^dxq+sLYl4NULE&B^NF1|8i`W2!o^*txWcW|Yb&12F!eL#`NUEM`*Bqip?#dB-h z>mfW^IaxR_$S>7x@kr&HsGkE^e4Cz+Pp?e>A)o5Nqu0&Y(A2+Fn2*h4g`b?GoPHX#&s)3)L?Q6L@lJfrQv?RupP z)t|MeUF+K`qvUwxg1-`Ges%P9iF9-kKRoq0d-NY1Ri2w{#|+#!{tk0GbBl|@4{tw{ zm0itjlaP_A8&>Te$NU&o?q#MtiyCWtQ|dT%Jtu}Q!pSH>16j{c5_(6uczzYP@bNpj z4=!<;ZT=B+E~}p93GrmgdLt@Q^B!gtB&w=CcF!c}1t#XWT{{o++W#KseWWganhSqf ztfp^2KaRr}ebaf1nmiL@A^eqcfrvLRH9;7@WrW0Voc|?8$^#l_&NQDdnulwQ>olC7 zZ$AZphSlNdMhLx0=3K|zorch@f2VBNrzh_cYVRkE{Yj)}2a47F8# zlyz<^=M>rMer;$tdC*#M@mi2?Xb}z!DG`v}{O=uap0qHYnJM^R7C*Yp<6w)f*mB_g z?FoiCQ?n<^Vz=neVpTsqJbi6wFd-vFDkjhRF)u--F7qa9dOn zKjlfJbqG9%eZGVQe*SzJuCXlX!@m{y_z}hWMpW`SBjFTG@0Ggmv#*R)`ILNv4HnUU zs;No#Af;|XCH^do@}0A=un_(5ZzuLY!n%YPA?MilQP)`jH0^&_NZ&7iauto88;s4 z3Gm?KA9syXU&=QbvNRtmCpcZ~7VDh20Sh1}IMG8WPjZL($nR#|wF#_zKqLH55eLk^ z7Y^2p=K@n@SEitM`uY05o7%VpJ9YcVj~~{nZA>9dt-qIH5%ljaWyj}G*26cU2>#pA znOhI?#OW&CcCV{O5_e#Xs&2v=*^uSy>l1;jO%T41gsA)PbA)t0-(oH(D%fiCInaf5VbN~r0RYieP|DDTOzmK>?vV}P7HX{cPL^L`-)NIz z)g646F8KBEdc2;DY()R#M8yw+kQB@uFBStmI-S<`;%xYkXh}+n_?e&$wm{JOnhn42 zxt%AumdhRa7FUQ!=JbJl->BDaDOt?Ys=4NN{qFNiQg(2BcBoXFa+TbWMI%7qFqGj< z=o%w_H-w@9xA3!P2}$i$xIvv|vo{oS zl`eHZxL&(lfp??B%fII_5bRpuDiAMk?I|4`Q3P)O6+V_lTr|N)1ntczvCQ4BI;NuaHJ&)Iw8@^38RQ#oKWjKeX ziI4l&B*Cw_ktzX{&P10(e<{;loCEv1;rYZQ$IZK3S$M@uACIuBYKDdnL@4n;-=;$g z{a@_8cRbhq|3CU}mxdAz4GjvBJu_M=l$9AGill5ITf3wpdnJ{<6Cxy%k&zWyWv^s! z&iyG}pX>Mio!{?w&bgiQ$2qs-cDt_Ib$P$NUeDKaJjVU;c-`*;M<@2Mv+t;@JNIDS zlA@dZAJfiB+%i^YnaH&4sa$@Yu3Niebmh3UEro)=csDk&))K-{?yNJ-`Gx^BJx1~ZzWE7 zx!RvEVv+Q5#qG4OsPEXvU$S!Lc5o1+aGPFRTf5eKGA6`Werx+EA680E#KC=6Rak=6 zW<|@PPb1r`n#*$-mU}5_cc`uy+7$P6`2M3qOH%GQP@J4*bs0^s)zk0e`!umyr7T`e ze~YT}hw+HjDICZ{!^a!5IthuibFhE$H)5y)E_5 z&|@h_I8)+QEh%EfF$^rGiKxG_D(_REGmdfYr@*HfDl1;-;vi+T+9PB*62xU!QeV9E zlJxhM4 zivCzl22E^J#zSfbG3`OuJd=nfddwi_o5%;t&j*_H##N-bCG4}#&*x&zi3#CAJ%G*p zi{=LT@ZPU$$k-$O1pq!hS7~PU9XrlQb7A1Y+VG!s+sQ}Aw^|Kv<6dO!eoJ9yc4Ca% zFS%>g>J^(i)fG>4v92wjO4=%tcK?Bp+leoSLVYaxwx}QafIGas`|Ig_fewL7Kbl>P z=C(P94a~8ds$;ywaQFId{WL zqoip=jd8uRV>YKxZPj7>I2rdAq`}9gVwYSn(%OijeMmmCtyjq8c>82cY|{x3FHN#M zqi&X5=8aVMj_de3z6md{KM##r`{l(PQ-qFNKz3D6 z3fJi4!#E@o0Pikdx>VpgHrjV+OJ|SNCmwEICsnpj->v#7l%kt&cS%3Ho!uBXP{YBp=c>^Xhrf&IutSC?^lxXosm^pmiYaygNLGQl&O zTVAsr&Pm$rBRxvyauBGY5XbG*bU;gOW$Q94BBtvzI)B9_yBE$l3tZ|M>W_m5N<-zLBaTgHoa&ocU z+3Imeda~Friv|#zOWfoA@2mzs7J0{!yo#Q`-!&=W2j}?3{Cvic^$1=s*Jg0lja%=z zI(Ec0ke8aS(32$Ea)9wpZx>zfp?~m1Y3w!mqN=TwW`)qmi>?4%%U)bF9#0-Uxl#_cVPi^<(i{R**>YZ4!!ZU4SJ49ve?%z0bh~TM<=W3RnxU>9QhUnsJ!lNHYn1Hn$8M3APr3-jbZ#oYxC2` z`pcsX)oEE2mfpEDc}hm|!{hJPDB#5P)Lyh_5ni4q`4>rzNpB>5;ow?^#c z%hw?)Dc9GdK}5RxdEgwSeq3OAcXv0%X{J2CECRlTS&RN`KDC5`0{5(d$##Iug}JnX z7x(ZRt-cG`Z{@U>J~C=rC>GpV$77~lQ*o#$65A_ zevYHtXJ2}uQ&gL+(AzSb;il~|EiLNJ9GWMGe+a%A8}S-m)hWKbq>5FidpzWn-2jcW z%C#KqDW)tIAm&I}cOLy13TRU{!tmCK<010)0tJJuq4~0*65lC`QN8yP9G4zN+793{ z$UH?#C9jGj>Em* z;#CJ{>_(@TiJZGGp{KX$#2P9mFRy*oMr)o*akt&8-*yu=dHoxUve@-dqzh9nn zogp`|%D*hyz#c)|B6zlAJ^?PXb5n75nxB620FCgYJto)6mSgoLkat|Jjpo`^>QCAG zv9~|LJo&*EAqW2Jy>$=iOO!YbXQiIKNpS||3lIIM%iQb2Or(%|KZ!gy%!rX_wL>A4 zwb60hsdlw;h*#9cb17FR&vbB{+vy6E-BO&uiCkqhWo2je&b%*Y60{41*R1PxqfyRt z6qEt(?dqRMVPT0VtExIuA7LKPa$(Wgjk*DXBh(op-A5Q{epLE8{%A^2ifysD`hD@t z-7_wMF`kv~39?ENs_UY>PJ3rKjO<(W!T%W3s_46qgLMj{nS4a9uRpP_Z*NyeMF!WE zO2bD0@1&CR_cQ7=JgDugjAf!cx9#9(R!ZCLB5?PGL5naa58nxo6UkgQ?K-K7aeD+n zPobsV6Q;RbL@*>cRZimN_C*4Qe)~f&sga$pw0L9 zPNifwrm6u88b6aXN?&D_|5a(*(`SsuBSW71_wGHLICU{6>3FeP zDpl!5trt!CzRa-Q%P4|g95YqA?d=BBJQ`E`&t18%47}b*Q;;qBS-ifAxMF12?Y1ZZ zX?uo6%>y3R8lqNm?$Iooh3hf{CncG9@@3U1ML+cfuWLs!hNx%7uBNx0`q=JqhF&IM zc0~_=U+$eMbEX1DO1OH|@{F0q@dvo6`t0AEcK2oxMvw*B(Yo<4O>@aXsm>}z{ty4u(LFL|qC>c&3&Z2REDd1Dtq zZMljx?xTB0rJ3U4MO{&#)1Cf2>ux$l?SJoG@)e!Zl3fL^p-!;(c`-u!Wac(beXN$u zQ;Rsd_39cwjw*hO;x*6WS=~JD9t#P1I#WB`Rl8wC^pH+*tBw28>I@0P-#^<7bMtPU zqS4h9e&Z5q?!l2MV57!q$aX%{;U*~xbcXl#JDGAFJAOOPTgs#6aN~^2~c^93ezIyxcE~oT|8z+}p+;KcS+H~o}oyl*TGFDPZ#9wI=JDt~r zOl`vky7L-GPu*^e{mh)2F8HDBFaw9y`=`?eay4s#cqt^kb~w(iq7Tpbqq5d<5oN#3 z%o5ZCQ`3ciwdbj_wOqWaZEC91m0?GRiqsLPYv*$J`c}E6t0@T zY3aWzsR6Tx)N5j4VWfV}9_wl|(RzXUhNifGOvsBDE~5^O-?mvU#Zhw~?F+GOJ{QW` zdo`Lud9|ZgE=@=1)*Xf?!v%$fN5_BNyj=YB*CtjrTgSZ*OO1qtA2iXxH0!xyJH2 zqroytgh3aD5*A6f0hP6L$(LR3>n_*%>f^yx^}f{eWt}yQ?A{q_5&-s ztF9AomvHGMBk|4`%&6YY7%%PJ-t!!xy+)ReK&c?9E_K%AZv{ZwfW7V=*Ldp^i%MGl zMy-rO?;gb%jh#sF1rbt^1F$h{?gOyw3wnAksEiE!YOs||EbjBT_<3yH?vqc*kx{d3 zfup+-0Gf0(9=n(KQ$t@RJW6_QnEj!DQRQiF-m;IdK3T&19{$ubTWxP;R6{egY1wYG zrrj1s{Wtwn`hQ@yRo`j5D~e~qjfz{6`tsdZx3}uFlGJFr}OVV+Iv)0{y8u$WUMlM=U%+f_2mc}>ogU)GOp-lz;X5+Bc=I= z$GDyE$TM$x8BZ>Q-d!t~E+$B0EjQCEFX!%Vz5UJ#V%5r18{RT(d>H)w4f}S-gX)hl zG-;-Lts^O36K;C@lib}Cdp?NX*iKDhHqd7`HpWzVWY5r4ct8 zl!Nm3;UV3xahm>m3LPm!*W5@kVz}0^JigH}I4;?9S#->-|7`(_ zN{giyhL00p^_BNI?)}|ru=uC|$H&)w8!k5_a2yP-)nXR-NPw#sbHB4j!^<|hYkTJX z?FG1h{IY84T9ilKZ8IvV#j@MvR8&r`4U@We$Y!0@FVWnj4vywu-D`L%bUuInoLlR7 z@Mms>qulFfGt~V-p6ZW61KMQ%sp=N>MGdKad8J{v@BXFLA{{5rv+tlVt5h$liWJl_ z{A@(F6MVGX%X`8&gTUh74(6n?tR@a?$<%d;%ejj>Q3sOzSm!Qg8def=Cf^~vuiZ7z ze18ryM7)RgEtPN0_hVxYT$y!7Ri-m`yraG1uE$QwYR|luBj7qgNT?mN;xbF?TfGh! z719)3n^Vqvu=SK^vtul3VwCJE!<4c_wNQq4)g4JsoO;(Ty0Ogd#6!JDoEC>=ktQ8M z?ZbRlm41?}<_a0(N0$sO9>g4*NSY&Fpcxk1*K%fz-bORbq3<*+Yg3Q2&PF78+0|HAGZ<<#czR5~n=1IqLy1pG`tf^j3kT*hS9``!}py^*y+!BOpmK2ifosZR4RlYm~|#Pg-icbZdBLuVp53 z7u`2&wu@~QFmC!-@_R|y*RRKuUe8rIC(Ze&eyymQ_?6|~EA}ZSHrA_SOEnXl$;pzz zT6L?7-!qkUeo9jgd!6E!^nd#FezENJt)N*Sdy&SS zkPUbUm+|4S7B#}gJ-}w%*H=`sQ5{=ipX->ok#Rm&kwMMkc2Jz`SyJwMK|RN0&IZ`1 zxVYGOCl9V+RR3;2OJv~3hN`XoO^(^_p4*z+e=^#XSy@?r@_KR#nWux&%zEq#D>v#2dtY}&BI7oYJ_M^?G-xH!eotHyVJw?7@ zy!8dA&@yb(o17C_wpZ)I56+4?t_l;c=3nCU=8Z*k?fS*r45gnP=%G-UC%Aln*A!$i z%>en1zkclAX|}p^q(Q0h&D=`R!K`7ZTut`7kK|BmiA5cK;x@-Q^RDzyDl>wi-4&*# zLFxA@9JR({2asfbfVa6?yYqgfte5CcanntRN8G!6&@+R;&WFo5tys|4*Y^~SUTLF^ z2jjD}{zAG$eF6JPA;(zxnR8`T<)7+rM-e|7p)1rPq!dFr>!GvqT$bjQt}AHC0=Tj{ z=uwYUU`^roC76MgwaL^M(nFiuKtT^M=D|u}wVOPJVv$Mh>T0QI21ZMuI!O zz5|wP5bqP$}=C+pY&#h9P>umlKXS7Y?1JvkS)Y%ZG3np-IA z_b9&qTh=#TMtSb#&vPYRX$584ewIe$oJC%$_+l=HN=iYpMx=@}xp710O|aRkTBYj3Ff_~%rAqT&m<)Kk;?`u{+2-FNJ;g07d7bLLJL zmy~1ZMyWgJ7ye5_P2t{*^l8^e&E@f%u1lQ2so|(myPPQ&w1w}&I#ghn>^)}B8@*pM zrMMz==O%XQJ1JU}x(WXLhnwT#&H9v|y-6xbI#0T_=`@bbzNVpiG zF=6(Kq(+})HSY-+-{R!0%rA+b`CRON=81Al@4dhuQ(QoU1y!O}Uc1K5Yh1Uhbc~DR z*oxs?gy_FJ5=ZVmI&`y|-7mYiatn^W&RFKh@u_L1+!NQPViVr`RUXT2+%j(2MP2&I za-g|<LRbNq&DY`@c-l05VA-I+rnVNo|< z2Q&GIy$TDvnO1Q!wDh^DiDBnMMAa9xpFc(!p&1n@)pR@l$|_QD<|I>f;!8T|%vgY2 zTplGeEg$XK$ESDQEMgy4;Dpo_`ss6$9KK4x_zES?mIFltf_(=7P&~8Io$*^8n1&^& z)kVBhNK@n0U)*hL>2fw^Q|FKV6{x-9vQ%MnnNDE?r6#}PPEoSsokbJ)7-<0EbEoRYogDkuLS{IKEtsa(vyB@ zdZ;WD^AR!U0tR~&5r7GbU(w%FH}=)>-UPV9-6DR2=J7J=n%z18>1nPayyL$TfboFJ#n%xw6^`Pdl|$xDJ^%>&6m|h+^NvfL3?uN*vaRN&Ys(_ zH54Nh*L9R=c}3>`oHeahT2=HDD2uOtG1}vfH$PeB!>hXit%`RK?y$>bLE&ic^05(Vco`wy%(=Z)-lYY%D)Vv|=<$@gnZ;&donJj}qq3Wg4S5iL`@55iDo?tEuybQ5SnPLw5egoFK!>)Edk)FhZ13Iffi_|t5faL>lu z#2?<#CH?5Dr5N(xA{8P4kvH!r?7otwobOuj@rOcaHyV4I68M7lXXg4f@3<#Ka~DS< z-l1yyEr}C9tm|ttRy+x{saXDvmY3nIK1W_E%Md*K&F7bR5^U6$#@fG4Z%JI{As>^t zxBBWg=T#M(j-FAXe_f$ny#|+ zM@`{IblM$NIjL^6IL0W(Ptd{SkY2H-8_w%4KK32$uRo!_vGx7C;qim{68bWaX@3?DEudeGUhjq_qFZ?PurEuA~dS9UfM%x)mdSvRZu z+#s8;_y)QI&yK)LBU4*M$xgc>5v|E3-QHhR{&6ZN`!F?dM%{5AUrqtOPvIfN2-8m9j!{k8(Z-q%3WHRdRBQWJJebx~ATGa?c?W-4`Ykb!WEUbIY6d z)paObXE$tk!|(U@pqLxaLxTm--24;$k1MGf7n$>HTxv1*j>%&F?}u%*7eB<`A6)bi z_{i;Ff%fHL`X?ps9+S!iAXLSANC(M9hV=+NVv*lhH8!JA3JCp}#NCrwg371ny8$$O zvRQLMk#rwi7GUaG;^*gQVs8Giw>C*0#Mc_7tJbYM0TQQIbzoBa4Q{qzdPC4CP@E56 zvAw~%y)i2@q;vf#NwmP}6urCsVBJls2xA;_IG+zj-Dd^z*t7a`67uYt&)C!y{x&vTSllD9hn8v)<-~~-TD{(WepH}}Le8WZ zrM#9$uh=OxR5x~}Da-NkSbvlBd2rq@p@5+PZ}SgU4R|ukFW#@jyWx%4(pWxL(j;}+ z&>*o>V8ezs7Ic!KcdZjFX3Az(Lo zunzc)!wSADw9|a0LG0s(vx`AdA_qx^mA8*}c6G4`Z=YP{lRbH6xbORBkSQD{Oai_mdDq!TasgWm?vZ$hPa&bA|zP(KU7tIFw z5AwNL=HqsZDrRQf!y_ZU*m9}2ehZXA7p%7-eKY8u=U%tcJ()Qy2ck7l>+Y`+qo=2z z$gJ>q`*w7*H~XKCo(<*wH`CW|(m`_z-p4;_Z7m39-^GUxr5o?ui~08E&^iHP5XYmp z=FbNHWz#}73n%A#P%ubbyvS%_X*mGN4vJG|rWh|D-y+KF>}>p-H@Vn7RB_;D~sACC?gxhNFya>z#7gR!KuI%XTC8MHET z@)O2;8o?W|e*JnUkotTmD_aj`EJ2$=#zG8D?gCo5=6@tFY_KY{VhcJsKg_IUn@m;c z?bfkR6RWZC^NgM>-JhSAm8gLH{dx6i>86FtY+&KrhhCpQKc^zNNYBupAE`%Z>st6x zxN=(i?;ku>K)?6jzxaRkEu>e0ZDKcQy9RHd(<)ry6_xPyUWBlX%$(c{5B|a>f2kJ@ z2*j4c+ApGD1wMgZr@5`|Hn?1MJIg|-+}sxCB3wIyMVR7lIX7$nj6-WDB_47-yvB{& zasIP$YJaq~y=w0KJ8x8*^tD++(0jj2RCEW$1k6{~*47k?tE(#`PtxBnIcyGaesv4n z3AaIjlhe?!1N$Klr0RH4-l)OF)6>%>^iK;O5Dr!HRdBITAxgV-=MI>L=&&c3Qnm}4 zP(Xg6Wb((HUwq_)mIvI>fY6)YEo<1AfOq_pVoR@lI@ZlkIcbBd&Ce^b^;7<4K@`oCKyPiKP_Q=;{N4h66FWP{=h zu4S)~7f>3I!-QU~O?*K0c;P`$?M8Fk9*~VLeImNV5X^`QMav%2vMdGzLNwT&<$wIW zAInnQt`%IU6eqCg>}6wHbLY+-s=o_x@6>?m66saog`vf-(G0%Cs4?R{+L0F;-tg=% zIZtES(O>ZbQ;DG21!Drm@KVYaPHhVKLjIc-!o4nozAe>yU=Jq!4%n5X>Oe(t3p5-5 z%?6>z6ztiv7z$-hIQdH#JHKowFW+F*->9U0@y}7hq(A0~e^v%M1nnzVSSx~174ny-36i!FFyXWZ{!vy zsIn;jT{WgVFvy zILO+3`R}f!eYlE^=?xy`H0WUPHW(ir_8-c@uU%gJePV?*uvSMwuNSVF&c9~uS}w?4 zynOkRXv)Z)J^K+1QnWiDRyF@4@2s;}dX*=e8V%f1IG9YqOB@fPn9G+hYlE;DeSXRo ze;W76-hP04gK33{_yh2sod88%0{A3eaWu*-EX6PnW}6ZGl~m3FJJ=A8tY=`L24SJ( zcO25y+`NCscpJBs93LNN7GC=ISFacW1?otwIC5M1j|bXKOBDisk4}?6&+f2JDC)9< zuvkt}UPoDutVH>uC(+=V-Ue#7f0mzyzg?mo~y$(_}0uwVFa z@;%v9VAXP!X*!uFcE$ZWJ2+ffzrsZ-heQ#v+?~Q5Ft|#bs->Jm}JH07`sAUU0o+Q zBVWwp?&LBGg8Og^FoG=W`lhBVr#*jm7CsPhR%P3CKzOCQ-sQ{8Bf{v@0Q&^9!poJA z?D{=9Vz^9V)bii)wkV?0`FjlmqFd&8W?{}Br>|!XfdM}?L%O3u(jyO@o~vN5F8{}d z&@u0ech~?H?i}#ka6*g_Ey({G_2ljFh=|?b&n>?&-#LIiNXJZeD_%|Ty1~Bb;nOEi zoG=40$C^jv|7=n81}=xO_?(}AvO5`N*ZcQZfkDs-%W{C3bz%DU(-DOja zrz}~%#wjZ50HqlOq+7Tzu7p9m#d7vFv*6K%d%tkmyWZU1?<<1l58#g>RDuzs;Pk!# z(H!fE!B;MOriA|oM}Db`OV&PyA8kL)FaOAAx+TSol>s+9cOPOBbPg*1eU{_LAAH32 z=>Ga@wQ{uT?utz49^yT9$$z^FLv5D(aAZ=mYP;4GA)b3~Zg*fXDa{C+tcN={OwY{F z(d}87h^I%%F`bXl5Xqgr+-`4@7+7~gSe{qHbcuH>>(~vf+--f zG@aeuIWW`E<4Ls{(hKT<%)~};j!J+}k67{ErmVTUx_=MNFT-$5ydWccJ>-`nIMt->vjk~htC@yYjXV2(y|1i0)(~eZp%Lx+qvKf z7_UKQOf_D65q8`ikWC)d)YR-A2XlOuVf|)~^Vt|4?gVq;Rxbt~;bZ5{(Sw8afPuNG z=@IZ1#eLgB$ zS>G6%?U<*lNe%J^!cAprf+vMw-{` z>ea(HDC=vR-e<>6ygzqPRKB@p+Ov^?HG>>y@UG_~9Wk96y+%0;+?7xUYxBkA;QZ5AC6HH84G49`P3R-5=}gMQY5!)XtvV%ZYJ=VbckzP|eQy6kw+N zXUpngGmgBvWj91Ai1ns3H?AIkzsMnBER50?z4S%SLt+e}?fV>%A6)d&Q>RuQJ$e-S z8fU@FxnlKZhncxYaA=(v1270e$O-j|HXAqC5^xx@Rc+e1aS12|HA>6z4h8~&N`}Ao zWI6{C#%1uegNbSxjxEzQ5Q8Df-3vanTf2|lv8xhCmN ztSoUhc6KgE;!(0eP%4*Vq*)v+&H#Jx5iClkAUlpe|6Vw_-+jRmcJ`Po_o4xVloLoq zPpA9)Z=<21$-EIjcR=|tGwlnoa56)8xV01^8lyc-A0yvueCMrE!vpZ0hGI9aT)P&g zAb0cXtiP$#%xMxVBSl+JL*oKo(o@O(-x8L^yvmlGvu}A^!rOb_W4oI z3}jj99a(;MpXBjl%a1XBRlY32!RK+yE0W*f!BoAi!TOj%zOydp8OH`6McrYHd>qkP zMNhLqVrh-yPyp4|4O=gD3w4a$)heB7^IpVc%U;kkBGO?~G8_HA^hW>Vq+a{RiRk3j zGK364ZYNc=J9e4l%oriy$Ll64YPXeCRJ^U4>{IH>@eK-9+u4=U;b7Xg0X?b8*5E@{ zM(@B_d>GuX6sMoe@lu`rHSZ?p)Zq|emXsHMFL*ot_#JA7AjSwqR-vBgq^}TTo4keu z$Oc-~iA4v~Y3Ybu#`E=5(KI$7%1M#zz+j&s8w;IZ_O1sK2tf4GkiC=bH2SwprNrG|7uFaUi?A=#`EVL>-o zp*>*;TknN;SmNIFxgGk&%uI*R506aH=Fq&GX!lQ=`jy_{sdBy`(5lfF+qddO(YjGuM`TPKOJBgoA$cdf{d=}6$T4FM}5#>OS;1ewB~KrI_+NU zFTerTN7JYCvmaR^Q7?TNB6Y=3d`hg4In*}QH0K~AGLS1W-h9&+Z0nIj|VBz$x86S6$d1+n(@oZ5$Fgu7m5V7f+h zjWZ|oWQ5wDZNJeOvTWb{T#Di9nxLDnwQhM-0g_K5UrDwqL<|$La2-u^GffZO2*sY9 z(xV6KvLlHe4Uxh|Oz>H2cF_CkoAML2HXVUU9YMC6cB~~g?#5CoMJOirXHMxg*^jXc zQ{lIVLjsPfDmcy#1)G1~efK5eye^QBt`i+D6M^2TL_Q&<3m3*{W=2!8zKBirdJrnb zZ}Atl@?TZuue%)Di>aDu=yy=D5W!cSBF(5StkQ%)bsBU_&7sU*^B64VY@m0wIhfk) zGX49mI2-4m+6JCpD2Bz#w||=3MV@q$7Lva^4gwqIF~%8KXa8nF<3V{ zL&_py;WJa*BG9amg$yAG>(&c}X-Ri*W$PFFaBbzgqWA%gUldBDG;T0A88_z#I_Gwr zzM`0vMnA?bU|L3LZC;Sfeg2;7Ww|TL+MdUWpiG3KScN@N zGjOXQUwC$RaTMbTx9w^cOYwhB3JThuxzKBW;6^@_lZr((2y+|3GOy3a%(rY_Gw#*v zY%-nCE3puxkmPEgo$4=jXOebjM5?lE|NK;wg(srZAceM1oEiPzk-dbv7(U*EF@L-H zX|hXPD&}{+H+H>@*hDMd9b|^2oHVF-d-6eb`MDlOY+)B=o{(6ftwi?o%ve(}p8m$G zfxfrj5B6sa$sCEmP$&;B;C}4qGpt{EsyGT*{i+8U?VJBBL0L-HOrPsEf!NvWuM{Nl zrrtrw(b{z!YGUCeVjqV`gl@;*BEKWMz@|GQED=I90XMoMY@n3Djmw=55=rX>j6|U* zUBaFEQd`_?pvEy2V{Cr_S;A)o|K{H=+-<|-f?jzv`R|dYQ)MEWxdEo1w*Fm_#ZfP@ z^}Gp#uz7ni2Gb|?eL3|`4LMd^-KqPmwr3f!PtbT11`r{Ie-t7VyHk`{>E>rY{)p+? zXd2)<7#tu*S1jiu zzmodE7cccQYi=s5Crca#Z}6ek^d4}{n_aIn04-d-^{c6!IL=jn&ghn9%93jUe0e57 z(ACj1LFyIcCH<}(Cri$}3?EijS8v)u*7f-_jU`dHkdS)Ae#CHRVm`_I|7%G=0nFn# zJFWC-^Fa+C_<~LUF)JX_kbb40c4-=`Aq~FY)u+hrl-myb_7pF3hABk6REW3;H36B> z6LV9+VXt5BBaH3XhFaQ3@y+>J{M;md|94tPP?5t_pZ6L5+LsRM@J@+e_`kP;JDP)) z5TG62jV)|eBGkbs`LvR9=A!-cK)f2cw6$g_k1f3OTUciA8QzB{qsI(QBSWE?tI>hZ3GW1adLkC zTyYYNptMkbqbEk_clMHpZsgZ;g2bxBTM?VKu!k_ye+&m~1d#j(3ttRd?^T9v;|H*( z4Q}Pjx0}Gc^INy_GjXw2QrBOI2|BcxN=w~8f^blIJh2+poV7?Bo_Lx4dRNQ0p=xYePiU3 z+k|WWF&O0kpZP5|6dl7NbUZn>P7+MSuu5h%npQC*v#_3Wte%CeTA-AVRM5efojh6M ztIdfEjywO}tV&76J~sdTXq}<2kh$JWjk5Z+WH%ZzPtk!7QyrI8R#vu>I0P210@@L! zBj1*+6Wq08yGeFOV+X$M3GmMTS3ViMU2QZb)H*13_uV z0>}te0B-7y|F}-=orOUxHWdlVwu(DUdyg$8_YzwHi)P<%+a&FdnCy+i)z43M2Tyf~ zj8vYTD6z^s>p0aPHo0~yHzNcX3gFv#;BzMXhy)HxSb#gMZW#E!=KJw#P_rBNNiI$ z%JF_!fy9f&etZYOb1vz zOr{4hb}6d*$kBN8WuRtq?mscO4(!8-*4`7YpRvo$@Wl>tTigEk-jL=J-5+S7a4@aa z{Y5CTgNmL=_+AiRdqvifl%DQxGh{cFkE^Pxm?TMr3JXc=PAvWNl}H|acnuU5>^?Ro z4a&A0!sIH4S+FU3TONy-Ks1yDL!O_k@MJDD&*=&#OAe z?;c>e#bohSa{nd79P_zi`H5|92y2UAQG8D})W5|JS=7RVgxdxqJ6{rNJ!MNuLl z4s2cz@kve%%>ZgGP~JApyupTt8a{2&*MJdN9mPnJLK&T6u((Htr{)ZdD;a|Q*U#Jo-FwEvtktwlh^;Xdpi zxRFVcTS+z{c<(oBm>l76v~IzF+r^B%hkcEDMlzP?)|h{5B+p4GDKZw2O(gXyv2H5H z0IGTvZF@v;_c4+x$GNg&)O4Fk1oZqOJ?#!BPonw<$*DqULaJKO;`dGpa@wA!!S7rF zi$@lC2eIkTX>s%|kVm%8O$X0;pklu1&+koQ@kls%mm2MczL0tnQMCND%{b%hD4EFT zl0cXwP@B?}G>(|^aT{zmUuvL?P5BP|Mh2@M~i?(k4EShIF$$d_P0 zo?l4Mkf@ZQ%s_H#CQ1Iesg(%#L|;v5xV}}y+Qeb9B6w2(Q6Yc+ z&Wr%9%fup zU9U7K@ZrIC%=4l8_iHIv5snDWO%MG&TNuN4i;6Qm@V>4L;$mpRu_K!>0H=5%83xR8 zpB+#GL02Fg>jV9Ti?FB@c^nS%79_NFiX0@T8Msl0Ro0Z|uXjDMBuQ(UY8>Nsm>%zi zXO%cPAJ>w+nhXr`kS4_PFQFFUM2+yEFbytq_yX}j(EPdjuIu&R02VRr?luDAWX~!5 z*Kk^ihK%-#q2a?n2T7QKTmU9WxWicR_PdckG;ZUYkK?Z?ZO?H^5Yt_Pf`+7f*6c{! zA6R2Li=J+Wlk9ef@gH5l$A}IIaurk*UL%x=dfyMbso6G<{1J<04gbfh1 z_G)oEbPzkypge)xgrrSRk$H+s4kCi+$lWNbI6vm&&Pq}waGn`MDstZaVh;#-S;ho%r&j9f$a9&f8uierhrS(VNf?VT;dMGvBl3Gjyl54`BQ+ zV->p^-%tHPb8zRs{u&p6_RImC{5IAWa{i%|tF+){$i5^A@OF!`BR0*>E54#{iLn4W zr-LNM0y@F606r1418$6z3*+&T?U7L z8NV`sZvk4TxlRnRgNyq=zU)5$$X6KB zvi|@e^stl)#_vazOGJi>w_8@qLquK1y_F?lHF3q3o3Z7+oEIw=PTtJ>OQWi7Jk@5Q| zp7c%OIPrGWV&l*MlR3+wU`?O{rB4vDt|j5M`AjsXL-6i)vr|M@3OhX=JL)XM5In~# zxFixjlc@wEZx?G%{JWhm4(0GohUr~oh&+bX(Tc2|NZ$1ZTMH&8N*#ls&)^svoNPVt zllV{-P0K3%cXKF%nwK3}(RQe5LWTfV#6Afj5;BL4nAc5w zb<0yk2XU+unHEjsC#tN3w13knHFYq^d<*TKTB<$6*<4tl)DT<~ZJBGklal!pD`44R zSu>xL!TCOAtc9QGjytKu4*~ldfZxy0Cx#>)C94YkOIn{^9v`mI?)2&BMlF&3Lqq4M z87Q-{b#dzFld3oL+l=ptoSqu;oNO??>iMaubg9k^aVjK4C%C12Dkmo08CCh2OoIhXcH(xA?j|3?H62-D8*M4}B ziSJFbqiGJ+==&M0H!p1?sh&G9Q$D1z8U*NX^{AL5keK6~leWXJSZ3uHsu134*>t$LqhMuf*h{g7d`@af{y9my*N?!MUi^&7vqk`|O`I z&!U(s|00x{CK|^wy^ZZ!w*9x*((HJ?II-jfh*{+S*x8)4<;tswI^?{w<06BQB5;tm z=5;lPi6X6bxEPi{`1%jv>qnvY_XUEEBw2lp+}5BzbwKJnuoiW>KbDZJgZ#-I^WpZ3 zhX`}Q2WhiJML!KHjfm%)orax>ZzppW5@Pf~+Q>c8M9Xn2_tj96s2?AQc= zq9pAPE}og>FZdZr+&=G&6Onqv@t#My>kkaMM~7@UQeHX=yUO|}k1@c^hda*AE@Xyl z;R8jde}6P=$V5RwnT71^!vi>pZ{SvAxREq_H?S#l&@KUax)iT#AmiFsCVz)A@4$TrvcH=Wv__g zX1;@X8rq8QzV;DMSj3)k8c-RP6gdZSq?Tg|@Bgp*+5L_C^?v5w|7Xjz^B%=FwU51k zVSu&bfH<53G@Sg2Xq7?)?G7>_&pF|z-oYrN!O~|MyXN4+79iP&66DlH01nyyYq?Oc zx#|FnjBW?n?ayh+Rv{afgjFkcTJJ*mZ%!{@g#4n2BP-)y`33GSmfo8v?M{kk8V3HW z-;oP!qsMa)EMwt0e$dY=ngBNZlXLuc5d?8O|C1sGJ|&pr|NqDT1+o4gR(1YQO<48v z=E$hndE5$po^Ae3(|SR6g9UtzRxpFGKnLuhEE)a4fE-Tc*V*Sv8-S@0@DSN#0KzJs zF0>N>S;_)}rvK6Yl^2Ir5d5hy@u@SaHQ9C|;?#l>J&hbgDfGh~IVr^NWgpPKJkBO0LVdfHr51mZSYFDv7Nq zPhEpWpRZ#B+EH(DAkhS{;c7?A-fsia_Qc*~-}yqtrc45JDCow`jv_D*BEeGDY)_Wi zhh>|iN4fq-fkX6AvDRnTtr+}MA=qyZn0{h!u{@tO0#v8K~hJX2>oC3LMXf z)zdx`a5Qx%+KMEvBf3GWYJx-b+qe81_tQSf45m>2XavY;7>;Y?Kkako=ug2|SIoO!Mf{ zem*!5`Gmka%}J*7{)6&QVd(#!WAAZC}QQ|os{T9q`p!iD;|h{-aAACf*>g$_oc#TRbqND>+me& zQo6v%wFqFv_e&oyppZh_Odq<2_e&D_^s9*l`?OkFqHV8zSGM<#@y^m3vCl-fqtvvY z(sTDpmXXbub0;%8emo2x>@QX6w#rXXq9>(zcf6EL7jVl`!Z~^8RP#-0yq4%OpA0r4 zY2lltzKltYdOrtPvN|=GfY%vACF+-^VU#AtpWIktl2;blpO}xFkcl#VEJH7b+=HRb zO24nT^c)0pIT1>-2`}$)TKtfs7eJGiL6tJ#!S<3s|1SbfBA!yOvM;ugNEj_7T%^`O z3T_qwU%A8$^^B@ZrlSKV)OgI3uD9!dDgILD8=TDZ_X9ORDVtDbM;qYg9k(ryWBlKB z9U~A0$8QN4Gp2d(&lFv z%Q9$yD^j+_-$8)?D^23Ab^|FDR^UMhm^LxyI5);va7Liv8L9+KlF-8S#6Op?UnSkq z>G&GL#}f$i0|BlJA|);X=I;$}5*ptTpJ{+@3SeAuyjNa|pWiW*q}Q&8wZl{|%tCQJ zSp!VZ{0G$ABBcULeMn^fJXd1@FaICMuKc^iQgpu*uZ`a37K5du{H|q=e=Zf|I6L7= z&llObrN@&Lh!NdOPA`h*Cxvn&bg2>f$i#83hjoeDcjt&AAorvk5mfD zc44hWL%|U6{nn4v;%vf&H!i?8Zxy{^;RcUKx}zc@@P3s73u)IOP#!Ydw*e+Ot8DQ9 zNhUvXUg&zdq)k{Ly=E9Xb_bVpx} zLT|B^?S%8I{e1mPW6@MX3V=f$;&Vd4oJ|lV1|cd)?o{o`#s2VVnr;^m0xC^V63@3) z)z#X@BzUe-W{mlokA2| zfiQX+$L0&rxi2U;3zDMlc{Ki6^wsg9RwbpW8A$VR~ zNWq==(V2)cNfCFxx+94_?lH;KhJv#(aU)R9=7SAq<<{F>{3XmEM(G!tZy1B4H%Yp~ zU$w6gA3p+=)B|qlTG?DFw|Epb^`W7mE*vU7BQbvx!e`CR^m{Pk_0m)BSJ9_ai@iKV zkX$q_mtb2cUCib9f<_B((z-=56(Dxc0RFd4_Qa7!On*$>0b;i&$NGcOk7itWp!xt6 zo9YU3Mo^d8FFyW(nlzgcWYYk>sX$gAlc<#xtw{^W8Z;n=o_tKg-v@5fo@H2^UO-i3 zG2Iz~cgX|T_axn;hx*=}C4jsJ7Qp7m?aj)psr-yc=1(F0;lB9!$)va&k`Pa9L;_`> zaVKRG0;L|z_?@#SR5=i*oj~$9qNw=>G6qjSok51eF8P%lF|*IRCEW!YtwU#Lx6uqG z-I%vl!6gaFdhP8=QHrd-$P$1XJjFiN$Lqe5V!j>(bR%sVq~3^_-|o^}ND{yg(z}Lc z6d!;lWWh<_3>n>gGY$AO+-weke%K9#IVr4rGx zdb{EBleJf(VqgFtU&KqDLO*V8#9>dFKbtPgRug!Mw9lns1+o&2PiNlKeJsi^K2ab` zx{xlR=VGKriI`DferA9=E~5WH(jC3gYz6zH>iC!9$U$^42swf0KIFF2G3`=Brhg? zG5AP^q@6eqBeORSV6xZl6cNN$_!1yw?#@VTt*~YHGaP>o;x<-uWIO=|E`)0BNph@6 zF9;g`u6>08aq&>O`(Ird>HQ?#z}|2k%p?gUrE0{P{Gg|i1-dx+kztk-XI39gW?p?M zO=5tnNDoXB0$hi-LJ+|?iU25-g-uID971XzWNax|j`_oe4ja;Nh~C{@fx?!BS<^*X zFU>njB=YZYRH-E0xZ@6jYH}iHxcePvY8=maAJil+k+@G{K8eZBdg&{h(&nZ9nlyo9 zcU8dSivZdrt!O0JGjJm&wod(GBndq;HR0-Qx^@!C+ev z*`H*us%2Q4lHz9plXojnd0o_jy<7GVo&Sqw*ViW{~Q`Y}c8W|H8Jtj%Kkt^IL0P(!lRG3pwogl zbAm&o(Unvclm55L&OEN?t$X{K!!Z^aBU71^p;9RkiYBBCDHSDSsFYI3ky25H&_GEF zB@`LT5Dg@eBvTrZ(m+JR@4cOK|L)iGdj5Hy`;YUwQQu*I_Fn5+*SglVMTdl7{t6&i z$5M$fmRx>f-4fRoh^9@eE%H*lMYuRV!`)TD$7}C*szD>V3$@9wD$$rjx)@F)(-uWq z?2z|8XBfO<4Fu~gG$G=7lLjUeL7s4OML#JTIP|CcDZoF0Nz6S6SUFJ;|L9&I3MD{iZmnIb>ckn5~@7kD>j*dVva#KrSPj1sI-oCzumITMLY(P|3qMt zG2dn^(BA`J8Cw9YkT>03yXq}X^AsDT6b48#1#$I;3@WPGKV<>B4&sbkv#-K=WooHE z`nJ+Ta|NX-)G)0iN7m+7-o(AtLelEdRLkJ#XvRBSnyr=3C~xZ8cU*=z(oJF{;%=uQ zAtJDf<)BUo0obWz%BTAB9Ynt_>6woD%O5UEfN0vfIbwT%V;E3G2?0?pnm?PqB9vSq zY?rsL{raTDHS2YHKx(0K;o_?YqxKJ57h&V0eLQnozeftcE#Ks?nqs}C_q8v-pEw8i z-}o^9uZV;LiQ`tU@Adc13x`JbUKl<-RkP{W8|{bgIW>2a!vfOPWka6ieorp1Pm!%y zQ4#Xv=BZPjJea_fCw-%%<+)1Q({)1N2+bUM>&ge!?`}V0ymEx*#G%&bZ30goo6JZY z^3Ml|^fR-w%ODP-h?yjx!&DZF%*^I-9SDqSG@`k}=!?=iE|n)t3An@5)CP_nJ62so zW5172F~YQ;zkgfX+xtXCjYQ3Inp(D?pulqd`f)G&7l;0E^0ShA*L&KuY2eg7D2cBS zJ1D0gQa5;Bym&Eg){c@_uU}J943?lzYKYH--K)zZQ4MG&j-6aqQ6V*8Ko*L==toA5 zSs59UwzeYcwo~8fX!#=6gflp6hjaI#ii$=z(~_3;8#r+O#+5@SP7GiGQjsJ|i!+-d zM%B4`5LD=kYHLeNE$nxg*B<9|VZa2@Qyo!2QF3|ywOyL?_H}F^!y%l+1hoVu_d_no)HN{3cetv3YsRxXy^H%WDlMm| zc#v7Hdd3{qo>VG+@aFAXT|K>GeyziuXU_tmREo;W=jiEmsk!b_^7U&E^_0l7qvQ?4 zN;%6+pMI#UoKGT4^zC?fjEN5d{e$?6&xvef^uoFnXj}}-5q#nV#jwU^Jm?oiL^0fkdNnA{~+wN+f?CV zWnj=9&}~Ueox#f!Y)OQaTbL~T33G3D+jS~L*vK(seDDfkN5oei+`E0lnO!5(#xkjY zE>?GGs|?BHX;=Z%ne{Y3F5$LdWo6}=9<=c2SW|yOmB!XDubt*r#bbgaLo$nGbBQ;q zsoBibDM@K>!>6l^0dEDE+EzbJsiY3N&v%LnRa6}|Y&W?s_m<1n7ZqnSni}hOrBBU# z`!;mxl{I~CnlXgcA3r5|OnbD@9|IW+b5=&q>4xZRd}Es#&EFP@Fnzo8^JqgcxeD)f zJV`gQJYlNk9SOE!w0Yw?#J;36{m*q$OX61OvcSq4-`sis-oidds<)I>@{S)9I&|p3 zftqan@GqvQW15psY^^^-MREz)o*!pEp9$zmQ>NIoG&QbB-5JWx1*8Z|Ar7W%dBL?> zbz@^`22C$ryO#dy)p0;*FAfl77Uor!bfg!@uM8EP>YdH5T+VgoKa1=2G={UFh`$DU z7`>f4XVhF@g~-J!Ki(n-*q}RqzBNfWcA0s_T98C3Td9fa4dQ7RO{{~Vq58NKv1^Ke z!Gdf=JSl5xYMOOqY;@&8i<9WqLM~hw$FZNoaP$8C`z72O%Z|~?@M1nt(WTDDr2K3~ zd}>P;NOBHaQsQGl!f^Tz%)##F?Tn0!v=|*{j`c!=wyu81zxrvpx!r2W4CX}C0B~|I zE>||Gs3453NO3#<^XK-*+1aXFN+pq9RFJWTDk&}eZhfBYSy+x2i4-+ZH;F@s4iTpp zy>LvP$3!=kgB<@Z)N+Ks#SimaU*2@y6cHIogtMaJ%)78Oh-z4GV^|%m>Y?CZ?>UjH z;9r>eIY_k`7#f<5RZ2nPIvJmcOYXm&nBR`5+}s)nC)>^l$)o+tIDOtG*`cIkQc}{- zU%!gW%5>b^)VY!1TlL$M6ncx;MuX>$PpcdmbiJ$Gwo&89`=KVQr=h=*4@~W6Qksly|+z`$d5KnQTV7K_ri9F4gWIvUZm;Zg_ zNFOpnVREm$gV9Y*ZqJ@S@2|XZ5Y9FDRrrxiw=j?mcT4T1%rQ1IGqbd{jdqVU?3V1Z zkT2`+et5&amz;RODUNaQKDr57V#8Q=QAA8=tdzZ@mFc(A^gs9wQXCf_CoH=tQkt%k} zde}`*!a!A!A2w$cFn@b`3dbT$a(ZptxY2C+^7BfX5)KXy%rPHl#KTYT$QWU1vwP1T zc!FLH4Gqw^%M-2fNXfJCXg{>kx%J)$lF^IqZ{C4=QeHHh))*o(bC_-!s5%9 zFC0BvLJFQp3u70LHs3eS%i!baO(ni}wY{DB8XX1oLByUtXU>-9UyhJ_eyD0gy*>oA!{93-4kKuA#ZxMQh{62^36)B|N_9iS4OW8IbJ91CSp+ zd=Erc$;Xcw2xNT*NB{jsJ?7G-gSgM7wES8}<&r}KH0yii%NX2jh={{AG(zEXxfe^1 zp^`S=SJA*D6o8Y}q2&z57`f z9bT{#CV65>Hoi|02X@|q1%fypAumt+pzXBv1*Zy=zj+<(c(iA+p98L1=pS{RoTh2E z{2UH!{s8p5gU^!D`^?w%(q)#AIB#w^`tpQo2@1I>?mJMrL{!#nn;!CS%Fb|`w{6=LM1eGr2VPiy z&7W)BoT}gKCtQ)x#yf=+)&&t|F;sZ<>eZm>+a$Mc-3lxJknfZz^WNU{@OiZA@XNEQ zGWOoQc{A?*vt<0jq-16NF-ah_l@;CH!+E(vrWI*rgH<2nM+I%KJAakM4y1ki_K;@s zSSR$KzD)sRmTlE<`cIq~Z}t29Xk|lRKfl$Ko8wko?`ddgSX7&xLv=D4PYSECZmHQ7 z`|;>{zystHLtJaa7&Vgh+j#Ha|AF!W&yT$nrjPC!X}`!@+Ier!O(VK??Mm-v{&A(% z#4}6MN@01QTcJ`8EpL6cSgu?52vs3o0z=i*mOEyjkN$dFy16-X?q@8t{Er`hwa%|n zf3caFq!xKlb!U?bmQL4i+<10*^?Yi>pO0JYljjlFA}?L)IeGGA$jE`jf<^`)V>s-b zR24O~b@HP<0#DQ}GBWZ6u`W+qf0tuM{K0|Z@z2^46E*n{_0_-oz9^&YFvgsy>a(5w z5;HSzf}LjbHz^)a2}ttj`0yMP4PmY}vYXe?UM5sqieIQ@U^8 zz=H>C9#68*?54g_V>76yFcn?lQ667!S=lG7W#ZO7JUxFk=W1z>TPtb&{G$a>YuGTu zaNCwG_ujn=Ly^o;8uIMfGdyfM%I1tz<^W9t#%7N_4JGrpwq)pzcb^q=h-dwwqaFiq zc3s=rxir;^)@9Dy78_Z-{BjI6n`cuvCZ4y5ku%hJzdzb=VR+MTWG1vd`{PFO%pmr{ z-)|0|`FKx$=ul6}rOSYI#zd6`@Bm3UA;mVcgPomGR`St6Ug3oRYC2+A} zJ9`VX8WeONV&T%IOHUoWrwgP$b7q_T{QPlCFMBcYKM8Cif#2g|6X&pL6fSr(2|+@F zyn1VGfX7o7hm(_zaLNFHkAKlAj5wwrXn4UMI|T~D6Y>~(x?Xr31_bnQadC;g?JzVg z$fmcmT-rJZtToU%YLW61=6+y*=01NuTvKxhHW!#zK0#U$th)7VLxuf~dPzkx19l?e zOZzT0Gz=JP8h4PZ(eeKn;P*G0vbLWypF@(=)YRO0_^|wV&JJk0DFeFo?c0|dZPv

rQO=8oJbuz7f6=ib`4dV+cQh|f)^ZQSp z_=7S&4_gqb5F-|v=2Hh!a2f>ao!?(m4G9aU;u5~wCJH}Nz64H=lsT9DBl1E6A1+}T zNjq+E8H{lGLab7(W!>A`wT)w5SVh^{b1o~tz54q0W;$^`*KP_-lYz{t&mj>CHnz4> zg9qz#K>Mp~9*U93_8mJS6}r58_inqZYjJh8KfZ1apUybfs@YgtdS1CQ89zEp@(GhX z6La#`$mQt`Fw^#aiM`NaIKEzk1|0ycU~q8n>C=Pv?rC4Xa^=&@`0xh*Wm;Mir{a8v zYn_zRG0u4OD3XKs=9WtknQd!XR-ZwG2h$qrNWO{!g%|pcm|7b1vHetB49S3R-n_XQ zwC?>4$F5lSp<{hQn%GXeytcl+UEZOS@<;N#@Rh6JIFy!^t=hE75NMHb>()B?){%`@ z%4^vA4x2X*9Xr;S`ImOmH#6L1ZZCMtzUs@{y~tm)U47IG#iW%<4J&RsT`U-z{Iyu; zyYH=Y4QHaGBje)@Q+GCtVioSQQ{JL*i?h`#s;UC$&_DKcPOVlCz{6(RTeZ`jA+LfM9o^4l%;)KY_YvJ@Zqk0gQHld+| zX;TfGKK%qwL2GdG z=>1_~vTRjMu817o`1XL(`P7Q*^2gQH)nVP|l+gU%WX+m2u-|=P0?hXfOB<*ocA2SY z^<7w&*hR;<02|io>S~^Mn*hVG^<~O!|pjg7B%F@azq9ns2o?`n7O%*!u z83GTQobQ{QoJ=y@j0O$s1*u!NZ|lyRR|M^I1}t-UtZ8>bzWKhEtnp@-JdcbuMRTS} z=_!0X1=1x-m6nz&QtaU{sB35#P5&V;-eL&ASnt?`iD%)~L?bjIzcyLxK>`I;Yr_|UuF ztn-sFjrm}?rO8`HQbvTRy95>$Sw=)e;KMioaLi0XCqRPvzUIQEW@ejlf^u_r$8)?_ zTwEM}#wRep#KEc^eq*A*AC1I{#N;L>QDh0ZG%*ys3W7K}MwT3&W|imi2SgUPU1*q2^XJd!K>M>L*uOWr zHzw-Ag+Qzmk#{l0Ok&_E9vo!^{DIbb-AZehcQWM$?*@LrU#6H|WfCe~qO-M`Ag zK4TH3-&4COAsRc5W@OB>&%dCHKcfQK15$|Q$Rv&jjYZ>eGWHqzhd5yi7A(M-On%z5 zqkNz%TPqAW$XUXbY)e@evT`X~W00ED0p9x4^wO7lb@guleBtn*f4=bO=|8}HI;1xW z?9KJ%`b34ZSZ zu3evpZR2=fw#|{1*if&xLFy>=OGK`nx36yr)w&2bG&DtdPX}T2xN&I@9(3Tabm`jF zcku7HiqVrM9imQU5mg*NOY=?32!*03!3=j!C`Tu$w4(7$^{wE%FirV?`Oht-^Qd^lxd$53nCpT` z9UD<}r$j9e*NkiFZg?Z2h&I5l&GCT?Bx{3R$DHk1eB?PW6YLMyd5PiyrYZ-4lgife z15V)(d^0AGj^aUo`}R$EqJo_waIhw99ifJFD7w=IBzIN*%Ee`gpu3gnxhX5z2Q+5a(asBnL6($DGe!l=v~r62}0ocs7vYwge5azyyZJ zp=!q{=sr(hFPAoOPB~eqX|OjML^m5V=wc0E!j52d8A;gcr^(N{nM zH8wN5YsMQ(ZST}QQ!aV+^f=C0r|!Rtzoy#EOZeCv{P1{o|T?RmH5V=Yz#>F5y>D-~F zXeKnmXhsJnOqhTfo&!>@-Me@Dl$Dt0=pPCR8HE2N2&IU)CtL=ed2PRkTrVLp@xk4@ zyF?VUPVb)C<0*MaqywBxCHSONone@c2xnE3mxDdws<-m8l-r7vCl6OvJ_Z_NCA29x zi6dfPf=x3ET!Dl#3MR4A;FX{o^=&V2_Uc*u^-NgBlD$3S58yD$|FE44=71Z7&&Wnz zBkcAhphkeo7U{;H4cO)VCa?KRRQZ!8_3{LCLEifuKi;2?#2OSVRNNgYz^mR^+CRO$ z!?d34}V&r(6X~!ixMdt3ti!m2(SapPCx-vM?)aN>OmLW zau?ssyAII@hNGR*PD)COa&i{joY+CQq!QWp5i#M?H*ec!gOba0diB#5c=tgXu7_zg z3Ro2$J_Jf7lKv@3h~;}s25#ibiI*T?io|Ko5(DH*5NOKKNg2U8VVMNKgoWE(I0sQp zvx}n0tcCI$@=A&L!kl;b@Zn^_eL&pq-MceQxQjLafUWe6CV}TEVS4xMDGHVxzm_fVHyxNt!blfYprDZ2oZ`GbjqKWIRB{ah{}V2>U>AWC9r zZ+`gj0h1PgWRe1w7u61)IyLmLpuT6#ngxvBO9zg=m!RpPa;>p925F2MHHybBHE7TR zR6Y`p7xZ{!@)ET2hiBpEBuZWyLHtC?moEp1qkM|?@LEJDE%W!Mc@_uxxT1EOXJ9Z2 z_<&=FQR+^2LWc0OCHk0dkZLPi@rhcF7$m4;LZ%K47wR4bpNJbxXk>fAj8JQ)p^Kob z9fcQkG`V$<>J~5Xs^HRT*@`Y1lwzkmW9K4=okg`i*Tt#k4XgNbvbJo6yJt8<; z9eyz~*DheuBbCahr}xy68hKF#lAhkSZC4`{e1r>q6nQ`oByly_XwlBFI5jXdo}%6u zgT=m$M%$Q^H!@Mhq1elc{^AAmn@f02lr4wggyKN>^KJ^xHkQ_YWPyWytcFPboI%s| zuQ^7Cd3*|tnM_D(&aC|w7cidBie_cr(%Y_yVtJx~c6tP#K5A-eWyFdsBmn1m^2W*A zYa=2QKF6vV?x?GW+F03N$;LbI(4o_Oe1PXtF4!n;z%&C2N;W zwa@eB$-`{Dy6!NXu12T4#KlvvqMiDa$3`=KI-SqljqwyhfTsJInfsx&;m;#(m^j(z zotsHBn9yRyl)Xe@W+Y+zG0Q61qen&BeyIokiypnLJbYMs+Qv76WTOC-5OEBz#=+n* z!QpWv5uCM?03#JzzfgPv4OGDHBRqCIg&9Byg(o|hbh&`@LwU6d3W{$O+a&FGkvM+^ zYiQAPrM&jhczY_>jy(8$)!`e94u^v{1jj|Q4j59wh6Td5-QJYv9Tl}Yp(JnN4$+k$ zx;bpy)?QX~>X}?Sfvky4ykDDu)LBMu>bEPc$BrDim*oL>W0%nevtoc1IvFiI-}M$R zmZoZGLbvYu>+_aFJef)B3lu3<1RuZlb<%hg`m1PZD=7!F(dFWMc9Cmw;_psl$UuoD zOqgHjcVCf~o!xEj+_{vhAgOM$va)wdqR#yOUb&BO4!zqU?}zJ5-DC`#MpHABOA~A| zduzETgB?y$x-K{|r8BfvtZBS|Lc%1doI-WM2yhul09m?HrSN6W-MeizZQ3--Fzf(O zlSr#h>xGuwi7#K)b8$=~Y^I`;(!EEI=D+-q;$#>AaLH8THu&rl_4sOvnM3pi1^?-o{ps7)h$dXK7jY2{p;GiWF$Ousl?|S*^^2Zm z@8!-7F6YsvyoO(6HI>62`z0n$MK&-(RTV-iU(ut*jlOO_HKz+K<#BX=3o$aTx)s)n z+DZk11AGB`!X@9k&XtsFkrg$zx9OKmUtJJ|C>beVcBM-l(`=00RVZDy=AKt);ASr9 zzsh`RX0}I)GAIRJ@A8fx8)=#NO#PYXTGwjxhpH6!>5$Sm{fXz7#xxdx%={WaZsH^4 zPmn&{kkFw9$r9YqJ=!_Yx2NbqP!&mh-Vh?=va+4@DLRm%tD2tsDL*LL!O<}aa!owe z4BUPC04-|+a4_E!64<9tuu|TE_T<}Zc7IUWP>^m`qU)E*vn$aBP-7M;O3~ z$BU%0va*)DqbkQ8ZFWytSp&#XRk%2kqZJ^7mLCo<+mklEH$a?{aP8W}hTF#V&hsQ| zQzz#+N@z=-M*4hJ%UBw8@Bn9vbCsLlDPZF)5qPpfAuAiEKnMT?@*2|mb6@O)z?CDW zOp$hXcNZ-@Sm>*bhkPT`ZPwowbPK=7rAHc*lg_mHb-kMZiwXOEeh9{64W>P@=O5{G z9gfFM7?|eozxr!~l9QdP28hC{h;oR!^0Uf9xwMZ;>L10bOWEFO;=&l$1*89MLq0}!y$^Cpn)-bB4Bcg`V z_P*w|!X`DibgsAQtcOc7M<@q8NKc1Q&gPlh5%7cm{`;@BbAtZQU)F6m zU%cU_BU}*1`bJbLe&k{bR0}RqsWeyzQxik3{nGO=q$MVX8^$&d{`1}*d;hEt?|16V zsAuFHgloq)?smQZr7*E8zePtfvJ%+CZueLEvu(uNa8nf2<52O}rw7!v|MNZG*<-!! zwQnDG-+PjiRfz!9J3}5cKw2V+>dDEcWU$MP=)jLjq@|}L8VVq&kX=3iSxV{07g~=s ziEXb%q0VjEu+%-bH}tv3@tlMjl4zqib?Srn@5AAgs&ah878WL0cOpCmpFCMoQISsW zZ22}hY=-*)O-)U1G>b8g>sHz^b3`X233Y*p{QMLhph(cq$d(l9 z5z7r5vWe^x3ggC&pfLHgYBSk(aDl(VY`cq_#xVd z^mWTyntyxza@i{$U)aCT>(+}K&R@lS0MvArs4gfO;ZXqiorD{?pe>2={GRAY17KmB zB{tLSrJ$X|FF~qk(QZbovXD089awvb0`yS`A1+v=wj?_+bQ?%eszsSmPbq`0Vh%|D zI--w+W+4Yd@T$klpsGM$Qg5hP!glXB!%YQ8^t%u<+*St={{BqW$JbY^1Df(ch9CqUU9QjTcPhP%~uW|_}oJ_mu;-IM+~La)2* zqs)wqQ{WQbHz+S}F;Q2C0b(QRvZ#{2V&gqs_~-1r8wS~xMLW0;sF6voF`o1%Pc=6J z_xn&8tOlfkWd(c`17NqmrFxV+?AE~uAS6&CEXrt4gd&Hme&cbkKn_>}QYK?aQ~a%F zrx%7-l$DL<0*x%bi2%{GHph5gW__w=P;qrRrOp&{a)NYoHS;=l*HHM4h5E<>2#U`G zq#FZtc;F8KX%eQMUH|>N30P@av8|J%qX~0HajgGB(AZ)y;8o2>oPUU?BcybzbVhOJ zi{YPy9PWIIYHp;$?xO__Ke6^l7jcenjXVDDk-forxeTJ_@2vibPtm4t4-q_ekI+%Ae8$}`*b;BSXQfy4~ z6?*Lw@St#Hr_(&%zkF%>+m^&h8zH>W*`k!)2NQTD2`KT93c1^H~`_uFh6f!tTxWNdO_# zaW@JYV4I3+*LjQ1SBo=(*eZ3i9NMsVI0^-qS9hhCB{&y=G&+oi%R}`4gxmT5gv{;h zT()lqSzpzc_hjoj(1u1Ix+~pKy^sE!ma7r&ysEyD5h+u)F!QZ1ByKyqipQ>DXwXoK zF3{HA?X(=#8PtEFN{bIffL-f_TssxFpNjm31cIim@JCibkwY|GuNKr!%$nJYWrqe8 z>^cw7$LS`;Hnp{2A(WM`S+ySFLNo={x!h#HgYqW&ZbsY$6oqJJKR_*!-`k*wN#hx`Y1dKkY`n%RI!w%+2`LsjAwf_K z8a$ZNY8ZWoF%4=WZbG!pm>~~wm6c&nx7ojbU=Y&Y{rA12! z=eCRtdLIr#bk^9wq4Ps-t4c_;U8g&H=HjN?D07Ls^~{1O5u2$MV`Ev1o#F~rQ@~b9Ungt z2^3t;x}FG#$*5*R`JqV0y@VgVIoKVlk_ViOv^4jeE*iCzXn z8s4;)lO{D>B}Dv3;0NA+L_g;z4a?S}s^PTj?{Ig3;O;5*tZ9S+XWIz*2t9&Vw_GMu z!f=&a;JI_>tkOHtgIJS|K%_v(Mrf|ZI5|FuZv6dQ3K<=zQt){ae9SWVT{cliC?42S zx)kCTO9_Y+Gs*P cgJ_yH*W{{NXqgQcv*{ALItH`jv@Li44+=J6t^fc4 literal 0 HcmV?d00001 diff --git a/gnu/llvm/llvm/docs/CommandGuide/tblgen.rst b/gnu/llvm/llvm/docs/CommandGuide/tblgen.rst index 372d1b2a730..2a468fa95fd 100644 --- a/gnu/llvm/llvm/docs/CommandGuide/tblgen.rst +++ b/gnu/llvm/llvm/docs/CommandGuide/tblgen.rst @@ -98,7 +98,7 @@ OPTIONS .. option:: -gen-dag-isel - Generate a DAG (Directed Acycle Graph) instruction selector. + Generate a DAG (Directed Acyclic Graph) instruction selector. .. option:: -gen-asm-matcher diff --git a/gnu/llvm/llvm/docs/CompileCudaWithLLVM.rst b/gnu/llvm/llvm/docs/CompileCudaWithLLVM.rst index 6e181c84e68..a2d7fd0b745 100644 --- a/gnu/llvm/llvm/docs/CompileCudaWithLLVM.rst +++ b/gnu/llvm/llvm/docs/CompileCudaWithLLVM.rst @@ -22,21 +22,22 @@ Compiling CUDA Code Prerequisites ------------- -CUDA is supported since llvm 3.9. Current release of clang (7.0.0) supports CUDA -7.0 through 9.2. If you need support for CUDA 10, you will need to use clang -built from r342924 or newer. +CUDA is supported since llvm 3.9. Clang currently supports CUDA 7.0 through +10.1. If clang detects a newer CUDA version, it will issue a warning and will +attempt to use detected CUDA SDK it as if it were CUDA-10.1. -Before you build CUDA code, you'll need to have installed the appropriate driver -for your nvidia GPU and the CUDA SDK. See `NVIDIA's CUDA installation guide +Before you build CUDA code, you'll need to have installed the CUDA SDK. See +`NVIDIA's CUDA installation guide `_ for -details. Note that clang `does not support -`_ the CUDA toolkit as installed by -many Linux package managers; you probably need to install CUDA in a single -directory from NVIDIA's package. +details. Note that clang `maynot support +`_ the CUDA toolkit as installed by +some Linux package managers. Clang does attempt to deal with specific details of +CUDA installation on a handful of common Linux distributions, but in general the +most reliable way to make it work is to install CUDA in a single directory from +NVIDIA's `.run` package and specify its location via `--cuda-path=...` argument. CUDA compilation is supported on Linux. Compilation on MacOS and Windows may or -may not work and currently have no maintainers. Compilation with CUDA-9.x is -`currently broken on Windows `_. +may not work and currently have no maintainers. Invoking clang -------------- @@ -341,7 +342,7 @@ HD functions cannot be overloaded by H or D functions with the same signature: When resolving an overloaded function, clang considers the host/device attributes of the caller and callee. These are used as a tiebreaker during overload resolution. See `IdentifyCUDAPreference -`_ for the full set of rules, +`_ for the full set of rules, but at a high level they are: * D functions prefer to call other Ds. HDs are given lower priority. @@ -506,13 +507,13 @@ LLVM to make it generate good GPU code. Among these changes are: reduce redundancy within straight-line code. * `Aggressive speculative execution - `_ + `_ -- This is mainly for promoting straight-line scalar optimizations, which are most effective on code along dominator paths. * `Memory space inference - `_ -- - In PTX, we can operate on pointers that are in a paricular "address space" + `_ -- + In PTX, we can operate on pointers that are in a particular "address space" (global, shared, constant, or local), or we can operate on pointers in the "generic" address space, which can point to anything. Operations in a non-generic address space are faster, but pointers in CUDA are not explicitly @@ -520,7 +521,7 @@ LLVM to make it generate good GPU code. Among these changes are: possible. * `Bypassing 64-bit divides - `_ -- + `_ -- This was an existing optimization that we enabled for the PTX backend. 64-bit integer divides are much slower than 32-bit ones on NVIDIA GPUs. @@ -528,14 +529,14 @@ LLVM to make it generate good GPU code. Among these changes are: which fit in 32-bits at runtime. This optimization provides a fast path for this common case. -* Aggressive loop unrooling and function inlining -- Loop unrolling and +* Aggressive loop unrolling and function inlining -- Loop unrolling and function inlining need to be more aggressive for GPUs than for CPUs because control flow transfer in GPU is more expensive. More aggressive unrolling and inlining also promote other optimizations, such as constant propagation and SROA, which sometimes speed up code by over 10x. (Programmers can force unrolling and inline using clang's `loop unrolling pragmas - `_ + `_ and ``__attribute__((always_inline))``.) Publication @@ -557,4 +558,4 @@ Obtaining Help ============== To obtain help on LLVM in general and its CUDA support, see `the LLVM -community `_. +community `_. diff --git a/gnu/llvm/llvm/docs/Contributing.rst b/gnu/llvm/llvm/docs/Contributing.rst index 2ad0d9080e1..45d4d7a27fa 100644 --- a/gnu/llvm/llvm/docs/Contributing.rst +++ b/gnu/llvm/llvm/docs/Contributing.rst @@ -37,6 +37,11 @@ and use the built binaries to reproduce the failure described in the bug. Use a debug build (`-DCMAKE_BUILD_TYPE=Debug`) or a build with assertions (`-DLLVM_ENABLE_ASSERTIONS=On`, enabled for Debug builds). +Reporting a Security Issue +-------------------------- + +There is a separate process to submit security-related bugs, see :ref:`report-security-issue`. + Bigger Pieces of Work --------------------- In case you are interested in taking on a bigger piece of work, a list of @@ -110,6 +115,8 @@ patch, or the Phabricator review with "Ping." The common courtesy 'ping' rate is once a week. Please remember that you are asking for valuable time from other professional developers. +For more information on LLVM's code-review process, please see :doc:`CodeReview`. + Helpful Information About LLVM ============================== diff --git a/gnu/llvm/llvm/docs/CoverageMappingFormat.rst b/gnu/llvm/llvm/docs/CoverageMappingFormat.rst index 30b11fe2f31..2267265f0bc 100644 --- a/gnu/llvm/llvm/docs/CoverageMappingFormat.rst +++ b/gnu/llvm/llvm/docs/CoverageMappingFormat.rst @@ -12,49 +12,26 @@ Introduction ============ LLVM's code coverage mapping format is used to provide code coverage -analysis using LLVM's and Clang's instrumenation based profiling +analysis using LLVM's and Clang's instrumentation based profiling (Clang's ``-fprofile-instr-generate`` option). -This document is aimed at those who use LLVM's code coverage mapping to provide -code coverage analysis for their own programs, and for those who would like -to know how it works under the hood. A prior knowledge of how Clang's profile -guided optimization works is useful, but not required. +This document is aimed at those who would like to know how LLVM's code coverage +mapping works under the hood. A prior knowledge of how Clang's profile guided +optimization works is useful, but not required. For those interested in using +LLVM to provide code coverage analysis for their own programs, see the `Clang +documentation `. -We start by showing how to use LLVM and Clang for code coverage analysis, -then we briefly describe LLVM's code coverage mapping format and the +We start by briefly describing LLVM's code coverage mapping format and the way that Clang and LLVM's code coverage tool work with this format. After the basics are down, more advanced features of the coverage mapping format are discussed - such as the data structures, LLVM IR representation and the binary encoding. -Quick Start -=========== - -Here's a short story that describes how to generate code coverage overview -for a sample source file called *test.c*. - -* First, compile an instrumented version of your program using Clang's - ``-fprofile-instr-generate`` option with the additional ``-fcoverage-mapping`` - option: - - ``clang -o test -fprofile-instr-generate -fcoverage-mapping test.c`` -* Then, run the instrumented binary. The runtime will produce a file called - *default.profraw* containing the raw profile instrumentation data: - - ``./test`` -* After that, merge the profile data using the *llvm-profdata* tool: - - ``llvm-profdata merge -o test.profdata default.profraw`` -* Finally, run LLVM's code coverage tool (*llvm-cov*) to produce the code - coverage overview for the sample source file: - - ``llvm-cov show ./test -instr-profile=test.profdata test.c`` - High Level Overview =================== LLVM's code coverage mapping format is designed to be a self contained -data format, that can be embedded into the LLVM IR and object files. +data format that can be embedded into the LLVM IR and into object files. It's described in this document as a **mapping** format because its goal is to store the data that is required for a code coverage tool to map between the specific source ranges in a file and the execution counts obtained @@ -224,9 +201,9 @@ executed, as it doesn't possess the frontend's knowledge. LLVM IR Representation ====================== -The coverage mapping data is stored in the LLVM IR using a single global -constant structure variable called *__llvm_coverage_mapping* -with the *__llvm_covmap* section specifier. +The coverage mapping data is stored in the LLVM IR using a global constant +structure variable called *__llvm_coverage_mapping* with the *IPSK_covmap* +section specifier (i.e. ".lcovmap$M" on Windows and "__llvm_covmap" elsewhere). For example, let’s consider a C file and how it gets compiled to LLVM: @@ -241,42 +218,45 @@ For example, let’s consider a C file and how it gets compiled to LLVM: return 13; } -The coverage mapping variable generated by Clang has 3 fields: +The coverage mapping variable generated by Clang has 2 fields: * Coverage mapping header. -* An array of function records. +* An optionally compressed list of filenames present in the translation unit. -* Coverage mapping data which is an array of bytes. Zero paddings are added at the end to force 8 byte alignment. +The variable has 8-byte alignment because ld64 cannot always pack symbols from +different object files tightly (the word-level alignment assumption is baked in +too deeply). .. code-block:: llvm - @__llvm_coverage_mapping = internal constant { { i32, i32, i32, i32 }, [2 x { i64, i32, i64 }], [40 x i8] } - { + @__llvm_coverage_mapping = internal constant { { i32, i32, i32, i32 }, [32 x i8] } + { { i32, i32, i32, i32 } ; Coverage map header { - i32 2, ; The number of function records - i32 20, ; The length of the string that contains the encoded translation unit filenames - i32 20, ; The length of the string that contains the encoded coverage mapping data - i32 2, ; Coverage mapping format version + i32 0, ; Always 0. In prior versions, the number of affixed function records + i32 32, ; The length of the string that contains the encoded translation unit filenames + i32 0, ; Always 0. In prior versions, the length of the affixed string that contains the encoded coverage mapping data + i32 3, ; Coverage mapping format version }, - [2 x { i64, i32, i64 }] [ ; Function records - { i64, i32, i64 } { - i64 0x5cf8c24cdb18bdac, ; Function's name MD5 - i32 9, ; Function's encoded coverage mapping data string length - i64 0 ; Function's structural hash - }, - { i64, i32, i64 } { - i64 0xe413754a191db537, ; Function's name MD5 - i32 9, ; Function's encoded coverage mapping data string length - i64 0 ; Function's structural hash - }], - [40 x i8] c"..." ; Encoded data (dissected later) + [32 x i8] c"..." ; Encoded data (dissected later) }, section "__llvm_covmap", align 8 -The current version of the format is version 3. The only difference from version 2 is that a special encoding for column end locations was introduced to indicate gap regions. +The current version of the format is version 4. There are two differences from version 3: -The function record layout has evolved since version 1. In version 1, the function record for *foo* is defined as follows: +* Function records are now named symbols, and are marked *linkonce_odr*. This + allows linkers to merge duplicate function records. Merging of duplicate + *dummy* records (emitted for functions included-but-not-used in a translation + unit) reduces size bloat in the coverage mapping data. As part of this + change, region mapping information for a function is now included within the + function record, instead of being affixed to the coverage header. + +* The filename list for a translation unit may optionally be zlib-compressed. + +The only difference between versions 3 and 2 is that a special encoding for +column end locations was introduced to indicate gap regions. + +In version 1, the function record for *foo* was defined as follows: .. code-block:: llvm @@ -286,19 +266,27 @@ The function record layout has evolved since version 1. In version 1, the functi i64 0 ; Function's structural hash } +In version 2, the function record for *foo* was defined as follows: + +.. code-block:: llvm + + { i64, i32, i64 } { + i64 0x5cf8c24cdb18bdac, ; Function's name MD5 + i32 9, ; Function's encoded coverage mapping data string length + i64 0 ; Function's structural hash Coverage Mapping Header: ------------------------ The coverage mapping header has the following fields: -* The number of function records. +* The number of function records affixed to the coverage header. Always 0, but present for backwards compatibility. * The length of the string in the third field of *__llvm_coverage_mapping* that contains the encoded translation unit filenames. -* The length of the string in the third field of *__llvm_coverage_mapping* that contains the encoded coverage mapping data. +* The length of the string in the third field of *__llvm_coverage_mapping* that contains any encoded coverage mapping data affixed to the coverage header. Always 0, but present for backwards compatibility. -* The format version. The current version is 3 (encoded as a 2). +* The format version. The current version is 4 (encoded as a 3). .. _function records: @@ -309,24 +297,11 @@ A function record is a structure of the following type: .. code-block:: llvm - { i64, i32, i64 } - -It contains function name's MD5, the length of the encoded mapping data for that function, and function's -structural hash value. - -Encoded data: -------------- - -The encoded data is stored in a single string that contains -the encoded filenames used by this translation unit and the encoded coverage -mapping data for each function in this translation unit. + { i64, i32, i64, i64, [? x i8] } -The encoded data has the following structure: - -``[filenames, coverageMappingDataForFunctionRecord0, coverageMappingDataForFunctionRecord1, ..., padding]`` - -If necessary, the encoded data is padded with zeroes so that the size -of the data string is rounded up to the nearest multiple of 8 bytes. +It contains the function name's MD5, the length of the encoded mapping data for +that function, the function's structural hash value, the hash of the filenames +in the function's translation unit, and the encoded mapping data. Dissecting the sample: ^^^^^^^^^^^^^^^^^^^^^^ @@ -339,32 +314,18 @@ IR for the `coverage mapping sample`_ that was shown earlier: .. code-block:: llvm - c"\01\12/Users/alex/test.c\01\00\00\01\01\01\0C\02\02\01\00\00\01\01\04\0C\02\02\00\00" + c"\01\15\1Dx\DA\13\D1\0F-N-*\D6/+\CE\D6/\C9-\D0O\CB\CF\D7K\06\00N+\07]" * The string contains values that are encoded in the LEB128 format, which is - used throughout for storing integers. It also contains a string value. - -* The length of the substring that contains the encoded translation unit - filenames is the value of the second field in the *__llvm_coverage_mapping* - structure, which is 20, thus the filenames are encoded in this string: - - .. code-block:: llvm - - c"\01\12/Users/alex/test.c" + used throughout for storing integers. It also contains a compressed payload. - This string contains the following data: +* The first three LEB128-encoded numbers in the sample specify the number of + filenames, the length of the uncompressed filenames, and the length of the + compressed payload (or 0 if compression is disabled). In this sample, there + is 1 filename that is 21 bytes in length (uncompressed), and stored in 29 + bytes (compressed). - * Its first byte has a value of ``0x01``. It stores the number of filenames - contained in this string. - * Its second byte stores the length of the first filename in this string. - * The remaining 18 bytes are used to store the first filename. - -* The length of the substring that contains the encoded coverage mapping data - for the first function is the value of the third field in the first - structure in an array of `function records`_ stored in the - third field of the *__llvm_coverage_mapping* structure, which is the 9. - Therefore, the coverage mapping for the first function record is encoded - in this string: +* The coverage mapping from the first function record is encoded in this string: .. code-block:: llvm diff --git a/gnu/llvm/llvm/docs/DependenceGraphs/index.rst b/gnu/llvm/llvm/docs/DependenceGraphs/index.rst index c53ee9051d5..e3e6447df2f 100644 --- a/gnu/llvm/llvm/docs/DependenceGraphs/index.rst +++ b/gnu/llvm/llvm/docs/DependenceGraphs/index.rst @@ -131,7 +131,7 @@ graph described in [1]_ in the following ways: 1. The graph nodes in the paper represent three main program components, namely *assignment statements*, *for loop headers* and *while loop headers*. In this implementation, DDG nodes naturally represent LLVM IR instructions. An assignment statement in this implementation typically involves a node representing the ``store`` instruction along with a number of individual nodes computing the right-hand-side of the assignment that connect to the ``store`` node via a def-use edge. The loop header instructions are not represented as special nodes in this implementation because they have limited uses and can be easily identified, for example, through ``LoopAnalysis``. 2. The paper describes five types of dependency edges between nodes namely *loop dependency*, *flow-*, *anti-*, *output-*, and *input-* dependencies. In this implementation *memory* edges represent the *flow-*, *anti-*, *output-*, and *input-* dependencies. However, *loop dependencies* are not made explicit, because they mainly represent association between a loop structure and the program elements inside the loop and this association is fairly obvious in LLVM IR itself. - 3. The paper describes two types of pi-blocks; *recurrences* whose bodies are SCCs and *IN* nodes whose bodies are not part of any SCC. In this impelmentation, pi-blocks are only created for *recurrences*. *IN* nodes remain as simple DDG nodes in the graph. + 3. The paper describes two types of pi-blocks; *recurrences* whose bodies are SCCs and *IN* nodes whose bodies are not part of any SCC. In this implementation, pi-blocks are only created for *recurrences*. *IN* nodes remain as simple DDG nodes in the graph. References diff --git a/gnu/llvm/llvm/docs/DeveloperPolicy.rst b/gnu/llvm/llvm/docs/DeveloperPolicy.rst index b31ef42c15d..b6e43ce0534 100644 --- a/gnu/llvm/llvm/docs/DeveloperPolicy.rst +++ b/gnu/llvm/llvm/docs/DeveloperPolicy.rst @@ -89,7 +89,9 @@ to read it as possible. As such, we recommend that you: patches may not apply correctly if the underlying code changes between the time the patch was created and the time it is applied. -#. Patches should be made with ``git format-patch``, or similar. If you use a +#. Patches should be made with ``git format-patch``, or similar (see special + commands for `Requesting Phabricator review via the web interface + `_ ). If you use a different tool, make sure it uses the ``diff -u`` format and that it doesn't contain clutter which makes it hard to read. @@ -121,49 +123,9 @@ licensing terms and may result in your contribution being excluded. Code Reviews ------------ -LLVM has a code review policy. Code review is one way to increase the quality of -software. We generally follow these policies: - -#. All developers are required to have significant changes reviewed before they - are committed to the repository. - -#. Code reviews are conducted by email on the relevant project's commit mailing - list, or alternatively on the project's development list or bug tracker. - -#. Code can be reviewed either before it is committed or after. We expect major - changes to be reviewed before being committed, but smaller changes (or - changes where the developer owns the component) can be reviewed after commit. - -#. The developer responsible for a code change is also responsible for making - all necessary review-related changes. - -#. Code review can be an iterative process, which continues until the patch is - ready to be committed. Specifically, once a patch is sent out for review, it - needs an explicit "looks good" before it is submitted. Do not assume silent - approval, or request active objections to the patch with a deadline. - -Sometimes code reviews will take longer than you would hope for, especially for -larger features. Accepted ways to speed up review times for your patches are: - -* Review other people's patches. If you help out, everybody will be more - willing to do the same for you; goodwill is our currency. -* Ping the patch. If it is urgent, provide reasons why it is important to you to - get this patch landed and ping it every couple of days. If it is - not urgent, the common courtesy ping rate is one week. Remember that you're - asking for valuable time from other professional developers. -* Ask for help on IRC. Developers on IRC will be able to either help you - directly, or tell you who might be a good reviewer. -* Split your patch into multiple smaller patches that build on each other. The - smaller your patch, the higher the probability that somebody will take a quick - look at it. - -Developers should participate in code reviews as both reviewers and -reviewees. If someone is kind enough to review your code, you should return the -favor for someone else. Note that anyone is welcome to review and give feedback -on a patch, but only people with Subversion write access can approve it. - -There is a web based code review tool that can optionally be used -for code reviews. See :doc:`Phabricator`. +LLVM has a code-review policy. Code review is one way to increase the quality of +software. Please see :doc:`CodeReview` for more information on LLVM's code-review +process. .. _code owners: @@ -325,9 +287,9 @@ Below are some guidelines about the format of the message itself: and in-code comments, ex. capitalization, full stop, etc. * If the commit is a bug fix on top of another recently committed patch, or a - revert or reapply of a patch, include the svn revision number of the prior - related commit. This could be as simple as "Revert rNNNN because it caused - PR#". + revert or reapply of a patch, include the git commit hash of the prior + related commit. This could be as simple as "Revert commit NNNN because it + caused PR#". For minor violations of these recommendations, the community normally favors reminding the contributor of this policy over reverting. Minor corrections and @@ -353,10 +315,9 @@ This is normal and will be done when the mailing list owner has time. If you have recently been granted commit access, these policies apply: -#. You are granted *commit-after-approval* to all parts of LLVM. To get - approval, submit a `patch`_ to `llvm-commits - `_. When approved, - you may commit it yourself. +#. You are granted *commit-after-approval* to all parts of LLVM. For + information on how to get approval for a patch, please see :doc:`CodeReview`. + When approved, you may commit it yourself. #. You are allowed to commit patches without approval which you think are obvious. This is clearly a subjective decision --- we simply expect you to @@ -384,8 +345,8 @@ after they are committed, depending on the nature of the change). You are encouraged to review other peoples' patches as well, but you aren't required to do so. -Current Contributors - Transfering from SVN -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Current Contributors - Transferring from SVN +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you had commit access to SVN and would like to request commit access to GitHub, please email `llvm-admin `_ with your SVN username and GitHub username. @@ -560,19 +521,86 @@ C API Changes release notes so that it's clear to external users who do not follow the project how the C API is changing and evolving. -New Targets ------------ +.. _toolchain: + +Updating Toolchain Requirements +------------------------------- + +We intend to require newer toolchains as time goes by. This means LLVM's +codebase can use newer versions of C++ as they get standardized. Requiring newer +toolchains to build LLVM can be painful for those building LLVM; therefore, it +will only be done through the following process: + + * It is a general goal to support LLVM and GCC versions from the last 3 years + at a minimum. This time-based guideline is not strict: we may support much + older compilers, or decide to support fewer versions. + + * An RFC is sent to the `llvm-dev mailing list`_ + + - Detail upsides of the version increase (e.g. which newer C++ language or + library features LLVM should use; avoid miscompiles in particular compiler + versions, etc). + - Detail downsides on important platforms (e.g. Ubuntu LTS status). + + * Once the RFC reaches consensus, update the CMake toolchain version checks as + well as the :doc:`getting started` guide. This provides a + softer transition path for developers compiling LLVM, because the + error can be turned into a warning using a CMake flag. This is an important + step: LLVM still doesn't have code which requires the new toolchains, but it + soon will. If you compile LLVM but don't read the mailing list, we should + tell you! + + * Ensure that at least one LLVM release has had this soft-error. Not all + developers compile LLVM top-of-tree. These release-bound developers should + also be told about upcoming changes. + + * Turn the soft-error into a hard-error after said LLVM release has branched. + + * Update the :doc:`coding standards` to allow the new + features we've explicitly approved in the RFC. + + * Start using the new features in LLVM's codebase. + +Here's a `sample RFC +`_ and the +`corresponding change `_. + +.. _new-llvm-components: + +Introducing New Components into LLVM +==================================== + +The LLVM community is a vibrant and exciting place to be, and we look to be +inclusive of new projects and foster new communities, and increase +collaboration across industry and academia. + +That said, we need to strike a balance between being inclusive of new ideas and +people and the cost of ongoing maintenance that new code requires. As such, we +have the following general policies for introducing major new components into +the LLVM world. However, this is really only intended to cover common cases +that we have seen arise: different situations are different, and we are open +to discussing unusual cases as well - just start an RFC thread on the +`llvm-dev mailing list`_. + +Adding a New Target +------------------- LLVM is very receptive to new targets, even experimental ones, but a number of problems can appear when adding new large portions of code, and back-ends are -normally added in bulk. We have found that landing large pieces of new code -and then trying to fix emergent problems in-tree is problematic for a variety +normally added in bulk. We have found that landing large pieces of new code +and then trying to fix emergent problems in-tree is problematic for a variety of reasons. For these reasons, new targets are *always* added as *experimental* until -they can be proven stable, and later moved to non-experimental. The difference -between both classes is that experimental targets are not built by default -(need to be added to -DLLVM_TARGETS_TO_BUILD at CMake time). +they can be proven stable, and later moved to non-experimental. The differences +between both classes are: + +* Experimental targets are not built by default (they need to be explicitly + enabled at CMake time). + +* Test failures, bugs, and build breakages that only appear when the + experimental target is enabled, caused by changes unrelated to the target, are + the responsibility of the community behind the target to fix. The basic rules for a back-end to be upstreamed in **experimental** mode are: @@ -599,8 +627,8 @@ The basic rules for a back-end to be upstreamed in **experimental** mode are: * The target should have either reasonable documentation on how it works (ISA, ABI, etc.) or a publicly available simulator/hardware (either free or cheap enough) - preferably both. This allows - developers to validate assumptions, understand constraints and review code - that can affect the target. + developers to validate assumptions, understand constraints and review code + that can affect the target. In addition, the rules for a back-end to be promoted to **official** are: @@ -639,49 +667,110 @@ In essences, these rules are necessary for targets to gain and retain their status, but also markers to define bit-rot, and will be used to clean up the tree from unmaintained targets. -.. _toolchain: - -Updating Toolchain Requirements -------------------------------- - -We intend to require newer toolchains as time goes by. This means LLVM's -codebase can use newer versions of C++ as they get standardized. Requiring newer -toolchains to build LLVM can be painful for those building LLVM; therefore, it -will only be done through the following process: - - * Generally, try to support LLVM and GCC versions from the last 3 years at a - minimum. This time-based guideline is not strict: we may support much older - compilers, or decide to support fewer versions. - - * An RFC is sent to the `llvm-dev mailing list `_ - - - Detail upsides of the version increase (e.g. which newer C++ language or - library features LLVM should use; avoid miscompiles in particular compiler - versions, etc). - - Detail downsides on important platforms (e.g. Ubuntu LTS status). - - * Once the RFC reaches consensus, update the CMake toolchain version checks as - well as the :doc:`getting started` guide. We want to - soft-error when developers compile LLVM. We say "soft-error" because the - error can be turned into a warning using a CMake flag. This is an important - step: LLVM still doesn't have code which requires the new toolchains, but it - soon will. If you compile LLVM but don't read the mailing list, we should - tell you! - - * Ensure that at least one LLVM release has had this soft-error. Not all - developers compile LLVM top-of-tree. These release-bound developers should - also be told about upcoming changes. - - * Turn the soft-error into a hard-error after said LLVM release has branched. +Adding an Established Project To the LLVM Monorepo +-------------------------------------------------- + +The `LLVM monorepo `_ is the centerpoint +of development in the LLVM world, and has all of the primary LLVM components, +including the LLVM optimizer and code generators, Clang, LLDB, etc. `Monorepos +in general `_ are great because they +allow atomic commits to the project, simplify CI, and make it easier for +subcommunities to collaborate. + +That said, the burden to add things to the LLVM monorepo needs to be very high - +code that is added to this repository is checked out by everyone in the +community. As such, we hold subprojects to a high bar similar to "official +targets", they: + + * Must be generally aligned with the mission of the LLVM project to advance + compilers, languages, tools, runtimes, etc. + * Must conform to all of the policies laid out in this developer policy + document, including license, patent, coding standards, and code of conduct. + * Must have an active community that maintains the code, including established + code owners. + * Should have reasonable documentation about how it works, including a high + quality README file. + * Should have CI to catch breakage within the project itself or due to + underlying LLVM dependencies. + * Should have code free of issues the community finds contentious, or be on a + clear path to resolving them. + * Must be proposed through the LLVM RFC process, and have its addition approved + by the LLVM community - this ultimately mediates the resolution of the + "should" concerns above. + +If you have a project that you think would make sense to add to the LLVM +monorepo, please start an RFC thread on the `llvm-dev mailing list`_ to kick off +the discussion. This process can take some time and iteration - please don’t +be discouraged or intimidated by that! + +If you have an earlier stage project that you think is aligned with LLVM, please +see the "Incubating New Projects" section. + +Incubating New Projects +----------------------- - * Update the :doc:`coding standards` to allow the new - features we've explicitly approved in the RFC. +The burden to add a new project to the LLVM monorepo is intentionally very high, +but that can have a chilling effect on new and innovative projects. To help +foster these sorts of projects, LLVM supports an "incubator" process that is +much easier to get started with. It provides space for potentially valuable, +new top-level and sub-projects to reach a critical mass before they have enough +code to prove their utility and grow a community. This also allows +collaboration between teams that already have permissions to make contributions +to projects under the LLVM umbrella. + +Projects which can be considered for the LLVM incubator meet the following +criteria: + + * Must be generally aligned with the mission of the LLVM project to advance + compilers, languages, tools, runtimes, etc. + * Must conform to the license, patent, and code of conduct policies laid out + in this developer policy document. + * Must have a documented charter and development plan, e.g. in the form of a + README file, mission statement, and/or manifesto. + * Should conform to coding standards, incremental development process, and + other expectations. + * Should have a sense of the community that it hopes to eventually foster, and + there should be interest from members with different affiliations / + organizations. + * Should have a feasible path to eventually graduate as a dedicated top-level + or sub-project within the `LLVM monorepo + `_. + * Should include a notice (e.g. in the project README or web page) that the + project is in ‘incubation status’ and is not included in LLVM releases (see + suggested wording below). + * Must be proposed through the LLVM RFC process, and have its addition + approved by the LLVM community - this ultimately mediates the resolution of + the "should" concerns above. + +That said, the project need not have any code to get started, and need not have +an established community at all! Furthermore, incubating projects may pass +through transient states that violate the "Should" guidelines above, or would +otherwise make them unsuitable for direct inclusion in the monorepo (e.g. +dependencies that have not yet been factored appropriately, leveraging +experimental components or APIs that are not yet upstream, etc). + +When approved, the llvm-admin group can grant the new project: + * A new repository in the LLVM Github Organization - but not the LLVM monorepo. + * New mailing list, discourse forum, and/or discord chat hosted with other LLVM + forums. + * Other infrastructure integration can be discussed on a case-by-case basis. + +Graduation to the mono-repo would follow existing processes and standards for +becoming a first-class part of the monorepo. Similarly, an incubating project +may be eventually retired, but no process has been established for that yet. If +and when this comes up, please start an RFC discussion on llvm-dev. + +This process is very new - please expect the details to change, it is always +safe to ask on the `llvm-dev mailing list`_ about this. + +Suggested disclaimer for the project README and the main project web page: - * Start using the new features in LLVM's codebase. +:: -Here's a `sample RFC -`_ and the -`corresponding change `_. + This project is participating in the LLVM Incubator process: as such, it is + not part of any official LLVM release. While incubation status is not + necessarily a reflection of the completeness or stability of the code, it + does indicate that the project is not yet endorsed as a component of LLVM. .. _copyright-license-patents: @@ -744,7 +833,7 @@ OpenMP, etc), Polly, and all other subprojects. There are a few exceptions: is used by LLVM. * Some subprojects are impractical or uninteresting to relicense (e.g. llvm-gcc and dragonegg). These will be split off from the LLVM project (e.g. to - separate Github projects), allowing interested people to continue their + separate GitHub projects), allowing interested people to continue their development elsewhere. To relicense LLVM, we will be seeking approval from all of the copyright holders @@ -875,7 +964,7 @@ holds though):: Q2: If at any time after my contribution, I am able to license other patent claims that would have been subject to Apache's Grant of Patent License if - they were licenseable by me at the time of my contribution, do those other + they were licensable by me at the time of my contribution, do those other claims become subject to the Grant of Patent License? A2: Yes. @@ -943,3 +1032,5 @@ applications to the binary redistribution clause. This also means that it is ok to move code from (e.g.) libc++ to the LLVM core without concern, but that code cannot be moved from the LLVM core to libc++ without the copyright owner's permission. + +.. _llvm-dev mailing list: http://lists.llvm.org/mailman/listinfo/llvm-dev diff --git a/gnu/llvm/llvm/docs/Docker.rst b/gnu/llvm/llvm/docs/Docker.rst index 5a42cbe698d..5a61ff988b0 100644 --- a/gnu/llvm/llvm/docs/Docker.rst +++ b/gnu/llvm/llvm/docs/Docker.rst @@ -51,7 +51,7 @@ Overview The ``llvm/utils/docker`` folder contains Dockerfiles and simple bash scripts to serve as a basis for anyone who wants to create their own Docker image with LLVM components, compiled from sources. The sources are checked out from the -upstream svn repository when building the image. +upstream git repository when building the image. The resulting image contains only the requested LLVM components and a few extra packages to make the image minimally useful for C++ development, e.g. libstdc++ @@ -68,7 +68,7 @@ Usage ===== The ``llvm/utils/build_docker_image.sh`` script provides a rather high degree of control on how to run the build. It allows you to specify the projects to -checkout from svn and provide a list of CMake arguments to use during when +checkout from git and provide a list of CMake arguments to use during when building LLVM inside docker container. Here's a very simple example of getting a docker image with clang binary, diff --git a/gnu/llvm/llvm/docs/ExceptionHandling.rst b/gnu/llvm/llvm/docs/ExceptionHandling.rst index 18ff53cd3b6..3e4ebb4c2a7 100644 --- a/gnu/llvm/llvm/docs/ExceptionHandling.rst +++ b/gnu/llvm/llvm/docs/ExceptionHandling.rst @@ -670,15 +670,15 @@ all of the new IR instructions: entry: %obj = alloca %struct.Cleanup, align 4 %e = alloca i32, align 4 - %call = invoke %struct.Cleanup* @"\01??0Cleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) + %call = invoke %struct.Cleanup* @"??0Cleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) to label %invoke.cont unwind label %lpad.catch invoke.cont: ; preds = %entry - invoke void @"\01?may_throw@@YAXXZ"() + invoke void @"?may_throw@@YAXXZ"() to label %invoke.cont.2 unwind label %lpad.cleanup invoke.cont.2: ; preds = %invoke.cont - call void @"\01??_DCleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) nounwind + call void @"??_DCleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) nounwind br label %return return: ; preds = %invoke.cont.3, %invoke.cont.2 @@ -687,15 +687,15 @@ all of the new IR instructions: lpad.cleanup: ; preds = %invoke.cont.2 %0 = cleanuppad within none [] - call void @"\01??1Cleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) nounwind + call void @"??1Cleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) nounwind cleanupret %0 unwind label %lpad.catch lpad.catch: ; preds = %lpad.cleanup, %entry %1 = catchswitch within none [label %catch.body] unwind label %lpad.terminate catch.body: ; preds = %lpad.catch - %catch = catchpad within %1 [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i32* %e] - invoke void @"\01?may_throw@@YAXXZ"() + %catch = catchpad within %1 [%rtti.TypeDescriptor2* @"??_R0H@8", i32 0, i32* %e] + invoke void @"?may_throw@@YAXXZ"() to label %invoke.cont.3 unwind label %lpad.terminate invoke.cont.3: ; preds = %catch.body @@ -704,7 +704,7 @@ all of the new IR instructions: lpad.terminate: ; preds = %catch.body, %lpad.catch cleanuppad within none [] - call void @"\01?terminate@@YAXXZ" + call void @"?terminate@@YAXXZ" unreachable } diff --git a/gnu/llvm/llvm/docs/Extensions.rst b/gnu/llvm/llvm/docs/Extensions.rst index e6f7fdd5044..0fca0684593 100644 --- a/gnu/llvm/llvm/docs/Extensions.rst +++ b/gnu/llvm/llvm/docs/Extensions.rst @@ -157,7 +157,7 @@ is usually the associated section's comdat. 1. It must be a COMDAT section. 2. It cannot be another associative COMDAT section. -In the following example the symobl ``sym`` is the comdat symbol of ``.foo`` +In the following example the symbol ``sym`` is the comdat symbol of ``.foo`` and ``.bar`` is associated to ``.foo``. .. code-block:: gas @@ -213,7 +213,7 @@ ELF-Dependent ^^^^^^^^^^^^^^^^^^^^^^ In order to support creating multiple sections with the same name and comdat, -it is possible to add an unique number at the end of the ``.seciton`` directive. +it is possible to add an unique number at the end of the ``.section`` directive. For example, the following code creates two sections named ``.text``. .. code-block:: gas @@ -282,7 +282,7 @@ The following directives are specified: - libpath - The paramter identifies an additional library search path to be considered + The parameter identifies an additional library search path to be considered when looking up libraries after the inclusion of this option. ``SHT_LLVM_DEPENDENT_LIBRARIES`` Section (Dependent Libraries) @@ -417,7 +417,7 @@ Introduces a function ID that can be used with ``.cv_loc``. Includes caller, whether the caller is a real function or another inlined call site. Syntax: - ``.cv_inline_site_id`` *FunctionId* ``within`` *Function* ``inlined_at`` *FileNumber Line* [ *Colomn* ] + ``.cv_inline_site_id`` *FunctionId* ``within`` *Function* ``inlined_at`` *FileNumber Line* [ *Column* ] ``.cv_loc`` Directive ^^^^^^^^^^^^^^^^^^^^^ @@ -503,7 +503,7 @@ in the following fashion: sub.w sp, sp, r4 However, this has the limitation of 32 MiB (±16MiB). In order to accommodate -larger binaries, LLVM supports the use of ``-mcode-model=large`` to allow a 4GiB +larger binaries, LLVM supports the use of ``-mcmodel=large`` to allow a 4GiB range via a slight deviation. It will generate an indirect jump as follows: .. code-block:: gas @@ -544,7 +544,7 @@ in the following fashion: sub sp, sp, x15, lsl #4 However, this has the limitation of 256 MiB (±128MiB). In order to accommodate -larger binaries, LLVM supports the use of ``-mcode-model=large`` to allow a 8GiB +larger binaries, LLVM supports the use of ``-mcmodel=large`` to allow a 8GiB (±4GiB) range via a slight deviation. It will generate an indirect jump as follows: diff --git a/gnu/llvm/llvm/docs/FAQ.rst b/gnu/llvm/llvm/docs/FAQ.rst index 6ce6051e1f6..aef15d6dc71 100644 --- a/gnu/llvm/llvm/docs/FAQ.rst +++ b/gnu/llvm/llvm/docs/FAQ.rst @@ -12,8 +12,8 @@ License Can I modify LLVM source code and redistribute the modified source? ------------------------------------------------------------------- Yes. The modified source distribution must retain the copyright notice and -follow the conditions listed in the `LLVM license -`_. +follow the conditions listed in the `Apache License v2.0 with LLVM Exceptions +`_. Can I modify the LLVM source code and redistribute binaries or other tools based on it, without redistributing the source? @@ -72,9 +72,9 @@ What source languages are supported? ------------------------------------ LLVM currently has full support for C and C++ source languages through -`Clang `_. Many other language frontends have +`Clang `_. Many other language frontends have been written using LLVM, and an incomplete list is available at -`projects with LLVM `_. +`projects with LLVM `_. I'd like to write a self-hosting LLVM compiler. How should I interface with the LLVM middle-end optimizers and back-end code generators? diff --git a/gnu/llvm/llvm/docs/Frontend/PerformanceTips.rst b/gnu/llvm/llvm/docs/Frontend/PerformanceTips.rst index f0f63f3f9d6..f9e23fdbf88 100644 --- a/gnu/llvm/llvm/docs/Frontend/PerformanceTips.rst +++ b/gnu/llvm/llvm/docs/Frontend/PerformanceTips.rst @@ -27,7 +27,7 @@ can often be useful to write a quick C program with the semantics you're trying to model and see what decisions Clang's IRGen makes about what IR to emit. Studying Clang's CodeGen directory can also be a good source of ideas. Note that Clang and LLVM are explicitly version locked so you'll need to make sure -you're using a Clang built from the same svn revision or release as the LLVM +you're using a Clang built from the same git revision or release as the LLVM library you're using. As always, it's *strongly* recommended that you track tip of tree development, particularly during bring up of a new project. @@ -255,11 +255,11 @@ couple specific suggestions: #. For languages with numerous rarely executed guard conditions (e.g. null checks, type checks, range checks) consider adding an extra execution or - two of LoopUnswith and LICM to your pass order. The standard pass order, + two of LoopUnswitch and LICM to your pass order. The standard pass order, which is tuned for C and C++ applications, may not be sufficient to remove all dischargeable checks from loops. -#. If you language uses range checks, consider using the IRCE pass. It is not +#. If your language uses range checks, consider using the IRCE pass. It is not currently part of the standard pass order. #. A useful sanity check to run is to run your optimized IR back through the diff --git a/gnu/llvm/llvm/docs/FuzzingLLVM.rst b/gnu/llvm/llvm/docs/FuzzingLLVM.rst index ab4b9b557cd..e471020aab7 100644 --- a/gnu/llvm/llvm/docs/FuzzingLLVM.rst +++ b/gnu/llvm/llvm/docs/FuzzingLLVM.rst @@ -106,7 +106,7 @@ llvm-opt-fuzzer A |LLVM IR fuzzer| aimed at finding bugs in optimization passes. -It receives optimzation pipeline and runs it for each fuzzer input. +It receives optimization pipeline and runs it for each fuzzer input. Interface of this fuzzer almost directly mirrors ``llvm-isel-fuzzer``. Both ``mtriple`` and ``passes`` arguments are required. Passes are specified in a diff --git a/gnu/llvm/llvm/docs/GarbageCollection.rst b/gnu/llvm/llvm/docs/GarbageCollection.rst index 5e671bc10b6..ade944b6d45 100644 --- a/gnu/llvm/llvm/docs/GarbageCollection.rst +++ b/gnu/llvm/llvm/docs/GarbageCollection.rst @@ -958,7 +958,7 @@ a realistic example: // } __gcmap_; // Align to address width. - AP.EmitAlignment(IntPtrSize == 4 ? 2 : 3); + AP.emitAlignment(IntPtrSize == 4 ? 2 : 3); // Emit PointCount. OS.AddComment("safe point count"); @@ -970,7 +970,7 @@ a realistic example: // Emit the address of the safe point. OS.AddComment("safe point address"); MCSymbol *Label = PI->Label; - AP.EmitLabelPlusOffset(Label/*Hi*/, 0/*Offset*/, 4/*Size*/); + AP.emitLabelPlusOffset(Label/*Hi*/, 0/*Offset*/, 4/*Size*/); } // Stack information never change in safe points! Only print info from the diff --git a/gnu/llvm/llvm/docs/GettingInvolved.rst b/gnu/llvm/llvm/docs/GettingInvolved.rst index 343b226231a..7d242fefdd0 100644 --- a/gnu/llvm/llvm/docs/GettingInvolved.rst +++ b/gnu/llvm/llvm/docs/GettingInvolved.rst @@ -11,11 +11,13 @@ LLVM welcomes contributions of all kinds. To get started, please review the foll Contributing DeveloperPolicy + CodeReview SphinxQuickstartTemplate Phabricator HowToSubmitABug BugLifeCycle CodingStandards + GitBisecting :doc:`Contributing` An overview on how to contribute to LLVM. @@ -23,6 +25,9 @@ LLVM welcomes contributions of all kinds. To get started, please review the foll :doc:`DeveloperPolicy` The LLVM project's policy towards developers and their contributions. +:doc:`CodeReview` + The LLVM project's code-review process. + :doc:`SphinxQuickstartTemplate` A template + tutorial for writing new Sphinx documentation. It is meant to be read in source form. @@ -42,6 +47,9 @@ LLVM welcomes contributions of all kinds. To get started, please review the foll Details the LLVM coding standards and provides useful information on writing efficient C++ code. +:doc:`GitBisecting` + Describes how to use ``git bisect`` on LLVM's repository. + .. _development-process: Development Process @@ -182,6 +190,7 @@ can be better. Proposals/TestSuite Proposals/VariableNames Proposals/VectorizationPlan + Proposals/VectorPredication :doc:`CodeOfConduct` Proposal to adopt a code of conduct on the LLVM social spaces (lists, events, @@ -203,4 +212,7 @@ can be better. Proposal to change the variable names coding standard. :doc:`Proposals/VectorizationPlan` - Proposal to model the process and upgrade the infrastructure of LLVM's Loop Vectorizer. \ No newline at end of file + Proposal to model the process and upgrade the infrastructure of LLVM's Loop Vectorizer. + +:doc:`Proposals/VectorPredication` + Proposal for predicated vector instructions in LLVM. diff --git a/gnu/llvm/llvm/docs/GettingStarted.rst b/gnu/llvm/llvm/docs/GettingStarted.rst index 35c021ee320..478571bd4c2 100644 --- a/gnu/llvm/llvm/docs/GettingStarted.rst +++ b/gnu/llvm/llvm/docs/GettingStarted.rst @@ -16,7 +16,7 @@ files needed to process intermediate representations and converts it into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer. It also contains basic regression tests. -C-like languages use the `Clang `_ front end. This +C-like languages use the `Clang `_ front end. This component compiles C, C++, Objective C, and Objective C++ code into LLVM bitcode -- and from there into object files, using LLVM. @@ -28,7 +28,7 @@ Getting the Source Code and Building LLVM ========================================= The LLVM Getting Started documentation may be out of date. The `Clang -Getting Started `_ page might have more +Getting Started `_ page might have more accurate information. This is an example workflow and configuration to get and build the LLVM source: @@ -39,14 +39,14 @@ This is an example workflow and configuration to get and build the LLVM source: * Or, on windows, ``git clone --config core.autocrlf=false https://github.com/llvm/llvm-project.git`` -#. Configure and build LLVM and Clang:. +#. Configure and build LLVM and Clang: * ``cd llvm-project`` * ``mkdir build`` * ``cd build`` * ``cmake -G [options] ../llvm`` - Some common generators are: + Some common build system generators are: * ``Ninja`` --- for generating `Ninja `_ build files. Most llvm developers use Ninja. @@ -75,9 +75,11 @@ This is an example workflow and configuration to get and build the LLVM source: * ``-DLLVM_ENABLE_ASSERTIONS=On`` --- Compile with assertion checks enabled (default is Yes for Debug builds, No for all other build types). - * Run your build tool of choice! + * ``cmake --build . [--target ]`` or the build system specified + above directly. - * The default target (i.e. ``ninja`` or ``make``) will build all of LLVM. + * The default target (i.e. ``cmake --build .`` or ``make``) will build all of + LLVM. * The ``check-all`` target (i.e. ``ninja check-all``) will run the regression tests to ensure everything is in working order. @@ -85,10 +87,10 @@ This is an example workflow and configuration to get and build the LLVM source: * CMake will generate build targets for each tool and library, and most LLVM sub-projects generate their own ``check-`` target. - * Running a serial build will be *slow*. To improve speed, try running a - parallel build. That's done by default in Ninja; for ``make``, use - ``make -j NNN`` (NNN is the number of parallel jobs, use e.g. number of - CPUs you have.) + * Running a serial build will be **slow**. To improve speed, try running a + parallel build. That's done by default in Ninja; for ``make``, use the + option ``-j NN``, where ``NN`` is the number of parallel jobs, e.g. the + number of available CPUs. * For more information see `CMake `__ @@ -338,6 +340,16 @@ If you fail to set rpath, most LLVM binaries will fail on startup with a message from the loader similar to ``libstdc++.so.6: version `GLIBCXX_3.4.20' not found``. This means you need to tweak the -rpath linker flag. +This method will add an absolute path to the rpath of all executables. That's +fine for local development. If you want to distribute the binaries you build +so that they can run on older systems, copy ``libstdc++.so.6`` into the +``lib/`` directory. All of LLVM's shipping binaries have an rpath pointing at +``$ORIGIN/../lib``, so they will find ``libstdc++.so.6`` there. Non-distributed +binaries don't have an rpath set and won't find ``libstdc++.so.6``. Pass +``-DLLVM_LOCAL_RPATH="$HOME/toolchains/lib64"`` to cmake to add an absolute +path to ``libstdc++.so.6`` as above. Since these binaries are not distributed, +having an absolute local path is fine for them. + When you build Clang, you will need to give *it* access to modern C++ standard library in order to use it as your new host in part of a bootstrap. There are two easy ways to do this, either build (and install) libc++ along @@ -402,10 +414,7 @@ The files are as follows, with *x.y* marking the version number: Checkout LLVM from Git ---------------------- -You can also checkout the source code for LLVM from Git. While the LLVM -project's official source-code repository is Subversion, we are in the process -of migrating to git. We currently recommend that all developers use Git for -day-to-day development. +You can also checkout the source code for LLVM from Git. .. note:: @@ -448,8 +457,8 @@ either via emailing to llvm-commits, or, preferably, via :ref:`Phabricator You'll generally want to make sure your branch has a single commit, corresponding to the review you wish to send, up-to-date with the upstream ``origin/master`` branch, and doesn't contain merges. Once you have that, you -can use ``git show`` or ``git format-patch`` to output the diff, and attach it -to a Phabricator review (or to an email message). +can start `a Phabricator review `_ (or use ``git show`` or +``git format-patch`` to output the diff, and attach it to an email message). However, using the "Arcanist" tool is often easier. After `installing arcanist`_, you can upload the latest commit using: @@ -497,10 +506,45 @@ required access rights. See `committing a change `obtaining commit access `_ for commit access. +Here is an example workflow using git. This workflow assumes you have an +accepted commit on the branch named `branch-with-change`. + +.. code-block:: console + + # Go to the branch with your accepted commit. + % git checkout branch-with-change + # Rebase your change onto the latest commits on Github. + % git pull --rebase origin master + # Rerun the appropriate tests if needed. + % ninja check-$whatever + # Check that the list of commits about to be pushed is correct. + % git log origin/master...HEAD --oneline + # Push to Github. + % git push origin HEAD:master + LLVM currently has a linear-history policy, which means that merge commits are not allowed. The `llvm-project` repo on github is configured to reject pushes that include merges, so the `git rebase` step above is required. +Please ask for help if you're having trouble with your particular git workflow. + +Git pre-push hook +^^^^^^^^^^^^^^^^^ + +We include an optional pre-push hook that run some sanity checks on the revisions +you are about to push and ask confirmation if you push multiple commits at once. +You can set it up (on Unix systems) by running from the repository root: + +.. code-block:: console + + % ln -sf ../../llvm/utils/git/pre-push.py .git/hooks/pre-push + +Bisecting commits +^^^^^^^^^^^^^^^^^ + +See `Bisecting LLVM code `_ for how to use ``git bisect`` +on LLVM. + Reverting a change ^^^^^^^^^^^^^^^^^^ @@ -517,7 +561,7 @@ you need to check the code out of SVN rather than git for some reason, you can do it like so: * ``cd where-you-want-llvm-to-live`` -* Read-Only: ``svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm`` +* Read-Only: ``svn co https://llvm.org/svn/llvm-project/llvm/trunk llvm`` * Read-Write: ``svn co https://user@llvm.org/svn/llvm-project/llvm/trunk llvm`` This will create an '``llvm``' directory in the current directory and fully @@ -599,7 +643,7 @@ used by people developing LLVM. | | overridden with ``LLVM_DYLIB_COMPONENTS``. The | | | default contains most of LLVM and is defined in | | | ``tools/llvm-shlib/CMakelists.txt``. This option is| -| | not avialable on Windows. | +| | not available on Windows. | +-------------------------+----------------------------------------------------+ | LLVM_OPTIMIZED_TABLEGEN | Builds a release tablegen that gets used during | | | the LLVM build. This can dramatically speed up | @@ -717,7 +761,7 @@ Note: There are some additional flags that need to be passed when building for iOS due to limitations in the iOS SDK. Check :doc:`HowToCrossCompileLLVM` and `Clang docs on how to cross-compile in general -`_ for more information +`_ for more information about cross-compiling. The Location of LLVM Object Files @@ -784,7 +828,7 @@ Directory Layout One useful source of information about the LLVM source base is the LLVM `doxygen `_ documentation available at -``_. The following is a brief introduction to code +``_. The following is a brief introduction to code layout: ``llvm/examples`` @@ -1090,6 +1134,70 @@ If you are having problems building or using LLVM, or if you have any other general questions about LLVM, please consult the `Frequently Asked Questions `_ page. +If you are having problems with limited memory and build time, please try +building with ninja instead of make. Please consider configuring the +following options with cmake: + + * -G Ninja + Setting this option will allow you to build with ninja instead of make. + Building with ninja significantly improves your build time, especially with + incremental builds, and improves your memory usage. + + * -DLLVM_USE_LINKER + Setting this option to lld will significantly reduce linking time for LLVM + executables on ELF-based platforms, such as Linux. If you are building LLVM + for the first time and lld is not available to you as a binary package, then + you may want to use the gold linker as a faster alternative to GNU ld. + + * -DCMAKE_BUILD_TYPE + + - Debug --- This is the default build type. This disables optimizations while + compiling LLVM and enables debug info. On ELF-based platforms (e.g. Linux) + linking with debug info may consume a large amount of memory. + + - Release --- Turns on optimizations and disables debug info. Combining the + Release build type with -DLLVM_ENABLE_ASSERTIONS=ON may be a good trade-off + between speed and debugability during development, particularly for running + the test suite. + + * -DLLVM_ENABLE_ASSERTIONS + This option defaults to ON for Debug builds and defaults to OFF for Release + builds. As mentioned in the previous option, using the Release build type and + enabling assertions may be a good alternative to using the Debug build type. + + * -DLLVM_PARALLEL_LINK_JOBS + Set this equal to number of jobs you wish to run simultaneously. This is + similar to the -j option used with make, but only for link jobs. This option + can only be used with ninja. You may wish to use a very low number of jobs, + as this will greatly reduce the amount of memory used during the build + process. If you have limited memory, you may wish to set this to 1. + + * -DLLVM_TARGETS_TO_BUILD + Set this equal to the target you wish to build. You may wish to set this to + X86; however, you will find a full list of targets within the + llvm-project/llvm/lib/Target directory. + + * -DLLVM_OPTIMIZED_TABLEGEN + Set this to ON to generate a fully optimized tablegen during your build. This + will significantly improve your build time. This is only useful if you are + using the Debug build type. + + * -DLLVM_ENABLE_PROJECTS + Set this equal to the projects you wish to compile (e.g. clang, lld, etc.) If + compiling more than one project, separate the items with a semicolon. Should + you run into issues with the semicolon, try surrounding it with single quotes. + + * -DCLANG_ENABLE_STATIC_ANALYZER + Set this option to OFF if you do not require the clang static analyzer. This + should improve your build time slightly. + + * -DLLVM_USE_SPLIT_DWARF + Consider setting this to ON if you require a debug build, as this will ease + memory pressure on the linker. This will make linking much faster, as the + binaries will not contain any of the debug information; however, this will + generate the debug information in the form of a DWARF object file (with the + extension .dwo). This only applies to host platforms using ELF, such as Linux. + .. _links: Links @@ -1100,8 +1208,8 @@ things... there are many more interesting and complicated things that you can do that aren't documented here (but we'll gladly accept a patch if you want to write something up!). For more information about LLVM, check out: -* `LLVM Homepage `_ -* `LLVM Doxygen Tree `_ -* `Starting a Project that Uses LLVM `_ +* `LLVM Homepage `_ +* `LLVM Doxygen Tree `_ +* `Starting a Project that Uses LLVM `_ .. _installing arcanist: https://secure.phabricator.com/book/phabricator/article/arcanist_quick_start/ diff --git a/gnu/llvm/llvm/docs/GettingStartedVS.rst b/gnu/llvm/llvm/docs/GettingStartedVS.rst index 7507f97bac8..84d0ecf4d8f 100644 --- a/gnu/llvm/llvm/docs/GettingStartedVS.rst +++ b/gnu/llvm/llvm/docs/GettingStartedVS.rst @@ -18,7 +18,7 @@ to use LLVM. It contains an assembler, disassembler, bitcode analyzer and bitcode optimizer. It also contains basic regression tests that can be used to test the LLVM tools and the Clang front end. -The second piece is the `Clang `_ front end. This +The second piece is the `Clang `_ front end. This component compiles C, C++, Objective C, and Objective C++ code into LLVM bitcode. Clang typically uses LLVM libraries to optimize the bitcode and emit machine code. LLVM fully supports the COFF object file format, which is @@ -74,15 +74,12 @@ Here's the short story for getting up and running quickly with LLVM: (*or use WinZip*) 3. ``cd llvm`` - * With anonymous Subversion access: + * With git access: - *Note:* some regression tests require Unix-style line ending (``\n``). To - pass all regression tests, please add two lines *enable-auto-props = yes* - and *\* = svn:mime-type=application/octet-stream* to - ``C:\Users\\AppData\Roaming\Subversion\config``. + *Note:* some regression tests require Unix-style line ending (``\n``). 1. ``cd `` - 2. ``svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm`` + 2. ``git clone https://github.com/llvm/llvm-project.git llvm`` 3. ``cd llvm`` 5. Use `CMake `_ to generate up-to-date project files: @@ -103,7 +100,7 @@ Here's the short story for getting up and running quickly with LLVM: * See the :doc:`LLVM CMake guide ` for detailed information about how to configure the LLVM build. * CMake generates project files for all build types. To select a specific - build type, use the Configuration manager from the VS IDE or the + build type, use the Configuration manager from the VS IDE or the ``/property:Configuration`` command line option when using MSBuild. * By default, the Visual Studio project files generated by CMake use the 32-bit toolset. If you are developing on a 64-bit version of Windows and @@ -236,6 +233,6 @@ things... there are many more interesting and complicated things that you can do that aren't documented here (but we'll gladly accept a patch if you want to write something up!). For more information about LLVM, check out: -* `LLVM homepage `_ -* `LLVM doxygen tree `_ +* `LLVM homepage `_ +* `LLVM doxygen tree `_ diff --git a/gnu/llvm/llvm/docs/GitBisecting.rst b/gnu/llvm/llvm/docs/GitBisecting.rst new file mode 100644 index 00000000000..8f44e351a08 --- /dev/null +++ b/gnu/llvm/llvm/docs/GitBisecting.rst @@ -0,0 +1,125 @@ +=================== +Bisecting LLVM code +=================== + +Introduction +============ + +``git bisect`` is a useful tool for finding which revision caused a bug. + +This document describes how to use ``git bisect``. In particular, while LLVM +has a mostly linear history, it has a few merge commits that added projects -- +and these merged the linear history of those projects. As a consequence, the +LLVM repository has multiple roots: One "normal" root, and then one for each +toplevel project that was developed out-of-tree and then merged later. +As of early 2020, the only such merged project is MLIR, but flang will likely +be merged in a similar way soon. + +Basic operation +=============== + +See https://git-scm.com/docs/git-bisect for a good overview. In summary: + + .. code-block:: bash + + git bisect start + git bisect bad master + git bisect good f00ba + +git will check out a revision in between. Try to reproduce your problem at +that revision, and run ``git bisect good`` or ``git bisect bad``. + +If you can't repro at the current commit (maybe the build is broken), run +``git bisect skip`` and git will pick a nearby alternate commit. + +(To abort a bisect, run ``git bisect reset``, and if git complains about not +being able to reset, do the usual ``git checkout -f master; git reset --hard +origin/master`` dance and try again). + +``git bisect run`` +================== + +A single bisect step often requires first building clang, and then compiling +a large code base with just-built clang. This can take a long time, so it's +good if it can happen completely automatically. ``git bisect run`` can do +this for you if you write a run script that reproduces the problem +automatically. Writing the script can take 10-20 minutes, but it's almost +always worth it -- you can do something else while the bisect runs (such +as writing this document). + +Here's an example run script. It assumes that you're in ``llvm-project`` and +that you have a sibling ``llvm-build-project`` build directory where you +configured CMake to use Ninja. You have a file ``repro.c`` in the current +directory that makes clang crash at trunk, but it worked fine at revision +``f00ba``. + + .. code-block:: bash + + # Build clang. If the build fails, `exit 125` causes this + # revision to be skipped + ninja -C ../llvm-build-project clang || exit 125 + + ../llvm-build-project/bin/clang repro.c + +To make sure your run script works, it's a good idea to run ``./run.sh`` by +hand and tweak the script until it works, then run ``git bisect good`` or +``git bisect bad`` manually once based on the result of the script +(check ``echo $?`` after your script ran), and only then run ``git bisect run +./run.sh``. Don't forget to mark your run script as executable -- ``git bisect +run`` doesn't check for that, it just assumes the run script failed each time. + +Once your run script works, run ``git bisect run ./run.sh`` and a few hours +later you'll know which commit caused the regression. + +(This is a very simple run script. Often, you want to use just-built clang +to build a different project and then run a built executable of that project +in the run script.) + +Bisecting across multiple roots +=============================== + +Here's how LLVM's history currently looks: + + .. code-block:: none + + A-o-o-......-o-D-o-o-HEAD + / + B-o-...-o-C- + +``A`` is the first commit in LLVM ever, ``97724f18c79c``. + +``B`` is the first commit in MLIR, ``aed0d21a62db``. + +``D`` is the merge commit that merged MLIR into the main LLVM repository, +``0f0d0ed1c78f``. + +``C`` is the last commit in MLIR before it got merged, ``0f0d0ed1c78f^2``. (The +``^n`` modifier selects the n'th parent of a merge commit.) + +``git bisect`` goes through all parent revisions. Due to the way MLIR was +merged, at every revision at ``C`` or earlier, *only* the ``mlir/`` directory +exists, and nothing else does. + +As of early 2020, there is no flag to ``git bisect`` to tell it to not +descend into all reachable commits. Ideally, we'd want to tell it to only +follow the first parent of ``D``. + +The best workaround is to pass a list of directories to ``git bisect``: +If you know the bug is due to a change in llvm, clang, or compiler-rt, use + + .. code-block:: bash + + git bisect start -- clang llvm compiler-rt + +That way, the commits in ``mlir`` are never evaluated. + +Alternatively, ``git bisect skip aed0d21a6 aed0d21a6..0f0d0ed1c78f`` explicitly +skips all commits on that branch. It takes 1.5 minutes to run on a fast +machine, and makes ``git bisect log`` output unreadable. (``aed0d21a6`` is +listed twice because git ranges exclude the revision listed on the left, +so it needs to be ignored explicitly.) + +More Resources +============== + +https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection diff --git a/gnu/llvm/llvm/docs/GlobalISel/GMIR.rst b/gnu/llvm/llvm/docs/GlobalISel/GMIR.rst index 52f38641476..ca0d6069222 100644 --- a/gnu/llvm/llvm/docs/GlobalISel/GMIR.rst +++ b/gnu/llvm/llvm/docs/GlobalISel/GMIR.rst @@ -76,7 +76,7 @@ generic and non-generic). There are some exceptions to this but in general: way of getting a given operand's type (as there was no 1:1 mapping between instruction types and operands). We considered putting the type in some variant of MCInstrDesc instead: - See `PR26576 `_: [GlobalISel] Generic MachineInstrs + See `PR26576 `_: [GlobalISel] Generic MachineInstrs need a type but this increases the memory footprint of the related objects .. _gmir-regbank: diff --git a/gnu/llvm/llvm/docs/GlobalISel/GenericOpcode.rst b/gnu/llvm/llvm/docs/GlobalISel/GenericOpcode.rst index 5cc1023db23..5c0be7ef70b 100644 --- a/gnu/llvm/llvm/docs/GlobalISel/GenericOpcode.rst +++ b/gnu/llvm/llvm/docs/GlobalISel/GenericOpcode.rst @@ -152,9 +152,11 @@ Convert a pointer to an integer. G_BITCAST ^^^^^^^^^ -Reinterpret a value as a new type. This is usually done without changing any -bits but this is not always the case due a sublety in the definition of the -:ref:`LLVM-IR Bitcast Instruction `. +Reinterpret a value as a new type. This is usually done without +changing any bits but this is not always the case due a sublety in the +definition of the :ref:`LLVM-IR Bitcast Instruction `. It +is allowed to bitcast between pointers with the same size, but +different address spaces. .. code-block:: none @@ -243,6 +245,15 @@ These each perform their respective integer arithmetic on a scalar. %2:_(s32) = G_ADD %0:_(s32), %1:_(s32) +G_SADDSAT, G_UADDSAT, G_SSUBSAT, G_USUBSAT +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Signed and unsigned addition and subtraction with saturation. + +.. code-block:: none + + %2:_(s32) = G_SADDSAT %0:_(s32), %1:_(s32) + G_SHL, G_LSHR, G_ASHR ^^^^^^^^^^^^^^^^^^^^^ @@ -278,14 +289,16 @@ typically bytes but this may vary between targets. There are currently no in-tree targets that use this with addressable units not equal to 8 bit. -G_PTR_MASK +G_PTRMASK ^^^^^^^^^^ -Zero the least significant N bits of a pointer. +Zero out an arbitrary mask of bits of a pointer. The mask type must be +an integer, and the number of vector elements must match for all +operands. This corresponds to `i_intr_llvm_ptrmask`. .. code-block:: none - %1:_(p0) = G_PTR_MASK %0, 3 + %2:_(p0) = G_PTRMASK %0, %1 G_SMIN, G_SMAX, G_UMIN, G_UMAX ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -556,7 +569,11 @@ Same as G_INDEXED_LOAD except that the load performed is zero-extending, as with G_STORE ^^^^^^^ -Generic store. Expects a MachineMemOperand in addition to explicit operands. +Generic store. Expects a MachineMemOperand in addition to explicit +operands. If the stored value size is greater than the memory size, +the high bits are implicitly truncated. If this is a vector store, the +high elements are discarded (i.e. this does not function as a per-lane +vector, truncating store) G_INDEXED_STORE ^^^^^^^^^^^^^^^ @@ -633,7 +650,7 @@ G_INTRINSIC, G_INTRINSIC_W_SIDE_EFFECTS Call an intrinsic The _W_SIDE_EFFECTS version is considered to have unknown side-effects and -as such cannot be reordered acrosss other side-effecting instructions. +as such cannot be reordered across other side-effecting instructions. .. note:: @@ -663,12 +680,9 @@ Other Operations G_DYN_STACKALLOC ^^^^^^^^^^^^^^^^ -Dynamically realign the stack pointer to the specified alignment +Dynamically realigns the stack pointer to the specified size and alignment. +An alignment value of `0` or `1` mean no specific alignment. .. code-block:: none %8:_(p0) = G_DYN_STACKALLOC %7(s64), 32 - -.. caution:: - - What does it mean for the immediate to be 0? It happens in the tests diff --git a/gnu/llvm/llvm/docs/GlobalISel/IRTranslator.rst b/gnu/llvm/llvm/docs/GlobalISel/IRTranslator.rst index a4d9bdad201..712fe95a829 100644 --- a/gnu/llvm/llvm/docs/GlobalISel/IRTranslator.rst +++ b/gnu/llvm/llvm/docs/GlobalISel/IRTranslator.rst @@ -73,7 +73,7 @@ This differs from SelectionDAG's multiple vregs via ``GetValueVTs``. As some of the bits are undef (padding), we should consider augmenting the representation with additional metadata (in effect, caching computeKnownBits information on vregs). -See `PR26161 `_: [GlobalISel] Value to vreg during +See `PR26161 `_: [GlobalISel] Value to vreg during IR to MachineInstr translation for aggregate type .. _irtranslator-constants: diff --git a/gnu/llvm/llvm/docs/GlobalISel/KnownBits.rst b/gnu/llvm/llvm/docs/GlobalISel/KnownBits.rst index 49989f9c9c6..7e628722d53 100644 --- a/gnu/llvm/llvm/docs/GlobalISel/KnownBits.rst +++ b/gnu/llvm/llvm/docs/GlobalISel/KnownBits.rst @@ -97,4 +97,4 @@ Then it's just a matter of fetching the analysis and using it: } There are many more API's beyond ``getKnownBits()``. See the `API reference -`_ for more information +`_ for more information diff --git a/gnu/llvm/llvm/docs/GwpAsan.rst b/gnu/llvm/llvm/docs/GwpAsan.rst index 67193bfe001..647c2a038a5 100644 --- a/gnu/llvm/llvm/docs/GwpAsan.rst +++ b/gnu/llvm/llvm/docs/GwpAsan.rst @@ -55,7 +55,7 @@ Allocator Support GWP-ASan is not a replacement for a traditional allocator. Instead, it works by inserting stubs into a supporting allocator to redirect allocations to GWP-ASan when they're chosen to be sampled. These stubs are generally implemented in the -implementaion of ``malloc()``, ``free()`` and ``realloc()``. The stubs are +implementation of ``malloc()``, ``free()`` and ``realloc()``. The stubs are extremely small, which makes using GWP-ASan in most allocators fairly trivial. The stubs follow the same general pattern (example ``malloc()`` pseudocode below): diff --git a/gnu/llvm/llvm/docs/HistoricalNotes/2007-OriginalClangReadme.txt b/gnu/llvm/llvm/docs/HistoricalNotes/2007-OriginalClangReadme.txt index 611dc9d2c01..1759ad1e1f9 100644 --- a/gnu/llvm/llvm/docs/HistoricalNotes/2007-OriginalClangReadme.txt +++ b/gnu/llvm/llvm/docs/HistoricalNotes/2007-OriginalClangReadme.txt @@ -125,7 +125,7 @@ II. Usage of clang driver: invoking Graphviz. For more information on getting Graphviz to work with clang/LLVM, - see: http://llvm.org/docs/ProgrammersManual.html#ViewGraph + see: https://llvm.org/docs/ProgrammersManual.html#ViewGraph III. Current advantages over GCC: diff --git a/gnu/llvm/llvm/docs/HowToAddABuilder.rst b/gnu/llvm/llvm/docs/HowToAddABuilder.rst index 30703c858e4..a30073d9251 100644 --- a/gnu/llvm/llvm/docs/HowToAddABuilder.rst +++ b/gnu/llvm/llvm/docs/HowToAddABuilder.rst @@ -81,7 +81,9 @@ Here are the steps you can follow to do so: buildbot documentation for help. You may want to restart your computer to see if it works. -#. Send a patch which adds your build slave and your builder to zorg. +#. Send a patch which adds your build slave and your builder to + `zorg `_. Use the typical LLVM + `workflow `_. * slaves are added to ``buildbot/osuosl/master/config/slaves.py`` * builders are added to ``buildbot/osuosl/master/config/builders.py`` @@ -89,7 +91,7 @@ Here are the steps you can follow to do so: Please make sure your builder name and its builddir are unique through the file. - It is possible to whitelist email addresses to unconditionally receive + It is possible to allow email addresses to unconditionally receive notifications on build failure; for this you'll need to add an ``InformativeMailNotifier`` to ``buildbot/osuosl/master/config/status.py``. This is particularly useful for the staging buildmaster which is silent diff --git a/gnu/llvm/llvm/docs/HowToBuildOnARM.rst b/gnu/llvm/llvm/docs/HowToBuildOnARM.rst index 356c846d82b..f28f8b3ae2d 100644 --- a/gnu/llvm/llvm/docs/HowToBuildOnARM.rst +++ b/gnu/llvm/llvm/docs/HowToBuildOnARM.rst @@ -22,7 +22,7 @@ on the ARMv6 and ARMv7 architectures and may be inapplicable to older chips. Pandaboard, have become hard-float platforms. There are a number of choices when using CMake. Autoconf usage is deprecated as of 3.8. - Building LLVM/Clang in ``Relese`` mode is preferred since it consumes + Building LLVM/Clang in ``Release`` mode is preferred since it consumes a lot less memory. Otherwise, the building process will very likely fail due to insufficient memory. It's also a lot quicker to only build the relevant back-ends (ARM and AArch64), since it's very unlikely that @@ -42,7 +42,7 @@ on the ARMv6 and ARMv7 architectures and may be inapplicable to older chips. Use Ninja instead of Make: "-G Ninja" Build with assertions on: "-DLLVM_ENABLE_ASSERTIONS=True" Force Python2: "-DPYTHON_EXECUTABLE=/usr/bin/python2" - Local (non-sudo) install path: "-DCMAKE_INSTALL_PREFIX=$HOME/llvm/instal" + Local (non-sudo) install path: "-DCMAKE_INSTALL_PREFIX=$HOME/llvm/install" CPU flags: "DCMAKE_C_FLAGS=-mcpu=cortex-a15" (same for CXX_FLAGS) After that, just typing ``make -jN`` or ``ninja`` will build everything. diff --git a/gnu/llvm/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst b/gnu/llvm/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst index 6ad93c773b2..72dfea4eb68 100644 --- a/gnu/llvm/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst +++ b/gnu/llvm/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst @@ -43,7 +43,7 @@ compiler-rt must be placed in the runtimes directory. ``qemu-arm`` should be available as a package for your Linux distribution. -The most complicated of the prequisites to satisfy is the arm-linux-gnueabihf +The most complicated of the prerequisites to satisfy is the arm-linux-gnueabihf sysroot. In theory it is possible to use the Linux distributions multiarch support to fulfill the dependencies for building but unfortunately due to /usr/local/include being added some host includes are selected. The easiest way diff --git a/gnu/llvm/llvm/docs/HowToCrossCompileLLVM.rst b/gnu/llvm/llvm/docs/HowToCrossCompileLLVM.rst index e71c0b07a7a..d2dc7bf60e5 100644 --- a/gnu/llvm/llvm/docs/HowToCrossCompileLLVM.rst +++ b/gnu/llvm/llvm/docs/HowToCrossCompileLLVM.rst @@ -9,7 +9,7 @@ This document contains information about building LLVM and Clang on host machine, targeting another platform. For more information on how to use Clang as a cross-compiler, -please check http://clang.llvm.org/docs/CrossCompilation.html. +please check https://clang.llvm.org/docs/CrossCompilation.html. TODO: Add MIPS and other platforms to this document. @@ -189,7 +189,7 @@ identification), like: If you copy that tarball to your target board, you'll be able to use it for running the test-suite, for example. Follow the guidelines at -http://llvm.org/docs/lnt/quickstart.html, unpack the tarball in the +https://llvm.org/docs/lnt/quickstart.html, unpack the tarball in the test directory, and use options: .. code-block:: bash diff --git a/gnu/llvm/llvm/docs/HowToSetUpLLVMStyleRTTI.rst b/gnu/llvm/llvm/docs/HowToSetUpLLVMStyleRTTI.rst index 38929948590..821b00ab7ec 100644 --- a/gnu/llvm/llvm/docs/HowToSetUpLLVMStyleRTTI.rst +++ b/gnu/llvm/llvm/docs/HowToSetUpLLVMStyleRTTI.rst @@ -380,8 +380,8 @@ contract, you can tweak and optimize it as much as you want. For example, LLVM-style RTTI can work fine in the presence of multiple-inheritance by defining an appropriate ``classof``. An example of this in practice is -`Decl `_ vs. -`DeclContext `_ +`Decl `_ vs. +`DeclContext `_ inside Clang. The ``Decl`` hierarchy is done very similarly to the example setup demonstrated in this tutorial. @@ -396,7 +396,7 @@ returning true for ones that are known to be ``DeclContext``'s. Touch on some of the more advanced features, like ``isa_impl`` and ``simplify_type``. However, those two need reference documentation in the form of doxygen comments as well. We need the doxygen so that we can - say "for full details, see http://llvm.org/doxygen/..." + say "for full details, see https://llvm.org/doxygen/..." Rules of Thumb ============== @@ -412,3 +412,58 @@ Rules of Thumb #. For each class in the hierarchy that has children, implement a ``classof`` that checks a range of the first child's ``Kind`` and the last child's ``Kind``. + +RTTI for Open Class Hierarchies +=============================== + +Sometimes it is not possible to know all types in a hierarchy ahead of time. +For example, in the shapes hierarchy described above the authors may have +wanted their code to work for user defined shapes too. To support use cases +that require open hierarchies LLVM provides the ``RTTIRoot`` and +``RTTIExtends`` utilities. + +The ``RTTIRoot`` class describes an interface for performing RTTI checks. The +``RTTIExtends`` class template provides an implementation of this interface +for classes derived from ``RTTIRoot``. ``RTTIExtends`` uses the "`Curiously +Recurring Template Idiom`_", taking the class being defined as its first +template argument and the parent class as the second argument. Any class that +uses ``RTTIExtends`` must define a ``static char ID`` member, the address of +which will be used to identify the type. + +This open-hierarchy RTTI support should only be used if your use case requries +it. Otherwise the standard LLVM RTTI system should be preferred. + +.. _`Curiously Recurring Template Idiom`: + https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern + +E.g. + +.. code-block:: c++ + + class Shape : public RTTIExtends { + public: + static char ID; + virtual double computeArea() = 0; + }; + + class Square : public RTTIExtends { + double SideLength; + public: + static char ID; + + Square(double S) : SideLength(S) {} + double computeArea() override; + }; + + class Circle : public RTTIExtends { + double Radius; + public: + static char ID; + + Circle(double R) : Radius(R) {} + double computeArea() override; + }; + + char Shape::ID = 0; + char Square::ID = 0; + char Circle::ID = 0; diff --git a/gnu/llvm/llvm/docs/HowToSubmitABug.rst b/gnu/llvm/llvm/docs/HowToSubmitABug.rst index d276ee8681f..58c020fbaed 100644 --- a/gnu/llvm/llvm/docs/HowToSubmitABug.rst +++ b/gnu/llvm/llvm/docs/HowToSubmitABug.rst @@ -10,6 +10,8 @@ If you're working with LLVM and run into a bug, we definitely want to know about it. This document describes what you can do to increase the odds of getting it fixed quickly. +🔒 If you believe that the bug is security related, please follow :ref:`report-security-issue`. 🔒 + Basically you have to do two things at a minimum. First, decide whether the bug `crashes the compiler`_ (or an LLVM pass), or if the compiler is `miscompiling`_ the program (i.e., the @@ -26,7 +28,7 @@ contain the following information: * All information necessary to reproduce the problem. * The reduced test-case that triggers the bug. -* The location where you obtained LLVM (if not from our Subversion +* The location where you obtained LLVM (if not from our Git repository). Thanks for helping us make LLVM better! diff --git a/gnu/llvm/llvm/docs/HowToUpdateDebugInfo.rst b/gnu/llvm/llvm/docs/HowToUpdateDebugInfo.rst new file mode 100644 index 00000000000..3283bfd8933 --- /dev/null +++ b/gnu/llvm/llvm/docs/HowToUpdateDebugInfo.rst @@ -0,0 +1,424 @@ +======================================================= +How to Update Debug Info: A Guide for LLVM Pass Authors +======================================================= + +.. contents:: + :local: + +Introduction +============ + +Certain kinds of code transformations can inadvertently result in a loss of +debug info, or worse, make debug info misrepresent the state of a program. + +This document specifies how to correctly update debug info in various kinds of +code transformations, and offers suggestions for how to create targeted debug +info tests for arbitrary transformations. + +For more on the philosophy behind LLVM debugging information, see +:doc:`SourceLevelDebugging`. + +Rules for updating debug locations +================================== + +.. _WhenToPreserveLocation: + +When to preserve an instruction location +---------------------------------------- + +A transformation should preserve the debug location of an instruction if the +instruction either remains in its basic block, or if its basic block is folded +into a predecessor that branches unconditionally. The APIs to use are +``IRBuilder``, or ``Instruction::setDebugLoc``. + +The purpose of this rule is to ensure that common block-local optimizations +preserve the ability to set breakpoints on source locations corresponding to +the instructions they touch. Debugging, crash logs, and SamplePGO accuracy +would be severely impacted if that ability were lost. + +Examples of transformations that should follow this rule include: + +* Instruction scheduling. Block-local instruction reordering should not drop + source locations, even though this may lead to jumpy single-stepping + behavior. + +* Simple jump threading. For example, if block ``B1`` unconditionally jumps to + ``B2``, *and* is its unique predecessor, instructions from ``B2`` can be + hoisted into ``B1``. Source locations from ``B2`` should be preserved. + +* Peephole optimizations that replace or expand an instruction, like ``(add X + X) => (shl X 1)``. The location of the ``shl`` instruction should be the same + as the location of the ``add`` instruction. + +* Tail duplication. For example, if blocks ``B1`` and ``B2`` both + unconditionally branch to ``B3`` and ``B3`` can be folded into its + predecessors, source locations from ``B3`` should be preserved. + +Examples of transformations for which this rule *does not* apply include: + +* LICM. E.g., if an instruction is moved from the loop body to the preheader, + the rule for :ref:`dropping locations` applies. + +.. _WhenToMergeLocation: + +When to merge instruction locations +----------------------------------- + +A transformation should merge instruction locations if it replaces multiple +instructions with a single merged instruction, *and* that merged instruction +does not correspond to any of the original instructions' locations. The API to +use is ``Instruction::applyMergedLocation``. + +The purpose of this rule is to ensure that a) the single merged instruction +has a location with an accurate scope attached, and b) to prevent misleading +single-stepping (or breakpoint) behavior. Often, merged instructions are memory +accesses which can trap: having an accurate scope attached greatly assists in +crash triage by identifying the (possibly inlined) function where the bad +memory access occurred. This rule is also meant to assist SamplePGO by banning +scenarios in which a sample of a block containing a merged instruction is +misattributed to a block containing one of the instructions-to-be-merged. + +Examples of transformations that should follow this rule include: + +* Merging identical loads/stores which occur on both sides of a CFG diamond + (see the ``MergedLoadStoreMotion`` pass). + +* Merging identical loop-invariant stores (see the LICM utility + ``llvm::promoteLoopAccessesToScalars``). + +* Peephole optimizations which combine multiple instructions together, like + ``(add (mul A B) C) => llvm.fma.f32(A, B, C)``. Note that the location of + the ``fma`` does not exactly correspond to the locations of either the + ``mul`` or the ``add`` instructions. + +Examples of transformations for which this rule *does not* apply include: + +* Block-local peepholes which delete redundant instructions, like + ``(sext (zext i8 %x to i16) to i32) => (zext i8 %x to i32)``. The inner + ``zext`` is modified but remains in its block, so the rule for + :ref:`preserving locations` should apply. + +* Converting an if-then-else CFG diamond into a ``select``. Preserving the + debug locations of speculated instructions can make it seem like a condition + is true when it's not (or vice versa), which leads to a confusing + single-stepping experience. The rule for + :ref:`dropping locations` should apply here. + +* Hoisting identical instructions which appear in several successor blocks into + a predecessor block (see ``BranchFolder::HoistCommonCodeInSuccs``). In this + case there is no single merged instruction. The rule for + :ref:`dropping locations` applies. + +.. _WhenToDropLocation: + +When to drop an instruction location +------------------------------------ + +A transformation should drop debug locations if the rules for +:ref:`preserving` and +:ref:`merging` debug locations do not apply. The API to +use is ``Instruction::setDebugLoc()``. + +The purpose of this rule is to prevent erratic or misleading single-stepping +behavior in situations in which an instruction has no clear, unambiguous +relationship to a source location. + +To handle an instruction without a location, the DWARF generator +defaults to allowing the last-set location after a label to cascade forward, or +to setting a line 0 location with viable scope information if no previous +location is available. + +See the discussion in the section about +:ref:`merging locations` for examples of when the rule for +dropping locations applies. + +Rules for updating debug values +=============================== + +Deleting an IR-level Instruction +-------------------------------- + +When an ``Instruction`` is deleted, its debug uses change to ``undef``. This is +a loss of debug info: the value of one or more source variables becomes +unavailable, starting with the ``llvm.dbg.value(undef, ...)``. When there is no +way to reconstitute the value of the lost instruction, this is the best +possible outcome. However, it's often possible to do better: + +* If the dying instruction can be RAUW'd, do so. The + ``Value::replaceAllUsesWith`` API transparently updates debug uses of the + dying instruction to point to the replacement value. + +* If the dying instruction cannot be RAUW'd, call ``llvm::salvageDebugInfo`` on + it. This makes a best-effort attempt to rewrite debug uses of the dying + instruction by describing its effect as a ``DIExpression``. + +* If one of the **operands** of a dying instruction would become trivially + dead, use ``llvm::replaceAllDbgUsesWith`` to rewrite the debug uses of that + operand. Consider the following example function: + +.. code-block:: llvm + + define i16 @foo(i16 %a) { + %b = sext i16 %a to i32 + %c = and i32 %b, 15 + call void @llvm.dbg.value(metadata i32 %c, ...) + %d = trunc i32 %c to i16 + ret i16 %d + } + +Now, here's what happens after the unnecessary truncation instruction ``%d`` is +replaced with a simplified instruction: + +.. code-block:: llvm + + define i16 @foo(i16 %a) { + call void @llvm.dbg.value(metadata i32 undef, ...) + %simplified = and i16 %a, 15 + ret i16 %simplified + } + +Note that after deleting ``%d``, all uses of its operand ``%c`` become +trivially dead. The debug use which used to point to ``%c`` is now ``undef``, +and debug info is needlessly lost. + +To solve this problem, do: + +.. code-block:: cpp + + llvm::replaceAllDbgUsesWith(%c, theSimplifiedAndInstruction, ...) + +This results in better debug info because the debug use of ``%c`` is preserved: + +.. code-block:: llvm + + define i16 @foo(i16 %a) { + %simplified = and i16 %a, 15 + call void @llvm.dbg.value(metadata i16 %simplified, ...) + ret i16 %simplified + } + +You may have noticed that ``%simplified`` is narrower than ``%c``: this is not +a problem, because ``llvm::replaceAllDbgUsesWith`` takes care of inserting the +necessary conversion operations into the DIExpressions of updated debug uses. + +Deleting a MIR-level MachineInstr +--------------------------------- + +TODO + +How to automatically convert tests into debug info tests +======================================================== + +.. _IRDebugify: + +Mutation testing for IR-level transformations +--------------------------------------------- + +An IR test case for a transformation can, in many cases, be automatically +mutated to test debug info handling within that transformation. This is a +simple way to test for proper debug info handling. + +The ``debugify`` utility +^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``debugify`` testing utility is just a pair of passes: ``debugify`` and +``check-debugify``. + +The first applies synthetic debug information to every instruction of the +module, and the second checks that this DI is still available after an +optimization has occurred, reporting any errors/warnings while doing so. + +The instructions are assigned sequentially increasing line locations, and are +immediately used by debug value intrinsics everywhere possible. + +For example, here is a module before: + +.. code-block:: llvm + + define void @f(i32* %x) { + entry: + %x.addr = alloca i32*, align 8 + store i32* %x, i32** %x.addr, align 8 + %0 = load i32*, i32** %x.addr, align 8 + store i32 10, i32* %0, align 4 + ret void + } + +and after running ``opt -debugify``: + +.. code-block:: llvm + + define void @f(i32* %x) !dbg !6 { + entry: + %x.addr = alloca i32*, align 8, !dbg !12 + call void @llvm.dbg.value(metadata i32** %x.addr, metadata !9, metadata !DIExpression()), !dbg !12 + store i32* %x, i32** %x.addr, align 8, !dbg !13 + %0 = load i32*, i32** %x.addr, align 8, !dbg !14 + call void @llvm.dbg.value(metadata i32* %0, metadata !11, metadata !DIExpression()), !dbg !14 + store i32 10, i32* %0, align 4, !dbg !15 + ret void, !dbg !16 + } + + !llvm.dbg.cu = !{!0} + !llvm.debugify = !{!3, !4} + !llvm.module.flags = !{!5} + + !0 = distinct !DICompileUnit(language: DW_LANG_C, file: !1, producer: "debugify", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2) + !1 = !DIFile(filename: "debugify-sample.ll", directory: "/") + !2 = !{} + !3 = !{i32 5} + !4 = !{i32 2} + !5 = !{i32 2, !"Debug Info Version", i32 3} + !6 = distinct !DISubprogram(name: "f", linkageName: "f", scope: null, file: !1, line: 1, type: !7, isLocal: false, isDefinition: true, scopeLine: 1, isOptimized: true, unit: !0, retainedNodes: !8) + !7 = !DISubroutineType(types: !2) + !8 = !{!9, !11} + !9 = !DILocalVariable(name: "1", scope: !6, file: !1, line: 1, type: !10) + !10 = !DIBasicType(name: "ty64", size: 64, encoding: DW_ATE_unsigned) + !11 = !DILocalVariable(name: "2", scope: !6, file: !1, line: 3, type: !10) + !12 = !DILocation(line: 1, column: 1, scope: !6) + !13 = !DILocation(line: 2, column: 1, scope: !6) + !14 = !DILocation(line: 3, column: 1, scope: !6) + !15 = !DILocation(line: 4, column: 1, scope: !6) + !16 = !DILocation(line: 5, column: 1, scope: !6) + +Using ``debugify`` +^^^^^^^^^^^^^^^^^^ + +A simple way to use ``debugify`` is as follows: + +.. code-block:: bash + + $ opt -debugify -pass-to-test -check-debugify sample.ll + +This will inject synthetic DI to ``sample.ll`` run the ``pass-to-test`` and +then check for missing DI. The ``-check-debugify`` step can of course be +omitted in favor of more customizable FileCheck directives. + +Some other ways to run debugify are available: + +.. code-block:: bash + + # Same as the above example. + $ opt -enable-debugify -pass-to-test sample.ll + + # Suppresses verbose debugify output. + $ opt -enable-debugify -debugify-quiet -pass-to-test sample.ll + + # Prepend -debugify before and append -check-debugify -strip after + # each pass on the pipeline (similar to -verify-each). + $ opt -debugify-each -O2 sample.ll + +In order for ``check-debugify`` to work, the DI must be coming from +``debugify``. Thus, modules with existing DI will be skipped. + +``debugify`` can be used to test a backend, e.g: + +.. code-block:: bash + + $ opt -debugify < sample.ll | llc -o - + +There is also a MIR-level debugify pass that can be run before each backend +pass, see: +:ref:`Mutation testing for MIR-level transformations`. + +``debugify`` in regression tests +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The output of the ``debugify`` pass must be stable enough to use in regression +tests. Changes to this pass are not allowed to break existing tests. + +.. note:: + + Regression tests must be robust. Avoid hardcoding line/variable numbers in + check lines. In cases where this can't be avoided (say, if a test wouldn't + be precise enough), moving the test to its own file is preferred. + +.. _MIRDebugify: + +Mutation testing for MIR-level transformations +---------------------------------------------- + +A variant of the ``debugify`` utility described in +:ref:`Mutation testing for IR-level transformations` can be used +for MIR-level transformations as well: much like the IR-level pass, +``mir-debugify`` inserts sequentially increasing line locations to each +``MachineInstr`` in a ``Module`` (although there is no equivalent MIR-level +``check-debugify`` pass). + +For example, here is a snippet before: + +.. code-block:: llvm + + name: test + body: | + bb.1 (%ir-block.0): + %0:_(s32) = IMPLICIT_DEF + %1:_(s32) = IMPLICIT_DEF + %2:_(s32) = G_CONSTANT i32 2 + %3:_(s32) = G_ADD %0, %2 + %4:_(s32) = G_SUB %3, %1 + +and after running ``llc -run-pass=mir-debugify``: + +.. code-block:: llvm + + name: test + body: | + bb.0 (%ir-block.0): + %0:_(s32) = IMPLICIT_DEF debug-location !12 + DBG_VALUE %0(s32), $noreg, !9, !DIExpression(), debug-location !12 + %1:_(s32) = IMPLICIT_DEF debug-location !13 + DBG_VALUE %1(s32), $noreg, !11, !DIExpression(), debug-location !13 + %2:_(s32) = G_CONSTANT i32 2, debug-location !14 + DBG_VALUE %2(s32), $noreg, !9, !DIExpression(), debug-location !14 + %3:_(s32) = G_ADD %0, %2, debug-location !DILocation(line: 4, column: 1, scope: !6) + DBG_VALUE %3(s32), $noreg, !9, !DIExpression(), debug-location !DILocation(line: 4, column: 1, scope: !6) + %4:_(s32) = G_SUB %3, %1, debug-location !DILocation(line: 5, column: 1, scope: !6) + DBG_VALUE %4(s32), $noreg, !9, !DIExpression(), debug-location !DILocation(line: 5, column: 1, scope: !6) + +By default, ``mir-debugify`` inserts ``DBG_VALUE`` instructions **everywhere** +it is legal to do so. In particular, every (non-PHI) machine instruction that +defines a register must be followed by a ``DBG_VALUE`` use of that def. If +an instruction does not define a register, but can be followed by a debug inst, +MIRDebugify inserts a ``DBG_VALUE`` that references a constant. Insertion of +``DBG_VALUE``'s can be disabled by setting ``-debugify-level=locations``. + +To run MIRDebugify once, simply insert ``mir-debugify`` into your ``llc`` +invocation, like: + +.. code-block:: bash + + # Before some other pass. + $ llc -run-pass=mir-debugify,other-pass ... + + # After some other pass. + $ llc -run-pass=other-pass,mir-debugify ... + +To run MIRDebugify before each pass in a pipeline, use +``-debugify-and-strip-all-safe``. This can be combined with ``-start-before`` +and ``-start-after``. For example: + +.. code-block:: bash + + $ llc -debugify-and-strip-all-safe -run-pass=... + $ llc -debugify-and-strip-all-safe -O1 + +To strip out all debug info from a test, use ``mir-strip-debug``, like: + +.. code-block:: bash + + $ llc -run-pass=mir-debugify,other-pass,mir-strip-debug + +It can be useful to combine ``mir-debugify`` and ``mir-strip-debug`` to +identify backend transformations which break in the presence of debug info. +For example, to run the AArch64 backend tests with all normal passes +"sandwiched" in between MIRDebugify and MIRStripDebugify mutation passes, run: + +.. code-block:: bash + + $ llvm-lit test/CodeGen/AArch64 -Dllc="llc -debugify-and-strip-all-safe" + +Using LostDebugLocObserver +-------------------------- + +TODO diff --git a/gnu/llvm/llvm/docs/HowToUseAttributes.rst b/gnu/llvm/llvm/docs/HowToUseAttributes.rst index 1d05e238587..cc8a00ec545 100644 --- a/gnu/llvm/llvm/docs/HowToUseAttributes.rst +++ b/gnu/llvm/llvm/docs/HowToUseAttributes.rst @@ -57,7 +57,7 @@ An ``AttributeList`` object is designed to be passed around by value. Note: It is advised that you do *not* use the ``AttributeList`` "introspection" methods (e.g. ``Raw``, ``getRawPointer``, etc.). These methods break -encapsulation, and may be removed in a future release (i.e. LLVM 4.0). +encapsulation, and may be removed in a future release. ``AttrBuilder`` =============== @@ -73,7 +73,7 @@ should be passed by reference. Note: It is advised that you do *not* use the ``AttrBuilder::addRawValue()`` method or the ``AttrBuilder(uint64_t Val)`` constructor. These are for -backwards compatibility and may be removed in a future release (i.e. LLVM 4.0). +backwards compatibility and may be removed in a future release. And that's basically it! A lot of functionality is hidden behind these classes, but the interfaces are pretty straight forward. diff --git a/gnu/llvm/llvm/docs/HowToUseInstrMappings.rst b/gnu/llvm/llvm/docs/HowToUseInstrMappings.rst index 1c586b4bada..ac03f31b77d 100644 --- a/gnu/llvm/llvm/docs/HowToUseInstrMappings.rst +++ b/gnu/llvm/llvm/docs/HowToUseInstrMappings.rst @@ -28,7 +28,7 @@ describe all the instructions using that model. TableGen parses all the relation models and uses the information to construct relation tables which relate instructions with each other. These tables are emitted in the ``XXXInstrInfo.inc`` file along with the functions to query them. Following -is the definition of ``InstrMapping`` class definied in Target.td file: +is the definition of ``InstrMapping`` class defined in Target.td file: .. code-block:: text diff --git a/gnu/llvm/llvm/docs/LLVMBuild.txt b/gnu/llvm/llvm/docs/LLVMBuild.txt index 00d82f664c1..74422db0494 100644 --- a/gnu/llvm/llvm/docs/LLVMBuild.txt +++ b/gnu/llvm/llvm/docs/LLVMBuild.txt @@ -10,7 +10,7 @@ ; ; For more information on the LLVMBuild system, please see: ; -; http://llvm.org/docs/LLVMBuild.html +; https://llvm.org/docs/LLVMBuild.html ; ;===------------------------------------------------------------------------===; diff --git a/gnu/llvm/llvm/docs/LangRef.rst b/gnu/llvm/llvm/docs/LangRef.rst index 190c282eacc..9b58b9dfb17 100644 --- a/gnu/llvm/llvm/docs/LangRef.rst +++ b/gnu/llvm/llvm/docs/LangRef.rst @@ -272,8 +272,8 @@ linkage: visible, meaning that it participates in linkage and can be used to resolve external symbol references. -It is illegal for a function *declaration* to have any linkage type -other than ``external`` or ``extern_weak``. +It is illegal for a global variable or function *declaration* to have any +linkage type other than ``external`` or ``extern_weak``. .. _callingconv: @@ -615,6 +615,8 @@ Global variable definitions must be initialized. Global variables in other translation units can also be declared, in which case they don't have an initializer. +Global variables can optionally specify a :ref:`linkage type `. + Either global variable definitions or declarations may have an explicit section to be placed in and may have an optional explicit alignment specified. If there is a mismatch between the explicit or inferred section information for the @@ -686,6 +688,13 @@ assume that the globals are densely packed in their section and try to iterate over them as an array, alignment padding would break this iteration. The maximum alignment is ``1 << 29``. +For global variables declarations, as well as definitions that may be +replaced at link time (``linkonce``, ``weak``, ``extern_weak`` and ``common`` +linkage types), LLVM makes no assumptions about the allocation size of the +variables, except that they may not overlap. The alignment of a global variable +declaration or replaceable definition must not be greater than the alignment of +the definition it resolves to. + Globals can also have a :ref:`DLL storage class `, an optional :ref:`runtime preemption specifier `, an optional :ref:`global attributes ` and @@ -910,8 +919,8 @@ The selection kind must be one of the following: The linker may choose any COMDAT key but the sections must contain the same amount of data. -Note that the Mach-O platform doesn't support COMDATs, and ELF and WebAssembly -only support ``any`` as a selection kind. +Note that XCOFF and the Mach-O platform don't support COMDATs, and ELF and +WebAssembly only support ``any`` as a selection kind. Here is an example of a COMDAT group where a function will only be selected if the COMDAT key's section is the largest: @@ -1057,6 +1066,31 @@ Currently, only the following parameter attributes are defined: site. If the alignment is not specified, then the code generator makes a target-specific assumption. +.. _attr_preallocated: + +``preallocated()`` + This indicates that the pointer parameter should really be passed by + value to the function, and that the pointer parameter's pointee has + already been initialized before the call instruction. This attribute + is only valid on LLVM pointer arguments. The argument must be the value + returned by the appropriate + :ref:`llvm.call.preallocated.arg` on non + ``musttail`` calls, or the corresponding caller parameter in ``musttail`` + calls, although it is ignored during codegen. + + A non ``musttail`` function call with a ``preallocated`` attribute in + any parameter must have a ``"preallocated"`` operand bundle. A ``musttail`` + function call cannot have a ``"preallocated"`` operand bundle. + + The preallocated attribute requires a type argument, which must be + the same as the pointee type of the argument. + + The preallocated attribute also supports specifying an alignment with the + align attribute. It indicates the alignment of the stack slot to + form and the known alignment of the pointer specified to the call + site. If the alignment is not specified, then the code generator + makes a target-specific assumption. + .. _attr_inalloca: ``inalloca`` @@ -1096,7 +1130,7 @@ Currently, only the following parameter attributes are defined: .. _attr_align: -``align `` +``align `` or ``align()`` This indicates that the pointer value may be assumed by the optimizer to have the specified alignment. If the pointer value does not have the specified alignment, behavior is undefined. @@ -1107,14 +1141,16 @@ Currently, only the following parameter attributes are defined: .. _noalias: ``noalias`` - This indicates that objects accessed via pointer values + This indicates that memory locations accessed via pointer values :ref:`based ` on the argument or return value are not also accessed, during the execution of the function, via pointer values not - *based* on the argument or return value. The attribute on a return value - also has additional semantics described below. The caller shares the - responsibility with the callee for ensuring that these requirements are met. - For further details, please see the discussion of the NoAlias response in - :ref:`alias analysis `. + *based* on the argument or return value. This guarantee only holds for + memory locations that are *modified*, by any means, during the execution of + the function. The attribute on a return value also has additional semantics + described below. The caller shares the responsibility with the callee for + ensuring that these requirements are met. For further details, please see + the discussion of the NoAlias response in :ref:`alias analysis `. Note that this definition of ``noalias`` is intentionally similar to the definition of ``restrict`` in C99 for function arguments. @@ -1216,6 +1252,12 @@ Currently, only the following parameter attributes are defined: only valid on intrinsic declarations and cannot be applied to a call site or arbitrary function. +``noundef`` + This attribute applies to parameters and return values. If the value + representation contains any undefined or poison bits, the behavior is + undefined. Note that this does not refer to padding introduced by the + type's storage representation. + .. _gc: Garbage Collector Strategy Names @@ -1497,6 +1539,14 @@ example: This attribute indicates that the inliner should never inline this function in any situation. This attribute may not be used together with the ``alwaysinline`` attribute. +``nomerge`` + This attribute indicates that calls to this function should never be merged + during optimization. For example, it will prevent tail merging otherwise + identical code sequences that raise an exception or terminate the program. + Tail merging normally reduces the precision of source location information, + making stack traces less useful for debugging. This attribute gives the + user control over the tradeoff between code size and debug information + precision. ``nonlazybind`` This attribute suppresses lazy symbol binding for the function. This may make calls to the function faster, at the cost of extra program @@ -1541,8 +1591,8 @@ example: trap or generate asynchronous exceptions. Exception handling schemes that are recognized by LLVM to handle asynchronous exceptions, such as SEH, will still provide their implementation defined semantics. -``"null-pointer-is-valid"`` - If ``"null-pointer-is-valid"`` is set to ``"true"``, then ``null`` address +``null_pointer_is_valid`` + If ``null_pointer_is_valid`` is set, then the ``null`` address in address-space 0 is considered to be a valid address for memory loads and stores. Any analysis or optimization should not treat dereferencing a pointer to ``null`` as undefined behavior in this function. @@ -1692,7 +1742,7 @@ example: functions. ``safestack`` This attribute indicates that - `SafeStack `_ + `SafeStack `_ protection is enabled for this function. If a function that has a ``safestack`` attribute is inlined into a @@ -1818,6 +1868,45 @@ example: mode or that might alter the state of floating-point status flags that might otherwise be set or cleared by calling this function. LLVM will not introduce any new floating-point instructions that may trap. + +``"denormal-fp-math"`` + This indicates the denormal (subnormal) handling that may be + assumed for the default floating-point environment. This is a + comma separated pair. The elements may be one of ``"ieee"``, + ``"preserve-sign"``, or ``"positive-zero"``. The first entry + indicates the flushing mode for the result of floating point + operations. The second indicates the handling of denormal inputs + to floating point instructions. For compatibility with older + bitcode, if the second value is omitted, both input and output + modes will assume the same mode. + + If this is attribute is not specified, the default is + ``"ieee,ieee"``. + + If the output mode is ``"preserve-sign"``, or ``"positive-zero"``, + denormal outputs may be flushed to zero by standard floating-point + operations. It is not mandated that flushing to zero occurs, but if + a denormal output is flushed to zero, it must respect the sign + mode. Not all targets support all modes. While this indicates the + expected floating point mode the function will be executed with, + this does not make any attempt to ensure the mode is + consistent. User or platform code is expected to set the floating + point mode appropriately before function entry. + + If the input mode is ``"preserve-sign"``, or ``"positive-zero"``, a + floating-point operation must treat any input denormal value as + zero. In some situations, if an instruction does not respect this + mode, the input may need to be converted to 0 as if by + ``@llvm.canonicalize`` during lowering for correctness. + +``"denormal-fp-math-f32"`` + Same as ``"denormal-fp-math"``, but only controls the behavior of + the 32-bit float type (or vectors of 32-bit floats). If both are + are present, this overrides ``"denormal-fp-math"``. Not all targets + support separately setting the denormal mode per type, and no + attempt is made to diagnose unsupported uses. Currently this + attribute is respected by the AMDGPU and NVPTX backends. + ``"thunk"`` This attribute indicates that the function will delegate to some other function with a tail call. The prototype of a thunk should not be used for @@ -1838,9 +1927,86 @@ example: ``shadowcallstack`` This attribute indicates that the ShadowCallStack checks are enabled for the function. The instrumentation checks that the return address for the - function has not changed between the function prolog and eiplog. It is + function has not changed between the function prolog and epilog. It is currently x86_64-specific. +Call Site Attributes +---------------------- + +In addition to function attributes the following call site only +attributes are supported: + +``vector-function-abi-variant`` + This attribute can be attached to a :ref:`call ` to list + the vector functions associated to the function. Notice that the + attribute cannot be attached to a :ref:`invoke ` or a + :ref:`callbr ` instruction. The attribute consists of a + comma separated list of mangled names. The order of the list does + not imply preference (it is logically a set). The compiler is free + to pick any listed vector function of its choosing. + + The syntax for the mangled names is as follows::: + + _ZGV_[()] + + When present, the attribute informs the compiler that the function + ```` has a corresponding vector variant that can be + used to perform the concurrent invocation of ```` on + vectors. The shape of the vector function is described by the + tokens between the prefix ``_ZGV`` and the ```` + token. The standard name of the vector function is + ``_ZGV_``. When present, + the optional token ``()`` informs the compiler + that a custom name is provided in addition to the standard one + (custom names can be provided for example via the use of ``declare + variant`` in OpenMP 5.0). The declaration of the variant must be + present in the IR Module. The signature of the vector variant is + determined by the rules of the Vector Function ABI (VFABI) + specifications of the target. For Arm and X86, the VFABI can be + found at https://github.com/ARM-software/abi-aa and + https://software.intel.com/en-us/articles/vector-simd-function-abi, + respectively. + + For X86 and Arm targets, the values of the tokens in the standard + name are those that are defined in the VFABI. LLVM has an internal + ```` token that can be used to create scalar-to-vector + mappings for functions that are not directly associated to any of + the target ISAs (for example, some of the mappings stored in the + TargetLibraryInfo). Valid values for the ```` token are::: + + := b | c | d | e -> X86 SSE, AVX, AVX2, AVX512 + | n | s -> Armv8 Advanced SIMD, SVE + | __LLVM__ -> Internal LLVM Vector ISA + + For all targets currently supported (x86, Arm and Internal LLVM), + the remaining tokens can have the following values::: + + := M | N -> mask | no mask + + := number -> number of lanes + | x -> VLA (Vector Length Agnostic) + + := v -> vector + | l | l -> linear + | R | R -> linear with ref modifier + | L | L -> linear with val modifier + | U | U -> linear with uval modifier + | ls -> runtime linear + | Rs -> runtime linear with ref modifier + | Ls -> runtime linear with val modifier + | Us -> runtime linear with uval modifier + | u -> uniform + + := name of the scalar function + + := optional, custom name of the vector function + +``preallocated()`` + This attribute is required on calls to ``llvm.call.preallocated.arg`` + and cannot be used on any other call. See + :ref:`llvm.call.preallocated.arg` for more + details. + .. _glattrs: Global Attributes @@ -1992,6 +2158,107 @@ site, these bundles may contain any values that are needed by the generated code. For more details, see :ref:`GC Transitions `. +.. _assume_opbundles: + +Assume Operand Bundles +^^^^^^^^^^^^^^^^^^^^^^ + +Operand bundles on an :ref:`llvm.assume ` allows representing +assumptions that a :ref:`parameter attribute ` or a +:ref:`function attribute ` holds for a certain value at a certain +location. Operand bundles enable assumptions that are either hard or impossible +to represent as a boolean argument of an :ref:`llvm.assume `. + +An assume operand bundle has the form: + +:: + + ""([ [, ] ]) + +* The tag of the operand bundle is usually the name of attribute that can be + assumed to hold. It can also be `ignore`, this tag doesn't contain any + information and should be ignored. +* The first argument if present is the value for which the attribute hold. +* The second argument if present is an argument of the attribute. + +If there are no arguments the attribute is a property of the call location. + +If the represented attribute expects a constant argument, the argument provided +to the operand bundle should be a constant as well. + +For example: + +.. code-block:: llvm + + call void @llvm.assume(i1 true) ["align"(i32* %val, i32 8)] + +allows the optimizer to assume that at location of call to +:ref:`llvm.assume ` ``%val`` has an alignment of at least 8. + +.. code-block:: llvm + + call void @llvm.assume(i1 %cond) ["cold"(), "nonnull"(i64* %val)] + +allows the optimizer to assume that the :ref:`llvm.assume ` +call location is cold and that ``%val`` may not be null. + +Just like for the argument of :ref:`llvm.assume `, if any of the +provided guarantees are are violated at runtime the behavior is undefined. + +Even if the assumed property can be encoded as a boolean value, like +``nonnull``, using operand bundles to express the property can still have +benefits: + +* Attributes that can be expressed via operand bundles are directly the + property that the optimizer uses and cares about. Encoding attributes as + operand bundles removes the need for an instruction sequence that represents + the property (e.g., `icmp ne i32* %p, null` for `nonnull`) and for the + optimizer to deduce the property from that instruction sequence. +* Expressing the property using operand bundles makes it easy to identify the + use of the value as a use in an :ref:`llvm.assume `. This then + simplifies and improves heuristics, e.g., for use "use-sensitive" + optimizations. + +.. _ob_preallocated: + +Preallocated Operand Bundles +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Preallocated operand bundles are characterized by the ``"preallocated"`` +operand bundle tag. These operand bundles allow separation of the allocation +of the call argument memory from the call site. This is necessary to pass +non-trivially copyable objects by value in a way that is compatible with MSVC +on some targets. There can be at most one ``"preallocated"`` operand bundle +attached to a call site and it must have exactly one bundle operand, which is +a token generated by ``@llvm.call.preallocated.setup``. A call with this +operand bundle should not adjust the stack before entering the function, as +that will have been done by one of the ``@llvm.call.preallocated.*`` intrinsics. + +.. code-block:: llvm + + %foo = type { i64, i32 } + + ... + + %t = call token @llvm.call.preallocated.setup(i32 1) + %a = call i8* @llvm.call.preallocated.arg(token %t, i32 0) preallocated(%foo) + %b = bitcast i8* %a to %foo* + ; initialize %b + call void @bar(i32 42, %foo* preallocated(%foo) %b) ["preallocated"(token %t)] + +.. _ob_gc_live: + +GC Live Operand Bundles +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A "gc-live" operand bundle is only valid on a :ref:`gc.statepoint ` +intrinsic. The operand bundle must contain every pointer to a garbage collected +object which potentially needs to be updated by the garbage collector. + +When lowered, any relocated value will be recorded in the corresponding +:ref:`stackmap entry `. See the intrinsic description +for further details. + .. _moduleasm: Module-Level Inline Assembly @@ -2105,6 +2372,7 @@ as follows: starting with ``?`` are not mangled in any way. * ``w``: Windows COFF mangling: Similar to ``x``, except that normal C symbols do not receive a ``_`` prefix. + * ``a``: XCOFF mangling: Private symbols get a ``L..`` prefix. ``n::...`` This specifies a set of native integer widths for the target CPU in bits. For example, it might contain ``n32`` for 32-bit PowerPC, @@ -2286,10 +2554,11 @@ The compiler may assume execution will continue after a volatile operation, so operations which modify memory or may have undefined behavior can be hoisted past a volatile operation. -IR-level volatile loads and stores cannot safely be optimized into -llvm.memcpy or llvm.memmove intrinsics even when those intrinsics are -flagged volatile. Likewise, the backend should never split or merge -target-legal volatile load/store instructions. +IR-level volatile loads and stores cannot safely be optimized into llvm.memcpy +or llvm.memmove intrinsics even when those intrinsics are flagged volatile. +Likewise, the backend should never split or merge target-legal volatile +load/store instructions. Similarly, IR-level volatile loads and stores cannot +change from integer to floating-point or vice versa. .. admonition:: Rationale @@ -2500,7 +2769,8 @@ floating-point transformations. ``nsz`` No Signed Zeros - Allow optimizations to treat the sign of a zero - argument or result as insignificant. + argument or result as insignificant. This does not imply that -0.0 + is poison and/or guaranteed to not exist in the operation. ``arcp`` Allow Reciprocal - Allow optimizations to use the reciprocal of an @@ -2508,7 +2778,9 @@ floating-point transformations. ``contract`` Allow floating-point contraction (e.g. fusing a multiply followed by an - addition into a fused multiply-and-add). + addition into a fused multiply-and-add). This does not enable reassociating + to form arbitrary contractions. For example, ``(a*b) + (c*d) + e`` can not + be transformed into ``(a*b) + ((c*d) + e)`` to create two fma operations. ``afn`` Approximate functions - Allow substitution of approximate calculations for @@ -2718,6 +2990,12 @@ Floating-Point Types * - ``half`` - 16-bit floating-point value + * - ``bfloat`` + - 16-bit "brain" floating-point value (7-bit significand). Provides the + same number of exponent bits as ``float``, so that it matches its dynamic + range, but with greatly reduced precision. Used in Intel's AVX-512 BF16 + extensions and Arm's ARMv8.6-A extensions, among others. + * - ``float`` - 32-bit floating-point value @@ -2725,7 +3003,7 @@ Floating-Point Types - 64-bit floating-point value * - ``fp128`` - - 128-bit floating-point value (112-bit mantissa) + - 128-bit floating-point value (112-bit significand) * - ``x86_fp80`` - 80-bit floating-point value (X87) @@ -3058,20 +3336,20 @@ number of digits. For example, NaN's, infinities, and other special values are represented in their IEEE hexadecimal format so that assembly and disassembly do not cause any bits to change in the constants. -When using the hexadecimal form, constants of types half, float, and -double are represented using the 16-digit form shown above (which -matches the IEEE754 representation for double); half and float values -must, however, be exactly representable as IEEE 754 half and single -precision, respectively. Hexadecimal format is always used for long -double, and there are three forms of long double. The 80-bit format used -by x86 is represented as ``0xK`` followed by 20 hexadecimal digits. The -128-bit format used by PowerPC (two adjacent doubles) is represented by -``0xM`` followed by 32 hexadecimal digits. The IEEE 128-bit format is -represented by ``0xL`` followed by 32 hexadecimal digits. Long doubles -will only work if they match the long double format on your target. -The IEEE 16-bit format (half precision) is represented by ``0xH`` -followed by 4 hexadecimal digits. All hexadecimal formats are big-endian -(sign bit at the left). +When using the hexadecimal form, constants of types bfloat, half, float, and +double are represented using the 16-digit form shown above (which matches the +IEEE754 representation for double); bfloat, half and float values must, however, +be exactly representable as bfloat, IEEE 754 half, and IEEE 754 single +precision respectively. Hexadecimal format is always used for long double, and +there are three forms of long double. The 80-bit format used by x86 is +represented as ``0xK`` followed by 20 hexadecimal digits. The 128-bit format +used by PowerPC (two adjacent doubles) is represented by ``0xM`` followed by 32 +hexadecimal digits. The IEEE 128-bit format is represented by ``0xL`` followed +by 32 hexadecimal digits. Long doubles will only work if they match the long +double format on your target. The IEEE 16-bit format (half precision) is +represented by ``0xH`` followed by 4 hexadecimal digits. The bfloat 16-bit +format is represented by ``0xR`` followed by 4 hexadecimal digits. All +hexadecimal formats are big-endian (sign bit at the left). There are no constants of type x86_mmx. @@ -3244,6 +3522,7 @@ uses with" concept would not hold. To ensure all uses of a given register observe the same value (even if '``undef``'), the :ref:`freeze instruction ` can be used. +A value is frozen if its uses see the same value. .. code-block:: llvm @@ -3280,7 +3559,34 @@ match what was already there. However, a store *to* an undefined location could clobber arbitrary memory, therefore, it has undefined behavior. -**MemorySanitizer**, a detector of uses of uninitialized memory, +Branching on an undefined value is undefined behavior. +This explains optimizations that depend on branch conditions to construct +predicates, such as Correlated Value Propagation and Global Value Numbering. +In case of switch instruction, the branch condition should be frozen, otherwise +it is undefined behavior. + +.. code-block:: text + + Unsafe: + br undef, BB1, BB2 ; UB + + %X = and i32 undef, 255 + switch %X, label %ret [ .. ] ; UB + + store undef, i8* %ptr + %X = load i8* %ptr ; %X is undef + switch i8 %X, label %ret [ .. ] ; UB + + Safe: + %X = or i8 undef, 255 ; always 255 + switch i8 %X, label %ret [ .. ] ; Well-defined + + %X = freeze i1 undef + br %X, BB1, BB2 ; Well-defined (non-deterministic jump) + + +This is also consistent with the behavior of MemorySanitizer. +MemorySanitizer, detector of uses of uninitialized memory, defines a branch with condition that depends on an undef value (or certain other values, like e.g. a result of a load from heap-allocated memory that has never been stored to) to have an externally visible @@ -3306,9 +3612,12 @@ the ``nsw`` flag. Poison value behavior is defined in terms of value *dependence*: -- Values other than :ref:`phi ` nodes depend on their operands. +- Values other than :ref:`phi ` nodes and :ref:`select ` + instructions depend on their operands. - :ref:`Phi ` nodes depend on the operand corresponding to their dynamic predecessor basic block. +- Select instructions depend on their condition operand and their + selected operand. - Function arguments depend on the corresponding actual argument values in the dynamic callers of their functions. - :ref:`Call ` instructions depend on the :ref:`ret ` @@ -3356,6 +3665,11 @@ behavior. Notably this includes (but is not limited to): - The condition operand of a :ref:`br ` instruction. - The callee operand of a :ref:`call ` or :ref:`invoke ` instruction. +- The parameter operand of a :ref:`call ` or :ref:`invoke ` + instruction, when the function or invoking call site has a ``noundef`` + attribute in the corresponding position. +- The operand of a :ref:`ret ` instruction if the function or invoking + call site has a `noundef` attribute in the return value position. Here are some examples: @@ -3845,7 +4159,14 @@ AMDGPU: - ``r``: A 32 or 64-bit integer register. - ``[0-9]v``: The 32-bit VGPR register, number 0-9. - ``[0-9]s``: The 32-bit SGPR register, number 0-9. - +- ``[0-9]a``: The 32-bit AGPR register, number 0-9. +- ``I``: An integer inline constant in the range from -16 to 64. +- ``J``: A 16-bit signed integer constant. +- ``A``: An integer or a floating-point inline constant. +- ``B``: A 32-bit signed integer constant. +- ``C``: A 32-bit unsigned integer constant or an integer inline constant in the range from -16 to 64. +- ``DA``: A 64-bit constant that can be split into two "A" constants. +- ``DB``: A 64-bit constant that can be split into two "B" constants. All ARM modes: @@ -4318,7 +4639,7 @@ to the ``add`` instruction using the ``!dbg`` identifier: %indvar.next = add i64 %indvar, 1, !dbg !21 Metadata can also be attached to a function or a global variable. Here metadata -``!22`` is attached to the ``f1`` and ``f2 functions, and the globals ``g1`` +``!22`` is attached to the ``f1`` and ``f2`` functions, and the globals ``g1`` and ``g2`` using the ``!dbg`` identifier: .. code-block:: llvm @@ -4396,7 +4717,7 @@ DIFile Files are sometimes used in ``scope:`` fields, and are the only valid target for ``file:`` fields. -Valid values for ``checksumkind:`` field are: {CSK_None, CSK_MD5, CSK_SHA1} +Valid values for ``checksumkind:`` field are: {CSK_None, CSK_MD5, CSK_SHA1, CSK_SHA256} .. _DIBasicType: @@ -4533,7 +4854,12 @@ The following ``tag:`` values are valid: For ``DW_TAG_array_type``, the ``elements:`` should be :ref:`subrange descriptors `, each representing the range of subscripts at that level of indexing. The ``DIFlagVector`` flag to ``flags:`` indicates that an -array type is a native packed vector. +array type is a native packed vector. The optional ``dataLocation`` is a +DIExpression that describes how to get from an object's address to the actual +raw data, if they aren't equivalent. This is only supported for array types, +particularly to describe Fortran arrays, which have an array descriptor in +addition to the array data. Alternatively it can also be DIVariable which +has the address of the actual raw data. For ``DW_TAG_enumeration_type``, the ``elements:`` should be :ref:`enumerator descriptors `, each representing the definition of an enumeration @@ -4816,15 +5142,20 @@ The current supported opcode vocabulary is limited: ``DW_OP_LLVM_entry_value`` is only legal in MIR. The operation is introduced by the ``LiveDebugValues`` pass; currently only for function parameters that - are unmodified throughout a function and that are described as simple - register location descriptions. The operation is also introduced by the - ``AsmPrinter`` pass when a call site parameter value + are unmodified throughout a function. Support is limited to function + parameter that are described as simple register location descriptions, or as + indirect locations (e.g. when a struct is passed-by-value to a callee via a + pointer to a temporary copy made in the caller). The entry value op is also + introduced by the ``AsmPrinter`` pass when a call site parameter value (``DW_AT_call_site_parameter_value``) is represented as entry value of the parameter. - ``DW_OP_breg`` (or ``DW_OP_bregx``) represents a content on the provided signed offset of the specified register. The opcode is only generated by the ``AsmPrinter`` pass to describe call site parameter value which requires an expression over two registers. +- ``DW_OP_push_object_address`` pushes the address of the object which can then + serve as a descriptor in subsequent calculation. This opcode can be used to + calculate bounds of fortran allocatable array which has array descriptors. DWARF specifies three kinds of simple location descriptions: Register, memory, and implicit location descriptions. Note that a location description is @@ -4842,9 +5173,9 @@ refines this address to produce a concrete location for the source variable. A ``llvm.dbg.value`` intrinsic describes the direct value of a source variable. The first operand of the intrinsic may be a direct or indirect value. A -DIExpresion attached to the intrinsic refines the first operand to produce a +DIExpression attached to the intrinsic refines the first operand to produce a direct value. For example, if the first operand is an indirect value, it may be -necessary to insert ``DW_OP_deref`` into the DIExpresion in order to produce a +necessary to insert ``DW_OP_deref`` into the DIExpression in order to produce a valid debug intrinsic. .. note:: @@ -5387,33 +5718,34 @@ attribute on parameters and return values. It is sometimes useful to attach information to loop constructs. Currently, loop metadata is implemented as metadata attached to the branch instruction -in the loop latch block. This type of metadata refer to a metadata node that is -guaranteed to be separate for each loop. The loop identifier metadata is -specified with the name ``llvm.loop``. - -The loop identifier metadata is implemented using a metadata that refers to -itself to avoid merging it with any other identifier metadata, e.g., -during module linkage or function inlining. That is, each loop should refer -to their own identification metadata even if they reside in separate functions. -The following example contains loop identifier metadata for two separate loop -constructs: +in the loop latch block. The loop metadata node is a list of +other metadata nodes, each representing a property of the loop. Usually, +the first item of the property node is a string. For example, the +``llvm.loop.unroll.count`` suggests an unroll factor to the loop +unroller: .. code-block:: llvm - !0 = !{!0} - !1 = !{!1} + br i1 %exitcond, label %._crit_edge, label %.lr.ph, !llvm.loop !0 + ... + !0 = !{!0, !1, !2} + !1 = !{!"llvm.loop.unroll.enable"} + !2 = !{!"llvm.loop.unroll.count", i32 4} -The loop identifier metadata can be used to specify additional -per-loop metadata. Any operands after the first operand can be treated -as user-defined metadata. For example the ``llvm.loop.unroll.count`` -suggests an unroll factor to the loop unroller: +For legacy reasons, the first item of a loop metadata node must be a +reference to itself. Before the advent of the 'distinct' keyword, this +forced the preservation of otherwise identical metadata nodes. Since +the loop-metadata node can be attached to multiple nodes, the 'distinct' +keyword has become unnecessary. -.. code-block:: llvm +Prior to the property nodes, one or two ``DILocation`` (debug location) +nodes can be present in the list. The first, if present, identifies the +source-code location where the loop begins. The second, if present, +identifies the source-code location where the loop ends. - br i1 %exitcond, label %._crit_edge, label %.lr.ph, !llvm.loop !0 - ... - !0 = !{!0, !1} - !1 = !{!"llvm.loop.unroll.count", i32 4} +Loop metadata nodes cannot be used as unique identifiers. They are +neither persistent for the same loop through transformations nor +necessarily unique to just one loop. '``llvm.loop.disable_nonforced``' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -6327,7 +6659,7 @@ The list is encoded in the IR using named metadata with the name ``!llvm.dependent-libraries``. Each operand is expected to be a metadata node which should contain a single string operand. -For example, the following metadata section contains two library specfiers:: +For example, the following metadata section contains two library specifiers:: !0 = !{!"a library specifier"} !1 = !{!"another library specifier"} @@ -6417,7 +6749,7 @@ If the global value is a function, the ``Summary`` entry will look like: .. code-block:: text - function: (module: ^0, flags: (linkage: external, notEligibleToImport: 0, live: 0, dsoLocal: 0), insts: 2[, FuncFlags]?[, Calls]?[, TypeIdInfo]?[, Refs]? + function: (module: ^0, flags: (linkage: external, notEligibleToImport: 0, live: 0, dsoLocal: 0), insts: 2[, FuncFlags]?[, Calls]?[, TypeIdInfo]?[, Params]?[, Refs]? The ``module`` field includes the summary entry id for the module containing this definition, and the ``flags`` field contains information such as @@ -6427,7 +6759,7 @@ to a local definition (the latter two are populated during the thin link). The ``insts`` field contains the number of IR instructions in the function. Finally, there are several optional fields: :ref:`FuncFlags`, :ref:`Calls`, :ref:`TypeIdInfo`, -:ref:`Refs`. +:ref:`Params`, :ref:`Refs`. .. _variable_summary: @@ -6495,6 +6827,77 @@ of ``hotness`` (which can take the values ``Unknown``, ``Cold``, ``None``, branch frequency relative to the entry frequency, scaled down by 2^8) may be specified. The defaults are ``Unknown`` and ``0``, respectively. +.. _params_summary: + +Params +^^^^^^ + +The optional ``Params`` is used by ``StackSafety`` and looks like: + +.. code-block:: text + + Params: ((Param)[, (Param)]*) + +where each ``Param`` describes pointer parameter access inside of the +function and looks like: + +.. code-block:: text + + param: 4, offset: [0, 5][, calls: ((Callee)[, (Callee)]*)]? + +where the first ``param`` is the number of the parameter it describes, +``offset`` is the inclusive range of offsets from the pointer parameter to bytes +which can be accessed by the function. This range does not include accesses by +function calls from ``calls`` list. + +where each ``Callee`` decribes how parameter is forwared into other +functions and looks like: + +.. code-block:: text + + callee: ^3, param: 5, offset: [-3, 3] + +The ``callee`` refers to the summary entry id of the callee, ``param`` is +the number of the callee parameter which points into the callers parameter +with offset known to be inside of the ``offset`` range. ``calls`` will be +consumed and removed by thin link stage to update ``Param::offset`` so it +covers all accesses possible by ``calls``. + +Pointer parameter without corresponding ``Param`` is considered unsafe and we +assume that access with any offset is possible. + +Example: + +If we have the following function: + +.. code-block:: text + + define i64 @foo(i64* %0, i32* %1, i8* %2, i8 %3) { + store i32* %1, i32** @x + %5 = getelementptr inbounds i8, i8* %2, i64 5 + %6 = load i8, i8* %5 + %7 = getelementptr inbounds i8, i8* %2, i8 %3 + tail call void @bar(i8 %3, i8* %7) + %8 = load i64, i64* %0 + ret i64 %8 + } + +We can expect the record like this: + +.. code-block:: text + + params: ((param: 0, offset: [0, 7]),(param: 2, offset: [5, 5], calls: ((callee: ^3, param: 1, offset: [-128, 127])))) + +The function may access just 8 bytes of the paramenter %0 . ``calls`` is empty, +so the parameter is either not used for function calls or ``offset`` already +covers all accesses from nested function calls. +Parameter %1 escapes, so access is unknown. +The function itself can access just a single byte of the parameter %2. Additional +access is possible inside of the ``@bar`` or ``^3``. The function adds signed +offset to the pointer and passes the result as the argument %1 into ``^3``. +This record itself does not tell us how ``^3`` will access the parameter. +Parameter %3 is not a pointer. + .. _refs_summary: Refs @@ -6515,7 +6918,7 @@ TypeIdInfo ^^^^^^^^^^ The optional ``TypeIdInfo`` field, used for -`Control Flow Integrity `_, +`Control Flow Integrity `_, looks like: .. code-block:: text @@ -6592,7 +6995,7 @@ Type ID Summary Entry Each type id summary entry corresponds to a type identifier resolution which is generated during the LTO link portion of the compile when building -with `Control Flow Integrity `_, +with `Control Flow Integrity `_, so these are only present in a combined summary index. Example: @@ -6682,7 +7085,7 @@ corresponds to "``attribute((used))``" in GNU C. On some targets, the code generator must emit a directive to the assembler or object file to prevent the assembler and linker from -molesting the symbol. +removing the symbol. .. _gv_llvmcompilerused: @@ -6860,7 +7263,8 @@ Upon execution of a conditional '``br``' instruction, the '``i1``' argument is evaluated. If the value is ``true``, control flows to the '``iftrue``' ``label`` argument. If "cond" is ``false``, control flows to the '``iffalse``' ``label`` argument. -If '``cond``' is ``poison``, this instruction has undefined behavior. +If '``cond``' is ``poison`` or ``undef``, this instruction has undefined +behavior. Example: """""""" @@ -6911,7 +7315,8 @@ When the '``switch``' instruction is executed, this table is searched for the given value. If the value is found, control flow is transferred to the corresponding destination; otherwise, control flow is transferred to the default destination. -If '``value``' is ``poison``, this instruction has undefined behavior. +If '``value``' is ``poison`` or ``undef``, this instruction has undefined +behavior. Implementation: """"""""""""""" @@ -6976,7 +7381,8 @@ Control transfers to the block specified in the address argument. All possible destination blocks must be listed in the label list, otherwise this instruction has undefined behavior. This implies that jumps to labels defined in other functions have undefined behavior as well. -If '``address``' is ``poison``, this instruction has undefined behavior. +If '``address``' is ``poison`` or ``undef``, this instruction has undefined +behavior. Implementation: """"""""""""""" @@ -7101,14 +7507,14 @@ Syntax: :: = callbr [cconv] [ret attrs] [addrspace()] | () [fn attrs] - [operand bundles] to label [other labels] + [operand bundles] to label [indirect labels] Overview: """"""""" The '``callbr``' instruction causes control to transfer to a specified function, with the possibility of control flow transfer to either the -'``normal``' label or one of the '``other``' labels. +'``fallthrough``' label or one of the '``indirect``' labels. This instruction should only be used to implement the "goto" feature of gcc style inline assembly. Any other usage is an error in the IR verifier. @@ -7135,17 +7541,17 @@ This instruction requires several arguments: type can be omitted if the function is not varargs. #. '``fnptrval``': An LLVM value containing a pointer to a function to be called. In most cases, this is a direct function call, but - indirect ``callbr``'s are just as possible, calling an arbitrary pointer + other ``callbr``'s are just as possible, calling an arbitrary pointer to function value. #. '``function args``': argument list whose types match the function signature argument types and parameter attributes. All arguments must be of :ref:`first class ` type. If the function signature indicates the function accepts a variable number of arguments, the extra arguments can be specified. -#. '``normal label``': the label reached when the called function - executes a '``ret``' instruction. -#. '``other labels``': the labels reached when a callee transfers control - to a location other than the normal '``normal label``'. The blockaddress +#. '``fallthrough label``': the label reached when the inline assembly's + execution exits the bottom. +#. '``indirect labels``': the labels reached when a callee transfers control + to a location other than the '``fallthrough label``'. The blockaddress constant for these should also be in the list of '``function args``'. #. The optional :ref:`function attributes ` list. #. The optional :ref:`operand bundles ` list. @@ -7158,6 +7564,9 @@ instruction in most regards. The primary difference is that it establishes an association with additional labels to define where control flow goes after the call. +The output values of a '``callbr``' instruction are available only to +the '``fallthrough``' block, not to any '``indirect``' blocks(s). + The only use of this today is to implement the "goto" feature of gcc inline assembly where additional labels can be provided as locations for the inline assembly to jump to. @@ -7165,10 +7574,15 @@ assembly to jump to. Example: """""""" -.. code-block:: text +.. code-block:: llvm - callbr void asm "", "r,x"(i32 %x, i8 *blockaddress(@foo, %fail)) - to label %normal [label %fail] + ; "asm goto" without output constraints. + callbr void asm "", "r,X"(i32 %x, i8 *blockaddress(@foo, %indirect)) + to label %fallthrough [label %indirect] + + ; "asm goto" with output constraints. + = callbr i32 asm "", "=r,r,X"(i32 %x, i8 *blockaddress(@foo, %indirect)) + to label %fallthrough [label %indirect] .. _i_resume: @@ -7543,6 +7957,8 @@ Example: = fadd float 4.0, %var ; yields float:result = 4.0 + %var +.. _i_sub: + '``sub``' Instruction ^^^^^^^^^^^^^^^^^^^^^ @@ -7638,6 +8054,8 @@ Example: = fsub float 4.0, %var ; yields float:result = 4.0 - %var = fsub float -0.0, %val ; yields float:result = -%var +.. _i_mul: + '``mul``' Instruction ^^^^^^^^^^^^^^^^^^^^^ @@ -7732,6 +8150,8 @@ Example: = fmul float 4.0, %var ; yields float:result = 4.0 * %var +.. _i_udiv: + '``udiv``' Instruction ^^^^^^^^^^^^^^^^^^^^^^ @@ -7778,6 +8198,8 @@ Example: = udiv i32 4, %var ; yields i32:result = 4 / %var +.. _i_sdiv: + '``sdiv``' Instruction ^^^^^^^^^^^^^^^^^^^^^^ @@ -7866,6 +8288,8 @@ Example: = fdiv float 4.0, %var ; yields float:result = 4.0 / %var +.. _i_urem: + '``urem``' Instruction ^^^^^^^^^^^^^^^^^^^^^^ @@ -7910,6 +8334,8 @@ Example: = urem i32 4, %var ; yields i32:result = 4 % %var +.. _i_srem: + '``srem``' Instruction ^^^^^^^^^^^^^^^^^^^^^^ @@ -8023,6 +8449,8 @@ commonly be strength reduced from other instructions. They require two operands of the same type, execute an operation on them, and produce a single value. The resulting value is the same type as its operands. +.. _i_shl: + '``shl``' Instruction ^^^^^^^^^^^^^^^^^^^^^ @@ -8075,6 +8503,9 @@ Example: = shl i32 1, 32 ; undefined = shl <2 x i32> < i32 1, i32 1>, < i32 1, i32 2> ; yields: result=<2 x i32> < i32 2, i32 4> +.. _i_lshr: + + '``lshr``' Instruction ^^^^^^^^^^^^^^^^^^^^^^ @@ -8124,6 +8555,8 @@ Example: = lshr i32 1, 32 ; undefined = lshr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 2> ; yields: result=<2 x i32> < i32 0x7FFFFFFF, i32 1> +.. _i_ashr: + '``ashr``' Instruction ^^^^^^^^^^^^^^^^^^^^^^ @@ -8174,6 +8607,8 @@ Example: = ashr i32 1, 32 ; undefined = ashr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 3> ; yields: result=<2 x i32> < i32 -1, i32 0> +.. _i_and: + '``and``' Instruction ^^^^^^^^^^^^^^^^^^^^^ @@ -8223,6 +8658,8 @@ Example: = and i32 15, 40 ; yields i32:result = 8 = and i32 4, 8 ; yields i32:result = 0 +.. _i_or: + '``or``' Instruction ^^^^^^^^^^^^^^^^^^^^ @@ -8272,6 +8709,8 @@ Example: = or i32 15, 40 ; yields i32:result = 47 = or i32 4, 8 ; yields i32:result = 12 +.. _i_xor: + '``xor``' Instruction ^^^^^^^^^^^^^^^^^^^^^ @@ -8446,27 +8885,27 @@ Arguments: """""""""" The first two operands of a '``shufflevector``' instruction are vectors -with the same type. The third argument is a shuffle mask whose element -type is always 'i32'. The result of the instruction is a vector whose -length is the same as the shuffle mask and whose element type is the +with the same type. The third argument is a shuffle mask vector constant +whose element type is ``i32``. The mask vector elements must be constant +integers or ``undef`` values. The result of the instruction is a vector +whose length is the same as the shuffle mask and whose element type is the same as the element type of the first two operands. -The shuffle mask operand is required to be a constant vector with either -constant integer or undef values. - Semantics: """""""""" The elements of the two input vectors are numbered from left to right -across both of the vectors. The shuffle mask operand specifies, for each -element of the result vector, which element of the two input vectors the -result element gets. - -If the shuffle mask is undef, the result vector is undef. If any element -of the mask operand is undef, that element of the result is undef. If the -shuffle mask selects an undef element from one of the input vectors, the -resulting element is undef. An undef mask element prevents a poisoned -vector element from propagating. +across both of the vectors. For each element of the result vector, the +shuffle mask selects an element from one of the input vectors to copy +to the result. Non-negative elements in the mask represent an index +into the concatenated pair of input vectors. + +If the shuffle mask is undefined, the result vector is undefined. If +the shuffle mask selects an undefined element from one of the input +vectors, the resulting element is undefined. An undefined element +in the mask vector specifies that the resulting element is undefined. +An undefined element in the mask vector prevents a poisoned vector +element from propagating. For scalable vectors, the only valid mask values at present are ``zeroinitializer`` and ``undef``, since we cannot write all indices as @@ -10305,8 +10744,8 @@ This instruction requires several arguments: #. The call will not cause unbounded stack growth if it is part of a recursive cycle in the call graph. - #. Arguments with the :ref:`inalloca ` attribute are - forwarded in place. + #. Arguments with the :ref:`inalloca ` or + :ref:`preallocated ` attribute are forwarded in place. #. If the musttail call appears in a function with the ``"thunk"`` attribute and the caller and callee both have varargs, than any unprototyped arguments in register or memory are forwarded to the callee. Similarly, @@ -11204,9 +11643,11 @@ the escaped allocas are allocated, which would break attempts to use '``llvm.localrecover``'. .. _int_read_register: +.. _int_read_volatile_register: .. _int_write_register: -'``llvm.read_register``' and '``llvm.write_register``' Intrinsics +'``llvm.read_register``', '``llvm.read_volatile_register``', and +'``llvm.write_register``' Intrinsics ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax: @@ -11216,6 +11657,8 @@ Syntax: declare i32 @llvm.read_register.i32(metadata) declare i64 @llvm.read_register.i64(metadata) + declare i32 @llvm.read_volatile_register.i32(metadata) + declare i64 @llvm.read_volatile_register.i64(metadata) declare void @llvm.write_register.i32(metadata, i32 @value) declare void @llvm.write_register.i64(metadata, i64 @value) !0 = !{!"sp\00"} @@ -11223,17 +11666,21 @@ Syntax: Overview: """"""""" -The '``llvm.read_register``' and '``llvm.write_register``' intrinsics -provides access to the named register. The register must be valid on -the architecture being compiled to. The type needs to be compatible -with the register being read. +The '``llvm.read_register``', '``llvm.read_volatile_register``', and +'``llvm.write_register``' intrinsics provide access to the named register. +The register must be valid on the architecture being compiled to. The type +needs to be compatible with the register being read. Semantics: """""""""" -The '``llvm.read_register``' intrinsic returns the current value of the -register, where possible. The '``llvm.write_register``' intrinsic sets -the current value of the register, where possible. +The '``llvm.read_register``' and '``llvm.read_volatile_register``' intrinsics +return the current value of the register, where possible. The +'``llvm.write_register``' intrinsic sets the current value of the register, +where possible. + +A call to '``llvm.read_volatile_register``' is assumed to have side-effects +and possibly return a different value each time (e.g. for a timer register). This is useful to implement named register global variables that need to always be mapped to a specific register, as is common practice on @@ -11633,6 +12080,149 @@ call a helper function, read from an alternate memory space, or perform other operations necessary to locate the TLS area. Not all targets support this intrinsic. +'``llvm.call.preallocated.setup``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare token @llvm.call.preallocated.setup(i32 %num_args) + +Overview: +""""""""" + +The '``llvm.call.preallocated.setup``' intrinsic returns a token which can +be used with a call's ``"preallocated"`` operand bundle to indicate that +certain arguments are allocated and initialized before the call. + +Semantics: +"""""""""" + +The '``llvm.call.preallocated.setup``' intrinsic returns a token which is +associated with at most one call. The token can be passed to +'``@llvm.call.preallocated.arg``' to get a pointer to get that +corresponding argument. The token must be the parameter to a +``"preallocated"`` operand bundle for the corresponding call. + +Nested calls to '``llvm.call.preallocated.setup``' are allowed, but must +be properly nested. e.g. + +:: code-block:: llvm + + %t1 = call token @llvm.call.preallocated.setup(i32 0) + %t2 = call token @llvm.call.preallocated.setup(i32 0) + call void foo() ["preallocated"(token %t2)] + call void foo() ["preallocated"(token %t1)] + +is allowed, but not + +:: code-block:: llvm + + %t1 = call token @llvm.call.preallocated.setup(i32 0) + %t2 = call token @llvm.call.preallocated.setup(i32 0) + call void foo() ["preallocated"(token %t1)] + call void foo() ["preallocated"(token %t2)] + +.. _int_call_preallocated_arg: + +'``llvm.call.preallocated.arg``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare i8* @llvm.call.preallocated.arg(token %setup_token, i32 %arg_index) + +Overview: +""""""""" + +The '``llvm.call.preallocated.arg``' intrinsic returns a pointer to the +corresponding preallocated argument for the preallocated call. + +Semantics: +"""""""""" + +The '``llvm.call.preallocated.arg``' intrinsic returns a pointer to the +``%arg_index``th argument with the ``preallocated`` attribute for +the call associated with the ``%setup_token``, which must be from +'``llvm.call.preallocated.setup``'. + +A call to '``llvm.call.preallocated.arg``' must have a call site +``preallocated`` attribute. The type of the ``preallocated`` attribute must +match the type used by the ``preallocated`` attribute of the corresponding +argument at the preallocated call. The type is used in the case that an +``llvm.call.preallocated.setup`` does not have a corresponding call (e.g. due +to DCE), where otherwise we cannot know how large the arguments are. + +It is undefined behavior if this is called with a token from an +'``llvm.call.preallocated.setup``' if another +'``llvm.call.preallocated.setup``' has already been called or if the +preallocated call corresponding to the '``llvm.call.preallocated.setup``' +has already been called. + +.. _int_call_preallocated_teardown: + +'``llvm.call.preallocated.teardown``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare i8* @llvm.call.preallocated.teardown(token %setup_token) + +Overview: +""""""""" + +The '``llvm.call.preallocated.teardown``' intrinsic cleans up the stack +created by a '``llvm.call.preallocated.setup``'. + +Semantics: +"""""""""" + +The token argument must be a '``llvm.call.preallocated.setup``'. + +The '``llvm.call.preallocated.teardown``' intrinsic cleans up the stack +allocated by the corresponding '``llvm.call.preallocated.setup``'. Exactly +one of this or the preallocated call must be called to prevent stack leaks. +It is undefined behavior to call both a '``llvm.call.preallocated.teardown``' +and the preallocated call for a given '``llvm.call.preallocated.setup``'. + +For example, if the stack is allocated for a preallocated call by a +'``llvm.call.preallocated.setup``', then an initializer function called on an +allocated argument throws an exception, there should be a +'``llvm.call.preallocated.teardown``' in the exception handler to prevent +stack leaks. + +Following the nesting rules in '``llvm.call.preallocated.setup``', nested +calls to '``llvm.call.preallocated.setup``' and +'``llvm.call.preallocated.teardown``' are allowed but must be properly +nested. + +Example: +"""""""" + +.. code-block:: llvm + + %cs = call token @llvm.call.preallocated.setup(i32 1) + %x = call i8* @llvm.call.preallocated.arg(token %cs, i32 0) preallocated(i32) + %y = bitcast i8* %x to i32* + invoke void @constructor(i32* %y) to label %conta unwind label %contb + conta: + call void @foo1(i32* preallocated(i32) %y) ["preallocated"(token %cs)] + ret void + contb: + %s = catchswitch within none [label %catch] unwind to caller + catch: + %p = catchpad within %s [] + call void @llvm.call.preallocated.teardown(token %cs) + ret void + Standard C Library Intrinsics ----------------------------- @@ -11697,6 +12287,65 @@ the argument. If "len" is 0, the pointers may be NULL or dangling. However, they must still be appropriately aligned. +.. _int_memcpy_inline: + +'``llvm.memcpy.inline``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +This is an overloaded intrinsic. You can use ``llvm.memcpy.inline`` on any +integer bit width and for different address spaces. Not all targets +support all bit widths however. + +:: + + declare void @llvm.memcpy.inline.p0i8.p0i8.i32(i8* , i8* , + i32 , i1 ) + declare void @llvm.memcpy.inline.p0i8.p0i8.i64(i8* , i8* , + i64 , i1 ) + +Overview: +""""""""" + +The '``llvm.memcpy.inline.*``' intrinsics copy a block of memory from the +source location to the destination location and guarantees that no external +functions are called. + +Note that, unlike the standard libc function, the ``llvm.memcpy.inline.*`` +intrinsics do not return a value, takes extra isvolatile +arguments and the pointers can be in specified address spaces. + +Arguments: +"""""""""" + +The first argument is a pointer to the destination, the second is a +pointer to the source. The third argument is a constant integer argument +specifying the number of bytes to copy, and the fourth is a +boolean indicating a volatile access. + +The :ref:`align ` parameter attribute can be provided +for the first and second arguments. + +If the ``isvolatile`` parameter is ``true``, the ``llvm.memcpy.inline`` call is +a :ref:`volatile operation `. The detailed access behavior is not +very cleanly specified and it is unwise to depend on it. + +Semantics: +"""""""""" + +The '``llvm.memcpy.inline.*``' intrinsics copy a block of memory from the +source location to the destination location, which are not allowed to +overlap. It copies "len" bytes of memory over. If the argument is known +to be aligned to some boundary, this can be specified as an attribute on +the argument. + +If "len" is 0, the pointers may be NULL or dangling. However, they must still +be appropriately aligned. + +The generated code is guaranteed not to call any external functions. + .. _int_memmove: '``llvm.memmove``' Intrinsic @@ -12690,27 +13339,65 @@ Semantics: This function returns the same values as the libm ``round`` functions would, and handles error conditions in the same way. -'``llvm.lround.*``' Intrinsic +'``llvm.roundeven.*``' Intrinsic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax: """"""" -This is an overloaded intrinsic. You can use ``llvm.lround`` on any -floating-point type. Not all targets support all types however. +This is an overloaded intrinsic. You can use ``llvm.roundeven`` on any +floating-point or vector of floating-point type. Not all targets support +all types however. :: - declare i32 @llvm.lround.i32.f32(float %Val) - declare i32 @llvm.lround.i32.f64(double %Val) - declare i32 @llvm.lround.i32.f80(float %Val) - declare i32 @llvm.lround.i32.f128(double %Val) - declare i32 @llvm.lround.i32.ppcf128(double %Val) + declare float @llvm.roundeven.f32(float %Val) + declare double @llvm.roundeven.f64(double %Val) + declare x86_fp80 @llvm.roundeven.f80(x86_fp80 %Val) + declare fp128 @llvm.roundeven.f128(fp128 %Val) + declare ppc_fp128 @llvm.roundeven.ppcf128(ppc_fp128 %Val) - declare i64 @llvm.lround.i64.f32(float %Val) - declare i64 @llvm.lround.i64.f64(double %Val) - declare i64 @llvm.lround.i64.f80(float %Val) - declare i64 @llvm.lround.i64.f128(double %Val) +Overview: +""""""""" + +The '``llvm.roundeven.*``' intrinsics returns the operand rounded to the nearest +integer in floating-point format rounding halfway cases to even (that is, to the +nearest value that is an even integer). + +Arguments: +"""""""""" + +The argument and return value are floating-point numbers of the same type. + +Semantics: +"""""""""" + +This function implements IEEE-754 operation ``roundToIntegralTiesToEven``. It +also behaves in the same way as C standard function ``roundeven``, except that +it does not raise floating point exceptions. + + +'``llvm.lround.*``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +This is an overloaded intrinsic. You can use ``llvm.lround`` on any +floating-point type. Not all targets support all types however. + +:: + + declare i32 @llvm.lround.i32.f32(float %Val) + declare i32 @llvm.lround.i32.f64(double %Val) + declare i32 @llvm.lround.i32.f80(float %Val) + declare i32 @llvm.lround.i32.f128(double %Val) + declare i32 @llvm.lround.i32.ppcf128(double %Val) + + declare i64 @llvm.lround.i64.f32(float %Val) + declare i64 @llvm.lround.i64.f64(double %Val) + declare i64 @llvm.lround.i64.f80(float %Val) + declare i64 @llvm.lround.i64.f128(double %Val) declare i64 @llvm.lround.i64.ppcf128(double %Val) Overview: @@ -14102,6 +14789,136 @@ Examples %res = call i4 @llvm.udiv.fix.i4(i4 3, i4 4, i32 1) ; %res = 2 (or 1) (1.5 / 2 = 0.75) +'``llvm.sdiv.fix.sat.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax +""""""" + +This is an overloaded intrinsic. You can use ``llvm.sdiv.fix.sat`` +on any integer bit width or vectors of integers. + +:: + + declare i16 @llvm.sdiv.fix.sat.i16(i16 %a, i16 %b, i32 %scale) + declare i32 @llvm.sdiv.fix.sat.i32(i32 %a, i32 %b, i32 %scale) + declare i64 @llvm.sdiv.fix.sat.i64(i64 %a, i64 %b, i32 %scale) + declare <4 x i32> @llvm.sdiv.fix.sat.v4i32(<4 x i32> %a, <4 x i32> %b, i32 %scale) + +Overview +""""""""" + +The '``llvm.sdiv.fix.sat``' family of intrinsic functions perform signed +fixed point saturation division on 2 arguments of the same scale. + +Arguments +"""""""""" + +The arguments (%a and %b) and the result may be of integer types of any bit +width, but they must have the same bit width. ``%a`` and ``%b`` are the two +values that will undergo signed fixed point division. The argument +``%scale`` represents the scale of both operands, and must be a constant +integer. + +Semantics: +"""""""""" + +This operation performs fixed point division on the 2 arguments of a +specified scale. The result will also be returned in the same scale specified +in the third argument. + +If the result value cannot be precisely represented in the given scale, the +value is rounded up or down to the closest representable value. The rounding +direction is unspecified. + +The maximum value this operation can clamp to is the largest signed value +representable by the bit width of the first 2 arguments. The minimum value is the +smallest signed value representable by this bit width. + +It is undefined behavior if the second argument is zero. + + +Examples +""""""""" + +.. code-block:: llvm + + %res = call i4 @llvm.sdiv.fix.sat.i4(i4 6, i4 2, i32 0) ; %res = 3 (6 / 2 = 3) + %res = call i4 @llvm.sdiv.fix.sat.i4(i4 6, i4 4, i32 1) ; %res = 3 (3 / 2 = 1.5) + %res = call i4 @llvm.sdiv.fix.sat.i4(i4 3, i4 -2, i32 1) ; %res = -3 (1.5 / -1 = -1.5) + + ; The result in the following could be rounded up to 1 or down to 0.5 + %res = call i4 @llvm.sdiv.fix.sat.i4(i4 3, i4 4, i32 1) ; %res = 2 (or 1) (1.5 / 2 = 0.75) + + ; Saturation + %res = call i4 @llvm.sdiv.fix.sat.i4(i4 -8, i4 -1, i32 0) ; %res = 7 (-8 / -1 = 8 => 7) + %res = call i4 @llvm.sdiv.fix.sat.i4(i4 4, i4 2, i32 2) ; %res = 7 (1 / 0.5 = 2 => 1.75) + %res = call i4 @llvm.sdiv.fix.sat.i4(i4 -4, i4 1, i32 2) ; %res = -8 (-1 / 0.25 = -4 => -2) + + +'``llvm.udiv.fix.sat.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax +""""""" + +This is an overloaded intrinsic. You can use ``llvm.udiv.fix.sat`` +on any integer bit width or vectors of integers. + +:: + + declare i16 @llvm.udiv.fix.sat.i16(i16 %a, i16 %b, i32 %scale) + declare i32 @llvm.udiv.fix.sat.i32(i32 %a, i32 %b, i32 %scale) + declare i64 @llvm.udiv.fix.sat.i64(i64 %a, i64 %b, i32 %scale) + declare <4 x i32> @llvm.udiv.fix.sat.v4i32(<4 x i32> %a, <4 x i32> %b, i32 %scale) + +Overview +""""""""" + +The '``llvm.udiv.fix.sat``' family of intrinsic functions perform unsigned +fixed point saturation division on 2 arguments of the same scale. + +Arguments +"""""""""" + +The arguments (%a and %b) and the result may be of integer types of any bit +width, but they must have the same bit width. ``%a`` and ``%b`` are the two +values that will undergo unsigned fixed point division. The argument +``%scale`` represents the scale of both operands, and must be a constant +integer. + +Semantics: +"""""""""" + +This operation performs fixed point division on the 2 arguments of a +specified scale. The result will also be returned in the same scale specified +in the third argument. + +If the result value cannot be precisely represented in the given scale, the +value is rounded up or down to the closest representable value. The rounding +direction is unspecified. + +The maximum value this operation can clamp to is the largest unsigned value +representable by the bit width of the first 2 arguments. The minimum value is the +smallest unsigned value representable by this bit width (zero). + +It is undefined behavior if the second argument is zero. + +Examples +""""""""" + +.. code-block:: llvm + + %res = call i4 @llvm.udiv.fix.sat.i4(i4 6, i4 2, i32 0) ; %res = 3 (6 / 2 = 3) + %res = call i4 @llvm.udiv.fix.sat.i4(i4 6, i4 4, i32 1) ; %res = 3 (3 / 2 = 1.5) + + ; The result in the following could be rounded down to 0.5 or up to 1 + %res = call i4 @llvm.udiv.fix.sat.i4(i4 3, i4 4, i32 1) ; %res = 1 (or 2) (1.5 / 2 = 0.75) + + ; Saturation + %res = call i4 @llvm.udiv.fix.sat.i4(i4 8, i4 2, i32 2) ; %res = 15 (2 / 0.5 = 4 => 3.75) + + Specialised Arithmetic Intrinsics --------------------------------- @@ -14226,6 +15043,169 @@ Examples: %r2 = call float @llvm.fmuladd.f32(float %a, float %b, float %c) ; yields float:r2 = (a * b) + c +Hardware-Loop Intrinsics +------------------------ + +LLVM support several intrinsics to mark a loop as a hardware-loop. They are +hints to the backend which are required to lower these intrinsics further to target +specific instructions, or revert the hardware-loop to a normal loop if target +specific restriction are not met and a hardware-loop can't be generated. + +These intrinsics may be modified in the future and are not intended to be used +outside the backend. Thus, front-end and mid-level optimizations should not be +generating these intrinsics. + + +'``llvm.set.loop.iterations.*``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +This is an overloaded intrinsic. + +:: + + declare void @llvm.set.loop.iterations.i32(i32) + declare void @llvm.set.loop.iterations.i64(i64) + +Overview: +""""""""" + +The '``llvm.set.loop.iterations.*``' intrinsics are used to specify the +hardware-loop trip count. They are placed in the loop preheader basic block and +are marked as ``IntrNoDuplicate`` to avoid optimizers duplicating these +instructions. + +Arguments: +"""""""""" + +The integer operand is the loop trip count of the hardware-loop, and thus +not e.g. the loop back-edge taken count. + +Semantics: +"""""""""" + +The '``llvm.set.loop.iterations.*``' intrinsics do not perform any arithmetic +on their operand. It's a hint to the backend that can use this to set up the +hardware-loop count with a target specific instruction, usually a move of this +value to a special register or a hardware-loop instruction. + +'``llvm.test.set.loop.iterations.*``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +This is an overloaded intrinsic. + +:: + + declare void @llvm.test.set.loop.iterations.i32(i32) + declare void @llvm.test.set.loop.iterations.i64(i64) + +Overview: +""""""""" + +The '``llvm.test.set.loop.iterations.*``' intrinsics are used to specify the +the loop trip count, and also test that the given count is not zero, allowing +it to control entry to a while-loop. They are placed in the loop preheader's +predecessor basic block, and are marked as ``IntrNoDuplicate`` to avoid +optimizers duplicating these instructions. + +Arguments: +"""""""""" + +The integer operand is the loop trip count of the hardware-loop, and thus +not e.g. the loop back-edge taken count. + +Semantics: +"""""""""" + +The '``llvm.test.set.loop.iterations.*``' intrinsics do not perform any +arithmetic on their operand. It's a hint to the backend that can use this to +set up the hardware-loop count with a target specific instruction, usually a +move of this value to a special register or a hardware-loop instruction. + +'``llvm.loop.decrement.reg.*``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +This is an overloaded intrinsic. + +:: + + declare i32 @llvm.loop.decrement.reg.i32(i32, i32) + declare i64 @llvm.loop.decrement.reg.i64(i64, i64) + +Overview: +""""""""" + +The '``llvm.loop.decrement.reg.*``' intrinsics are used to lower the loop +iteration counter and return an updated value that will be used in the next +loop test check. + +Arguments: +"""""""""" + +Both arguments must have identical integer types. The first operand is the +loop iteration counter. The second operand is the maximum number of elements +processed in an iteration. + +Semantics: +"""""""""" + +The '``llvm.loop.decrement.reg.*``' intrinsics do an integer ``SUB`` of its +two operands, which is not allowed to wrap. They return the remaining number of +iterations still to be executed, and can be used together with a ``PHI``, +``ICMP`` and ``BR`` to control the number of loop iterations executed. Any +optimisations are allowed to treat it is a ``SUB``, and it is supported by +SCEV, so it's the backends responsibility to handle cases where it may be +optimised. These intrinsics are marked as ``IntrNoDuplicate`` to avoid +optimizers duplicating these instructions. + + +'``llvm.loop.decrement.*``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +This is an overloaded intrinsic. + +:: + + declare i1 @llvm.loop.decrement.i32(i32) + declare i1 @llvm.loop.decrement.i64(i64) + +Overview: +""""""""" + +The HardwareLoops pass allows the loop decrement value to be specified with an +option. It defaults to a loop decrement value of 1, but it can be an unsigned +integer value provided by this option. The '``llvm.loop.decrement.*``' +intrinsics decrement the loop iteration counter with this value, and return a +false predicate if the loop should exit, and true otherwise. +This is emitted if the loop counter is not updated via a ``PHI`` node, which +can also be controlled with an option. + +Arguments: +"""""""""" + +The integer argument is the loop decrement value used to decrement the loop +iteration counter. + +Semantics: +"""""""""" + +The '``llvm.loop.decrement.*``' intrinsics do a ``SUB`` of the loop iteration +counter with the given loop decrement value, and return false if the loop +should exit, this ``SUB`` is not allowed to wrap. The result is a condition +that is used by the conditional branch controlling the loop. + + Experimental Vector Reduction Intrinsics ---------------------------------------- @@ -14278,7 +15258,17 @@ matches the element-type of the vector input. If the intrinsic call has the 'reassoc' or 'fast' flags set, then the reduction will not preserve the associativity of an equivalent scalarized counterpart. Otherwise the reduction will be *ordered*, thus implying that -the operation respects the associativity of a scalarized reduction. +the operation respects the associativity of a scalarized reduction. That is, the +reduction begins with the start value and performs an fadd operation with consecutively +increasing vector element indices. See the following pseudocode: + +:: + + float ordered_fadd(start_value, input_vector) + result = start_value + for i = 0 to length(input_vector) + result = result + input_vector[i] + return result Arguments: @@ -14339,7 +15329,17 @@ matches the element-type of the vector input. If the intrinsic call has the 'reassoc' or 'fast' flags set, then the reduction will not preserve the associativity of an equivalent scalarized counterpart. Otherwise the reduction will be *ordered*, thus implying that -the operation respects the associativity of a scalarized reduction. +the operation respects the associativity of a scalarized reduction. That is, the +reduction begins with the start value and performs an fmul operation with consecutively +increasing vector element indices. See the following pseudocode: + +:: + + float ordered_fmul(start_value, input_vector) + result = start_value + for i = 0 to length(input_vector) + result = result * input_vector[i] + return result Arguments: @@ -14533,6 +15533,7 @@ The argument to this intrinsic must be a vector of floating-point values. Syntax: """"""" +This is an overloaded intrinsic. :: @@ -14553,24 +15554,24 @@ Arguments: """""""""" The argument to this intrinsic must be a vector of floating-point values. - -.. _i_matrixintrinsics: - Matrix Intrinsics ----------------- Operations on matrixes requiring shape information (like number of rows/columns -or the memory layout) can be expressed using the matrix intrinsics. Matrixes are -embedded in a flat vector and the intrinsics take the dimensions as arguments. -Currently column-major layout is assumed. The intrinsics support both integer -and floating point matrixes. +or the memory layout) can be expressed using the matrix intrinsics. These +intrinsics require matrix dimensions to be passed as immediate arguments, and +matrixes are passed and returned as vectors. This means that for a ``R`` x +``C`` matrix, element ``i`` of column ``j`` is at index ``j * R + i`` in the +corresponding vector, with indices starting at 0. Currently column-major layout +is assumed. The intrinsics support both integer and floating point matrixes. '``llvm.matrix.transpose.*``' Intrinsic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax: """"""" +This is an overloaded intrinsic. :: @@ -14579,91 +15580,125 @@ Syntax: Overview: """"""""" -The '``llvm.matrix.transpose.*``' intrinsic treats %In as containing a matrix -with rows and columns and returns the transposed matrix embedded in -the result vector. +The '``llvm.matrix.transpose.*``' intrinsics treat %In as a x matrix +and return the transposed matrix in the result vector. Arguments: """""""""" -The and arguments must be constant integers. The vector argument -%In and the returned vector must have * elements. +First argument %In is vector that corresponds to a x matrix. +Thus, arguments and correspond to the number of rows and columns, +respectively, and must be positive, constant integers. The returned vector must +have * elements, and have the same float or integer element type +as %In. '``llvm.matrix.multiply.*``' Intrinsic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax: """"""" +This is an overloaded intrinsic. :: - declare vectorty @llvm.matrix.multiply.*(vectorty %A, vectorty %B, i32 , i32 , i32 ) + declare vectorty @llvm.matrix.multiply.*(vectorty %A, vectorty %B, i32 , i32 , i32 ) Overview: """"""""" -The '``llvm.matrix.multiply.*``' intrinsic treats %A as matrix with rows and columns, %B as -matrix with rows and columns and multiplies them. The result matrix is returned embedded in the -result vector. +The '``llvm.matrix.multiply.*``' intrinsics treat %A as a x +matrix, %B as a x matrix, and multiplies them. The result +matrix is returned in the result vector. Arguments: """""""""" -The , and arguments must be constant integers. The vector argument %A -must have * elements, %B must have * elements and the returned -vector must have * elements. +The first vector argument %A corresponds to a matrix with * +elements, and the second argument %B to a matrix with * +elements. Arguments , and must be positive, +constant integers. The returned vector must have * +elements. Vectors %A, %B, and the returned vector all have the same float or +integer element type. -'``llvm.matrix.columnwise.load.*``' Intrinsic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +'``llvm.matrix.column.major.load.*``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax: """"""" +This is an overloaded intrinsic. :: - declare vectorty @llvm.matrix.columnwise.load.*(ptrty %Ptr, i32 %Stride, i32 , i32 ) + declare vectorty @llvm.matrix.column.major.load.*( + ptrty %Ptr, i64 %Stride, i1 , i32 , i32 ) Overview: """"""""" -The '``llvm.matrix.columnwise.load.*``' intrinsic loads a matrix with -rows and columns, using a stride of %Stride between columns. For two -consecutive columns A and B, %Stride refers to the distance (the number of -elements) between the start of column A and the start of column B. The result -matrix is returned embedded in the result vector. This allows for convenient -loading of sub matrixes. +The '``llvm.matrix.column.major.load.*``' intrinsics load a x +matrix using a stride of %Stride to compute the start address of the different +columns. This allows for convenient loading of sub matrixes. If +is true, the intrinsic is considered a :ref:`volatile memory access +`. The result matrix is returned in the result vector. If the %Ptr +argument is known to be aligned to some boundary, this can be specified as an +attribute on the argument. Arguments: """""""""" -The and arguments must be constant integers. The returned vector -must have * elements. %Stride must be >= . +The first argument %Ptr is a pointer type to the returned vector type, and +correponds to the start address to load from. The second argument %Stride is a +postive, constant integer with %Stride ``>=`` . %Stride is used to compute +the column memory addresses. I.e., for a column ``C``, its start memory +addresses is calculated with %Ptr + ``C`` * %Stride. The third Argument + is a boolean value. The fourth and fifth arguments, and +, correspond to the number of rows and columns, respectively, and must be +positive, constant integers. The returned vector must have * +elements. + +The :ref:`align ` parameter attribute can be provided +for the %Ptr arguments. -'``llvm.matrix.columnwise.store.*``' Intrinsic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +'``llvm.matrix.column.major.store.*``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax: """"""" :: - declare void @llvm.matrix.columnwise.store.*(vectorty %In, ptrty %Ptr, i32 %Stride, i32 , i32 ) + declare void @llvm.matrix.column.major.store.*( + vectorty %In, ptrty %Ptr, i64 %Stride, i1 , i32 , i32 ) Overview: """"""""" -The '``llvm.matrix.columnwise.store.*``' intrinsic stores the matrix with - rows and columns embedded in %In, using a stride of %Stride -between columns. For two consecutive columns A and B, %Stride refers to the -distance (the number of elements) between the start of column A and the start -of column B. +The '``llvm.matrix.column.major.store.*``' intrinsics store the x +matrix in %In to memory using a stride of %Stride between columns. If + is true, the intrinsic is considered a :ref:`volatile memory +access `. + +If the %Ptr argument is known to be aligned to some boundary, this can be +specified as an attribute on the argument. Arguments: """""""""" -The and arguments must be constant integers. The vector argument -%In must have * elements. %Stride must be >= . +The first argument %In is a vector that corresponds to a x matrix +to be stored to memory. The second argument %Ptr is a pointer to the vector +type of %In, and is the start address of the matrix in memory. The third +argument %Stride is a positive, constant integer with %Stride ``>=`` . +%Stride is used to compute the column memory addresses. I.e., for a column +``C``, its start memory addresses is calculated with %Ptr + ``C`` * %Stride. +The fourth argument is a boolean value. The arguments and + correspond to the number of rows and columns, respectively, and must be +positive, constant integers. + +The :ref:`align ` parameter attribute can be provided +for the %Ptr arguments. + Half Precision Floating-Point Intrinsics ---------------------------------------- @@ -14731,163 +15766,910 @@ Syntax: :: - declare float @llvm.convert.from.fp16.f32(i16 %a) - declare double @llvm.convert.from.fp16.f64(i16 %a) + declare float @llvm.convert.from.fp16.f32(i16 %a) + declare double @llvm.convert.from.fp16.f64(i16 %a) + +Overview: +""""""""" + +The '``llvm.convert.from.fp16``' intrinsic function performs a +conversion from half precision floating-point format to single precision +floating-point format. + +Arguments: +"""""""""" + +The intrinsic function contains single argument - the value to be +converted. + +Semantics: +"""""""""" + +The '``llvm.convert.from.fp16``' intrinsic function performs a +conversion from half single precision floating-point format to single +precision floating-point format. The input half-float value is +represented by an ``i16`` value. + +Examples: +""""""""" + +.. code-block:: llvm + + %a = load i16, i16* @x, align 2 + %res = call float @llvm.convert.from.fp16(i16 %a) + +.. _dbg_intrinsics: + +Debugger Intrinsics +------------------- + +The LLVM debugger intrinsics (which all start with ``llvm.dbg.`` +prefix), are described in the `LLVM Source Level +Debugging `_ +document. + +Exception Handling Intrinsics +----------------------------- + +The LLVM exception handling intrinsics (which all start with +``llvm.eh.`` prefix), are described in the `LLVM Exception +Handling `_ document. + +.. _int_trampoline: + +Trampoline Intrinsics +--------------------- + +These intrinsics make it possible to excise one parameter, marked with +the :ref:`nest ` attribute, from a function. The result is a +callable function pointer lacking the nest parameter - the caller does +not need to provide a value for it. Instead, the value to use is stored +in advance in a "trampoline", a block of memory usually allocated on the +stack, which also contains code to splice the nest value into the +argument list. This is used to implement the GCC nested function address +extension. + +For example, if the function is ``i32 f(i8* nest %c, i32 %x, i32 %y)`` +then the resulting function pointer has signature ``i32 (i32, i32)*``. +It can be created as follows: + +.. code-block:: llvm + + %tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86 + %tramp1 = getelementptr [10 x i8], [10 x i8]* %tramp, i32 0, i32 0 + call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8*, i32, i32)* @f to i8*), i8* %nval) + %p = call i8* @llvm.adjust.trampoline(i8* %tramp1) + %fp = bitcast i8* %p to i32 (i32, i32)* + +The call ``%val = call i32 %fp(i32 %x, i32 %y)`` is then equivalent to +``%val = call i32 %f(i8* %nval, i32 %x, i32 %y)``. + +.. _int_it: + +'``llvm.init.trampoline``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare void @llvm.init.trampoline(i8* , i8* , i8* ) + +Overview: +""""""""" + +This fills the memory pointed to by ``tramp`` with executable code, +turning it into a trampoline. + +Arguments: +"""""""""" + +The ``llvm.init.trampoline`` intrinsic takes three arguments, all +pointers. The ``tramp`` argument must point to a sufficiently large and +sufficiently aligned block of memory; this memory is written to by the +intrinsic. Note that the size and the alignment are target-specific - +LLVM currently provides no portable way of determining them, so a +front-end that generates this intrinsic needs to have some +target-specific knowledge. The ``func`` argument must hold a function +bitcast to an ``i8*``. + +Semantics: +"""""""""" + +The block of memory pointed to by ``tramp`` is filled with target +dependent code, turning it into a function. Then ``tramp`` needs to be +passed to :ref:`llvm.adjust.trampoline ` to get a pointer which can +be :ref:`bitcast (to a new function) and called `. The new +function's signature is the same as that of ``func`` with any arguments +marked with the ``nest`` attribute removed. At most one such ``nest`` +argument is allowed, and it must be of pointer type. Calling the new +function is equivalent to calling ``func`` with the same argument list, +but with ``nval`` used for the missing ``nest`` argument. If, after +calling ``llvm.init.trampoline``, the memory pointed to by ``tramp`` is +modified, then the effect of any later call to the returned function +pointer is undefined. + +.. _int_at: + +'``llvm.adjust.trampoline``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare i8* @llvm.adjust.trampoline(i8* ) + +Overview: +""""""""" + +This performs any required machine-specific adjustment to the address of +a trampoline (passed as ``tramp``). + +Arguments: +"""""""""" + +``tramp`` must point to a block of memory which already has trampoline +code filled in by a previous call to +:ref:`llvm.init.trampoline `. + +Semantics: +"""""""""" + +On some architectures the address of the code to be executed needs to be +different than the address where the trampoline is actually stored. This +intrinsic returns the executable address corresponding to ``tramp`` +after performing the required machine specific adjustments. The pointer +returned can then be :ref:`bitcast and executed `. + + +.. _int_vp: + +Vector Predication Intrinsics +----------------------------- +VP intrinsics are intended for predicated SIMD/vector code. A typical VP +operation takes a vector mask and an explicit vector length parameter as in: + +:: + + llvm.vp..*( %x, %y, %mask, i32 %evl) + +The vector mask parameter (%mask) always has a vector of `i1` type, for example +`<32 x i1>`. The explicit vector length parameter always has the type `i32` and +is an unsigned integer value. The explicit vector length parameter (%evl) is in +the range: + +:: + + 0 <= %evl <= W, where W is the number of vector elements + +Note that for :ref:`scalable vector types ` ``W`` is the runtime +length of the vector. + +The VP intrinsic has undefined behavior if ``%evl > W``. The explicit vector +length (%evl) creates a mask, %EVLmask, with all elements ``0 <= i < %evl`` set +to True, and all other lanes ``%evl <= i < W`` to False. A new mask %M is +calculated with an element-wise AND from %mask and %EVLmask: + +:: + + M = %mask AND %EVLmask + +A vector operation ```` on vectors ``A`` and ``B`` calculates: + +:: + + A B = { A[i] B[i] M[i] = True, and + { undef otherwise + +Optimization Hint +^^^^^^^^^^^^^^^^^ + +Some targets, such as AVX512, do not support the %evl parameter in hardware. +The use of an effective %evl is discouraged for those targets. The function +``TargetTransformInfo::hasActiveVectorLength()`` returns true when the target +has native support for %evl. + + +.. _int_vp_add: + +'``llvm.vp.add.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.add.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.add.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.add.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Predicated integer addition of two vectors of integers. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.add``' intrinsic performs integer addition (:ref:`add `) +of the first and second vector operand on each enabled lane. The result on +disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.add.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = add <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + +.. _int_vp_sub: + +'``llvm.vp.sub.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.sub.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.sub.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.sub.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Predicated integer subtraction of two vectors of integers. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.sub``' intrinsic performs integer subtraction +(:ref:`sub `) of the first and second vector operand on each enabled +lane. The result on disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.sub.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = sub <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + + + +.. _int_vp_mul: + +'``llvm.vp.mul.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.mul.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.mul.nxv46i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.mul.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Predicated integer multiplication of two vectors of integers. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" +The '``llvm.vp.mul``' intrinsic performs integer multiplication +(:ref:`mul `) of the first and second vector operand on each enabled +lane. The result on disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.mul.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = mul <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + + +.. _int_vp_sdiv: + +'``llvm.vp.sdiv.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.sdiv.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.sdiv.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.sdiv.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Predicated, signed division of two vectors of integers. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.sdiv``' intrinsic performs signed division (:ref:`sdiv `) +of the first and second vector operand on each enabled lane. The result on +disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.sdiv.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = sdiv <4 x i32> %a, %b + %also.r = select <4 x ii> %mask, <4 x i32> %t, <4 x i32> undef + + +.. _int_vp_udiv: + +'``llvm.vp.udiv.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.udiv.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.udiv.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.udiv.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Predicated, unsigned division of two vectors of integers. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The third operand is the vector mask and has the same number of elements as the result vector type. The fourth operand is the explicit vector length of the operation. + +Semantics: +"""""""""" + +The '``llvm.vp.udiv``' intrinsic performs unsigned division +(:ref:`udiv `) of the first and second vector operand on each enabled +lane. The result on disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.udiv.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = udiv <4 x i32> %a, %b + %also.r = select <4 x ii> %mask, <4 x i32> %t, <4 x i32> undef + + + +.. _int_vp_srem: + +'``llvm.vp.srem.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.srem.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.srem.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.srem.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Predicated computations of the signed remainder of two integer vectors. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.srem``' intrinsic computes the remainder of the signed division +(:ref:`srem `) of the first and second vector operand on each enabled +lane. The result on disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.srem.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = srem <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + + + +.. _int_vp_urem: + +'``llvm.vp.urem.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.urem.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.urem.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.urem.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Predicated computation of the unsigned remainder of two integer vectors. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.urem``' intrinsic computes the remainder of the unsigned division +(:ref:`urem `) of the first and second vector operand on each enabled +lane. The result on disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.urem.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = urem <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + + +.. _int_vp_ashr: + +'``llvm.vp.ashr.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.ashr.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.ashr.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.ashr.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Vector-predicated arithmetic right-shift. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.ashr``' intrinsic computes the arithmetic right shift +(:ref:`ashr `) of the first operand by the second operand on each +enabled lane. The result on disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.ashr.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = ashr <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + + +.. _int_vp_lshr: + + +'``llvm.vp.lshr.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.lshr.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.lshr.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.lshr.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Vector-predicated logical right-shift. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.lshr``' intrinsic computes the logical right shift +(:ref:`lshr `) of the first operand by the second operand on each +enabled lane. The result on disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.lshr.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = lshr <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + + +.. _int_vp_shl: + +'``llvm.vp.shl.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.shl.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.shl.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.shl.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Vector-predicated left shift. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.shl``' intrinsic computes the left shift (:ref:`shl `) of +the first operand by the second operand on each enabled lane. The result on +disabled lanes is undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.shl.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = shl <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + + +.. _int_vp_or: + +'``llvm.vp.or.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.or.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.or.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.or.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) + +Overview: +""""""""" + +Vector-predicated or. + + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.or``' intrinsic performs a bitwise or (:ref:`or `) of the +first two operands on each enabled lane. The result on disabled lanes is +undefined. + +Examples: +""""""""" + +.. code-block:: llvm + + %r = call <4 x i32> @llvm.vp.or.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r + + %t = or <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef + + +.. _int_vp_and: + +'``llvm.vp.and.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" +This is an overloaded intrinsic. + +:: + + declare <16 x i32> @llvm.vp.and.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.and.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.and.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) Overview: """"""""" -The '``llvm.convert.from.fp16``' intrinsic function performs a -conversion from half precision floating-point format to single precision -floating-point format. +Vector-predicated and. + Arguments: """""""""" -The intrinsic function contains single argument - the value to be -converted. +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. Semantics: """""""""" -The '``llvm.convert.from.fp16``' intrinsic function performs a -conversion from half single precision floating-point format to single -precision floating-point format. The input half-float value is -represented by an ``i16`` value. +The '``llvm.vp.and``' intrinsic performs a bitwise and (:ref:`and `) of +the first two operands on each enabled lane. The result on disabled lanes is +undefined. Examples: """"""""" .. code-block:: llvm - %a = load i16, i16* @x, align 2 - %res = call float @llvm.convert.from.fp16(i16 %a) + %r = call <4 x i32> @llvm.vp.and.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r -.. _dbg_intrinsics: + %t = and <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef -Debugger Intrinsics -------------------- -The LLVM debugger intrinsics (which all start with ``llvm.dbg.`` -prefix), are described in the `LLVM Source Level -Debugging `_ -document. +.. _int_vp_xor: -Exception Handling Intrinsics ------------------------------ +'``llvm.vp.xor.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The LLVM exception handling intrinsics (which all start with -``llvm.eh.`` prefix), are described in the `LLVM Exception -Handling `_ document. +Syntax: +""""""" +This is an overloaded intrinsic. -.. _int_trampoline: +:: -Trampoline Intrinsics ---------------------- + declare <16 x i32> @llvm.vp.xor.v16i32 (<16 x i32> , <16 x i32> , <16 x i1> , i32 ) + declare @llvm.vp.xor.nxv4i32 ( , , , i32 ) + declare <256 x i64> @llvm.vp.xor.v256i64 (<256 x i64> , <256 x i64> , <256 x i1> , i32 ) -These intrinsics make it possible to excise one parameter, marked with -the :ref:`nest ` attribute, from a function. The result is a -callable function pointer lacking the nest parameter - the caller does -not need to provide a value for it. Instead, the value to use is stored -in advance in a "trampoline", a block of memory usually allocated on the -stack, which also contains code to splice the nest value into the -argument list. This is used to implement the GCC nested function address -extension. +Overview: +""""""""" + +Vector-predicated, bitwise xor. -For example, if the function is ``i32 f(i8* nest %c, i32 %x, i32 %y)`` -then the resulting function pointer has signature ``i32 (i32, i32)*``. -It can be created as follows: + +Arguments: +"""""""""" + +The first two operands and the result have the same vector of integer type. The +third operand is the vector mask and has the same number of elements as the +result vector type. The fourth operand is the explicit vector length of the +operation. + +Semantics: +"""""""""" + +The '``llvm.vp.xor``' intrinsic performs a bitwise xor (:ref:`xor `) of +the first two operands on each enabled lane. +The result on disabled lanes is undefined. + +Examples: +""""""""" .. code-block:: llvm - %tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86 - %tramp1 = getelementptr [10 x i8], [10 x i8]* %tramp, i32 0, i32 0 - call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8*, i32, i32)* @f to i8*), i8* %nval) - %p = call i8* @llvm.adjust.trampoline(i8* %tramp1) - %fp = bitcast i8* %p to i32 (i32, i32)* + %r = call <4 x i32> @llvm.vp.xor.v4i32(<4 x i32> %a, <4 x i32> %b, <4 x i1> %mask, i32 %evl) + ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r -The call ``%val = call i32 %fp(i32 %x, i32 %y)`` is then equivalent to -``%val = call i32 %f(i8* %nval, i32 %x, i32 %y)``. + %t = xor <4 x i32> %a, %b + %also.r = select <4 x i1> %mask, <4 x i32> %t, <4 x i32> undef -.. _int_it: -'``llvm.init.trampoline``' Intrinsic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +.. _int_get_active_lane_mask: + +'``llvm.get.active.lane.mask.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax: """"""" +This is an overloaded intrinsic. :: - declare void @llvm.init.trampoline(i8* , i8* , i8* ) + declare <4 x i1> @llvm.get.active.lane.mask.v4i1.i32(i32 %base, i32 %n) + declare <8 x i1> @llvm.get.active.lane.mask.v8i1.i64(i64 %base, i64 %n) + declare <16 x i1> @llvm.get.active.lane.mask.v16i1.i64(i64 %base, i64 %n) + declare @llvm.get.active.lane.mask.nxv16i1.i64(i64 %base, i64 %n) + Overview: """"""""" -This fills the memory pointed to by ``tramp`` with executable code, -turning it into a trampoline. +Create a mask representing active and inactive vector lanes. + Arguments: """""""""" -The ``llvm.init.trampoline`` intrinsic takes three arguments, all -pointers. The ``tramp`` argument must point to a sufficiently large and -sufficiently aligned block of memory; this memory is written to by the -intrinsic. Note that the size and the alignment are target-specific - -LLVM currently provides no portable way of determining them, so a -front-end that generates this intrinsic needs to have some -target-specific knowledge. The ``func`` argument must hold a function -bitcast to an ``i8*``. +Both operands have the same scalar integer type. The result is a vector with +the i1 element type. Semantics: """""""""" -The block of memory pointed to by ``tramp`` is filled with target -dependent code, turning it into a function. Then ``tramp`` needs to be -passed to :ref:`llvm.adjust.trampoline ` to get a pointer which can -be :ref:`bitcast (to a new function) and called `. The new -function's signature is the same as that of ``func`` with any arguments -marked with the ``nest`` attribute removed. At most one such ``nest`` -argument is allowed, and it must be of pointer type. Calling the new -function is equivalent to calling ``func`` with the same argument list, -but with ``nval`` used for the missing ``nest`` argument. If, after -calling ``llvm.init.trampoline``, the memory pointed to by ``tramp`` is -modified, then the effect of any later call to the returned function -pointer is undefined. +The '``llvm.get.active.lane.mask.*``' intrinsics are semantically equivalent +to: -.. _int_at: +:: -'``llvm.adjust.trampoline``' Intrinsic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + %m[i] = icmp ule (%base + i), %n -Syntax: -""""""" +where ``%m`` is a vector (mask) of active/inactive lanes with its elements +indexed by ``i``, and ``%base``, ``%n`` are the two arguments to +``llvm.get.active.lane.mask.*``, ``%imcp`` is an integer compare and ``ule`` +the unsigned less-than-equal comparison operator. Overflow cannot occur in +``(%base + i)`` and its comparison against ``%n`` as it is performed in integer +numbers and not in machine numbers. The above is equivalent to: :: - declare i8* @llvm.adjust.trampoline(i8* ) + %m = @llvm.get.active.lane.mask(%base, %n) -Overview: -""""""""" +This can, for example, be emitted by the loop vectorizer. Then, ``%base`` is +the first element of the vector induction variable (VIV), and ``%n`` is the +Back-edge Taken Count (BTC). Thus, these intrinsics perform an element-wise +less than or equal comparison of VIV with BTC, producing a mask of true/false +values representing active/inactive vector lanes, except if the VIV overflows +in which case they return false in the lanes where the VIV overflows. The +arguments are scalar types to accomodate scalable vector types, for which it is +unknown what the type of the step vector needs to be that enumerate its +lanes without overflow. -This performs any required machine-specific adjustment to the address of -a trampoline (passed as ``tramp``). +This mask ``%m`` can e.g. be used in masked load/store instructions. These +intrinsics provide a hint to the backend. I.e., for a vector loop, the +back-edge taken count of the original scalar loop is explicit as the second +argument. -Arguments: -"""""""""" -``tramp`` must point to a block of memory which already has trampoline -code filled in by a previous call to -:ref:`llvm.init.trampoline `. +Examples: +""""""""" -Semantics: -"""""""""" +.. code-block:: llvm + + %active.lane.mask = call <4 x i1> @llvm.get.active.lane.mask.v4i1.i64(i64 %elem0, i64 429) + %wide.masked.load = call <4 x i32> @llvm.masked.load.v4i32.p0v4i32(<4 x i32>* %3, i32 4, <4 x i1> %active.lane.mask, <4 x i32> undef) -On some architectures the address of the code to be executed needs to be -different than the address where the trampoline is actually stored. This -intrinsic returns the executable address corresponding to ``tramp`` -after performing the required machine specific adjustments. The pointer -returned can then be :ref:`bitcast and executed `. .. _int_mload_mstore: @@ -14923,8 +16705,7 @@ Reads a vector from memory according to the provided mask. The mask holds a bit Arguments: """""""""" -The first operand is the base pointer for the load. The second operand is the alignment of the source location. It must be a constant integer value. The third operand, mask, is a vector of boolean values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the base pointer and the type of the '``passthru``' operand are the same vector types. - +The first operand is the base pointer for the load. The second operand is the alignment of the source location. It must be a power of two constant integer value. The third operand, mask, is a vector of boolean values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the base pointer and the type of the '``passthru``' operand are the same vector types. Semantics: """""""""" @@ -14967,7 +16748,7 @@ Writes a vector to memory according to the provided mask. The mask holds a bit f Arguments: """""""""" -The first operand is the vector value to be written to memory. The second operand is the base pointer for the store, it has the same underlying type as the value operand. The third operand is the alignment of the destination location. The fourth operand, mask, is a vector of boolean values. The types of the mask and the value operand must have the same number of vector elements. +The first operand is the vector value to be written to memory. The second operand is the base pointer for the store, it has the same underlying type as the value operand. The third operand is the alignment of the destination location. It must be a power of two constant integer value. The fourth operand, mask, is a vector of boolean values. The types of the mask and the value operand must have the same number of vector elements. Semantics: @@ -15015,8 +16796,7 @@ Reads scalar values from arbitrary memory locations and gathers them into one ve Arguments: """""""""" -The first operand is a vector of pointers which holds all memory addresses to read. The second operand is an alignment of the source addresses. It must be a constant integer value. The third operand, mask, is a vector of boolean values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the vector of pointers and the type of the '``passthru``' operand are the same vector types. - +The first operand is a vector of pointers which holds all memory addresses to read. The second operand is an alignment of the source addresses. It must be 0 or a power of two constant integer value. The third operand, mask, is a vector of boolean values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the vector of pointers and the type of the '``passthru``' operand are the same vector types. Semantics: """""""""" @@ -15068,8 +16848,7 @@ Writes each element from the value vector to the corresponding memory address. T Arguments: """""""""" -The first operand is a vector value to be written to memory. The second operand is a vector of pointers, pointing to where the value elements should be stored. It has the same underlying type as the value operand. The third operand is an alignment of the destination addresses. The fourth operand, mask, is a vector of boolean values. The types of the mask and the value operand must have the same number of vector elements. - +The first operand is a vector value to be written to memory. The second operand is a vector of pointers, pointing to where the value elements should be stored. It has the same underlying type as the value operand. The third operand is an alignment of the destination addresses. It must be 0 or a power of two constant integer value. The fourth operand, mask, is a vector of boolean values. The types of the mask and the value operand must have the same number of vector elements. Semantics: """""""""" @@ -15119,7 +16898,7 @@ This is an overloaded intrinsic. Several values of integer, floating point or po Overview: """"""""" -Reads a number of scalar values sequentially from memory location provided in '``ptr``' and spreads them in a vector. The '``mask``' holds a bit for each vector lane. The number of elements read from memory is equal to the number of '1' bits in the mask. The loaded elements are positioned in the destination vector according to the sequence of '1' and '0' bits in the mask. E.g., if the mask vector is '10010001', "explandload" reads 3 values from memory addresses ptr, ptr+1, ptr+2 and places them in lanes 0, 3 and 7 accordingly. The masked-off lanes are filled by elements from the corresponding lanes of the '``passthru``' operand. +Reads a number of scalar values sequentially from memory location provided in '``ptr``' and spreads them in a vector. The '``mask``' holds a bit for each vector lane. The number of elements read from memory is equal to the number of '1' bits in the mask. The loaded elements are positioned in the destination vector according to the sequence of '1' and '0' bits in the mask. E.g., if the mask vector is '10010001', "expandload" reads 3 values from memory addresses ptr, ptr+1, ptr+2 and places them in lanes 0, 3 and 7 accordingly. The masked-off lanes are filled by elements from the corresponding lanes of the '``passthru``' operand. Arguments: @@ -15447,9 +17226,9 @@ Each of these intrinsics corresponds to a normal floating-point operation. The data arguments and the return value are the same as the corresponding FP operation. -The rounding mode argument is a metadata string specifying what -assumptions, if any, the optimizer can make when transforming constant -values. Some constrained FP intrinsics omit this argument. If required +The rounding mode argument is a metadata string specifying what +assumptions, if any, the optimizer can make when transforming constant +values. Some constrained FP intrinsics omit this argument. If required by the intrinsic, this argument must be one of the following strings: :: @@ -15459,6 +17238,7 @@ by the intrinsic, this argument must be one of the following strings: "round.downward" "round.upward" "round.towardzero" + "round.tonearestaway" If this argument is "round.dynamic" optimization passes must assume that the rounding mode is unknown and may change at runtime. No transformations that @@ -15765,7 +17545,7 @@ Syntax: Overview: """"""""" -The '``llvm.experimental.constrained.fptoui``' intrinsic converts a +The '``llvm.experimental.constrained.fptoui``' intrinsic converts a floating-point ``value`` to its unsigned integer equivalent of type ``ty2``. Arguments: @@ -15798,7 +17578,7 @@ Syntax: Overview: """"""""" -The '``llvm.experimental.constrained.fptosi``' intrinsic converts +The '``llvm.experimental.constrained.fptosi``' intrinsic converts :ref:`floating-point ` ``value`` to type ``ty2``. Arguments: @@ -15806,7 +17586,7 @@ Arguments: The first argument to the '``llvm.experimental.constrained.fptosi``' intrinsic must be :ref:`floating point ` or :ref:`vector -` of floating point values. +` of floating point values. The second argument specifies the exception behavior as described above. @@ -15915,7 +17695,7 @@ intrinsic must be :ref:`floating point ` or :ref:`vector ` of floating point values. This argument must be larger in size than the result. -The second and third arguments specify the rounding mode and exception +The second and third arguments specify the rounding mode and exception behavior as described above. Semantics: @@ -15939,7 +17719,7 @@ Syntax: Overview: """"""""" -The '``llvm.experimental.constrained.fpext``' intrinsic extends a +The '``llvm.experimental.constrained.fpext``' intrinsic extends a floating-point ``value`` to a larger floating-point value. Arguments: @@ -16066,6 +17846,69 @@ if either operand is a SNAN. The signaling comparison operation performed by '``llvm.experimental.constrained.fcmps``' will raise an exception if either operand is a NAN (QNAN or SNAN). +'``llvm.experimental.constrained.fmuladd``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare + @llvm.experimental.constrained.fmuladd( , , + , + metadata , + metadata ) + +Overview: +""""""""" + +The '``llvm.experimental.constrained.fmuladd``' intrinsic represents +multiply-add expressions that can be fused if the code generator determines +that (a) the target instruction set has support for a fused operation, +and (b) that the fused operation is more efficient than the equivalent, +separate pair of mul and add instructions. + +Arguments: +"""""""""" + +The first three arguments to the '``llvm.experimental.constrained.fmuladd``' +intrinsic must be floating-point or vector of floating-point values. +All three arguments must have identical types. + +The fourth and fifth arguments specify the rounding mode and exception behavior +as described above. + +Semantics: +"""""""""" + +The expression: + +:: + + %0 = call float @llvm.experimental.constrained.fmuladd.f32(%a, %b, %c, + metadata , + metadata ) + +is equivalent to the expression: + +:: + + %0 = call float @llvm.experimental.constrained.fmul.f32(%a, %b, + metadata , + metadata ) + %1 = call float @llvm.experimental.constrained.fadd.f32(%0, %c, + metadata , + metadata ) + +except that it is unspecified whether rounding will be performed between the +multiplication and addition steps. Fusion is not guaranteed, even if the target +platform supports it. +If a fused multiply-add is required, the corresponding +:ref:`llvm.experimental.constrained.fma ` intrinsic function should be +used instead. +This never sets errno, just as '``llvm.experimental.constrained.fma.*``'. + Constrained libm-equivalent Intrinsics -------------------------------------- @@ -16844,6 +18687,42 @@ This function returns the same values as the libm ``round`` functions would and handles error conditions in the same way. +'``llvm.experimental.constrained.roundeven``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare + @llvm.experimental.constrained.roundeven( , + metadata ) + +Overview: +""""""""" + +The '``llvm.experimental.constrained.roundeven``' intrinsic returns the first +operand rounded to the nearest integer in floating-point format, rounding +halfway cases to even (that is, to the nearest value that is an even integer), +regardless of the current rounding direction. + +Arguments: +"""""""""" + +The first argument and the return value are floating-point numbers of the same +type. + +The second argument specifies the exception behavior as described above. + +Semantics: +"""""""""" + +This function implements IEEE-754 operation ``roundToIntegralTiesToEven``. It +also behaves in the same way as C standard function ``roundeven`` and can signal +the invalid operation exception for a SNAN operand. + + '``llvm.experimental.constrained.lround``' Intrinsic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -16893,7 +18772,7 @@ Syntax: declare @llvm.experimental.constrained.llround( , metadata ) - + Overview: """"""""" @@ -16954,6 +18833,46 @@ This function returns the same values as the libm ``trunc`` functions would and handles error conditions in the same way. +Floating Point Environment Manipulation intrinsics +-------------------------------------------------- + +These functions read or write floating point environment, such as rounding +mode or state of floating point exceptions. Altering the floating point +environment requires special care. See :ref:`Floating Point Environment `. + +'``llvm.flt.rounds``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare i32 @llvm.flt.rounds() + +Overview: +""""""""" + +The '``llvm.flt.rounds``' intrinsic reads the current rounding mode. + +Semantics: +"""""""""" + +The '``llvm.flt.rounds``' intrinsic returns the current rounding mode. +Encoding of the returned values is same as the result of ``FLT_ROUNDS``, +specified by C standard: + +:: + + 0 - toward zero + 1 - to nearest, ties to even + 2 - toward positive infinity + 3 - toward negative infinity + 4 - to nearest, ties away from zero + +Other values may be used to represent additional rounding modes, supported by a +target. These values are target-specific. + General Intrinsics ------------------ @@ -17289,6 +19208,40 @@ Semantics: This intrinsic is lowered to the ``val``. +'``llvm.expect.with.probability``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +This intrinsic is similar to ``llvm.expect``. This is an overloaded intrinsic. +You can use ``llvm.expect.with.probability`` on any integer bit width. + +:: + + declare i1 @llvm.expect.with.probability.i1(i1 , i1 , double ) + declare i32 @llvm.expect.with.probability.i32(i32 , i32 , double ) + declare i64 @llvm.expect.with.probability.i64(i64 , i64 , double ) + +Overview: +""""""""" + +The ``llvm.expect.with.probability`` intrinsic provides information about +expected value of ``val`` with probability(or confidence) ``prob``, which can +be used by optimizers. + +Arguments: +"""""""""" + +The ``llvm.expect.with.probability`` intrinsic takes three arguments. The first +argument is a value. The second argument is an expected value. The third +argument is a probability. + +Semantics: +"""""""""" + +This intrinsic is lowered to the ``val``. + .. _int_assume: '``llvm.assume``' Intrinsic @@ -17308,10 +19261,14 @@ The ``llvm.assume`` allows the optimizer to assume that the provided condition is true. This information can then be used in simplifying other parts of the code. +More complex assumptions can be encoded as +:ref:`assume operand bundles `. + Arguments: """""""""" -The condition which the optimizer may assume is always true. +The argument of the call is the condition which the optimizer may assume is +always true. Semantics: """""""""" @@ -17871,6 +19828,34 @@ information on the *based on* terminology see mask argument does not match the pointer size of the target, the mask is zero-extended or truncated accordingly. +.. _int_vscale: + +'``llvm.vscale``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare i32 llvm.vscale.i32() + declare i64 llvm.vscale.i64() + +Overview: +""""""""" + +The ``llvm.vscale`` intrinsic returns the value for ``vscale`` in scalable +vectors such as ````. + +Semantics: +"""""""""" + +``vscale`` is a positive value that is constant throughout program +execution, but is unknown at compile time. +If the result value does not fit in the result type, then the result is +a :ref:`poison value `. + + Stack Map Intrinsics -------------------- diff --git a/gnu/llvm/llvm/docs/Lexicon.rst b/gnu/llvm/llvm/docs/Lexicon.rst index d42ce90730f..cf194eb0d1d 100644 --- a/gnu/llvm/llvm/docs/Lexicon.rst +++ b/gnu/llvm/llvm/docs/Lexicon.rst @@ -112,7 +112,7 @@ G **GEP** ``GetElementPtr``. An LLVM IR instruction that is used to get the address of a subelement of an aggregate data structure. It is documented in detail - `here `_. + `here `_. **GVN** Global Value Numbering. GVN is a pass that partitions values computed by a @@ -230,6 +230,10 @@ R and other optimization. For example, changing ``(A+B-A)`` into ``(B+A-A)``, permitting it to be optimized into ``(B+0)`` then ``(B)``. +**RFC** + Request for Comment. An email sent to a project mailing list in order to + solicit feedback on a proposed change. + .. _roots: .. _stack roots: @@ -250,7 +254,7 @@ S **Safe Point** In garbage collection, it is necessary to identify `stack roots`_ so that reachability analysis may proceed. It may be infeasible to provide this - information for every instruction, so instead the information may is + information for every instruction, so instead the information is calculated only at designated safe points. With a copying collector, `derived pointers`_ must not be retained across safe points and `object pointers`_ must be reloaded from stack roots. diff --git a/gnu/llvm/llvm/docs/LibFuzzer.rst b/gnu/llvm/llvm/docs/LibFuzzer.rst index 9ab013e721e..4e83955a054 100644 --- a/gnu/llvm/llvm/docs/LibFuzzer.rst +++ b/gnu/llvm/llvm/docs/LibFuzzer.rst @@ -250,7 +250,7 @@ still work. The most important command line options are: ``-help`` - Print help message. + Print help message (``-help=1``). ``-seed`` Random seed. If 0 (the default), the seed is generated. ``-runs`` @@ -258,7 +258,7 @@ The most important command line options are: ``-max_len`` Maximum length of a test input. If 0 (the default), libFuzzer tries to guess a good value based on the corpus (and reports it). -``len_control`` +``-len_control`` Try generating small inputs first, then try larger inputs over time. Specifies the rate at which the length limit is increased (smaller == faster). Default is 100. If 0, immediately try inputs with size up to max_len. @@ -287,7 +287,7 @@ The most important command line options are: that trigger new code coverage will be merged into the first corpus directory. Defaults to 0. This flag can be used to minimize a corpus. ``-merge_control_file`` - Specify a control file used for the merge proccess. + Specify a control file used for the merge process. If a merge process gets killed it tries to leave this file in a state suitable for resuming the merge. By default a temporary file will be used. ``-minimize_crash`` @@ -515,7 +515,7 @@ and extra run-time flag ``-use_value_profile=1`` the fuzzer will collect value profiles for the parameters of compare instructions and treat some new values as new coverage. -The current imlpementation does roughly the following: +The current implementation does roughly the following: * The compiler instruments all CMP instructions with a callback that receives both CMP arguments. * The callback computes `(caller_pc&4095) | (popcnt(Arg1 ^ Arg2) << 12)` and uses this value to set a bit in a bitset. @@ -581,7 +581,7 @@ you will want to know whether the function or the corpus can be improved further One easy to use metric is, of course, code coverage. We recommend to use -`Clang Coverage `_, +`Clang Coverage `_, to visualize and study your code coverage (`example `_). @@ -768,7 +768,7 @@ Trophies * WOFF2: `[1] `__ -* LLVM: `Clang `_, `Clang-format `_, `libc++ `_, `llvm-as `_, `Demangler `_, Disassembler: http://reviews.llvm.org/rL247405, http://reviews.llvm.org/rL247414, http://reviews.llvm.org/rL247416, http://reviews.llvm.org/rL247417, http://reviews.llvm.org/rL247420, http://reviews.llvm.org/rL247422. +* LLVM: `Clang `_, `Clang-format `_, `libc++ `_, `llvm-as `_, `Demangler `_, Disassembler: http://reviews.llvm.org/rL247405, http://reviews.llvm.org/rL247414, http://reviews.llvm.org/rL247416, http://reviews.llvm.org/rL247417, http://reviews.llvm.org/rL247420, http://reviews.llvm.org/rL247422. * Tensorflow: `[1] `__ @@ -781,18 +781,18 @@ Trophies .. _pcre2: http://www.pcre.org/ .. _AFL: http://lcamtuf.coredump.cx/afl/ .. _Radamsa: https://github.com/aoh/radamsa -.. _SanitizerCoverage: http://clang.llvm.org/docs/SanitizerCoverage.html -.. _SanitizerCoverageTraceDataFlow: http://clang.llvm.org/docs/SanitizerCoverage.html#tracing-data-flow -.. _AddressSanitizer: http://clang.llvm.org/docs/AddressSanitizer.html -.. _LeakSanitizer: http://clang.llvm.org/docs/LeakSanitizer.html +.. _SanitizerCoverage: https://clang.llvm.org/docs/SanitizerCoverage.html +.. _SanitizerCoverageTraceDataFlow: https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-data-flow +.. _AddressSanitizer: https://clang.llvm.org/docs/AddressSanitizer.html +.. _LeakSanitizer: https://clang.llvm.org/docs/LeakSanitizer.html .. _Heartbleed: http://en.wikipedia.org/wiki/Heartbleed .. _FuzzerInterface.h: https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/fuzzer/FuzzerInterface.h -.. _3.7.0: http://llvm.org/releases/3.7.0/docs/LibFuzzer.html -.. _building Clang from trunk: http://clang.llvm.org/get_started.html -.. _MemorySanitizer: http://clang.llvm.org/docs/MemorySanitizer.html -.. _UndefinedBehaviorSanitizer: http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html -.. _`coverage counters`: http://clang.llvm.org/docs/SanitizerCoverage.html#coverage-counters +.. _3.7.0: https://llvm.org/releases/3.7.0/docs/LibFuzzer.html +.. _building Clang from trunk: https://clang.llvm.org/get_started.html +.. _MemorySanitizer: https://clang.llvm.org/docs/MemorySanitizer.html +.. _UndefinedBehaviorSanitizer: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html +.. _`coverage counters`: https://clang.llvm.org/docs/SanitizerCoverage.html#coverage-counters .. _`value profile`: #value-profile -.. _`caller-callee pairs`: http://clang.llvm.org/docs/SanitizerCoverage.html#caller-callee-coverage +.. _`caller-callee pairs`: https://clang.llvm.org/docs/SanitizerCoverage.html#caller-callee-coverage .. _BoringSSL: https://boringssl.googlesource.com/boringssl/ diff --git a/gnu/llvm/llvm/docs/LinkTimeOptimization.rst b/gnu/llvm/llvm/docs/LinkTimeOptimization.rst index 010a7881623..9e0c2cc9f62 100644 --- a/gnu/llvm/llvm/docs/LinkTimeOptimization.rst +++ b/gnu/llvm/llvm/docs/LinkTimeOptimization.rst @@ -249,6 +249,12 @@ symbols and getting the name and attributes of each symbol via: The attributes of a symbol include the alignment, visibility, and kind. +Tools working with object files on Darwin (e.g. lipo) may need to know properties like the CPU type: + +.. code-block:: c + + lto_module_get_macho_cputype(lto_module_t mod, unsigned int *out_cputype, unsigned int *out_cpusubtype) + ``lto_code_gen_t`` ------------------ diff --git a/gnu/llvm/llvm/docs/LoopTerminology.rst b/gnu/llvm/llvm/docs/LoopTerminology.rst index 991282e5051..fc461986cb5 100644 --- a/gnu/llvm/llvm/docs/LoopTerminology.rst +++ b/gnu/llvm/llvm/docs/LoopTerminology.rst @@ -43,6 +43,9 @@ Note that there are some important implications of this definition: * Any two loops are either fully disjoint (no intersecting blocks), or one must be a sub-loop of the other. +* Loops in a function form a forest. One implication of this fact + is that a loop either has no parent or a single parent. + A loop may have an arbitrary number of exits, both explicit (via control flow) and implicit (via throwing calls which transfer control out of the containing function). There is no special requirement on @@ -52,46 +55,46 @@ is branched to). They may have multiple predecessors, phis, etc... Key Terminology =============== -Header Block - The basic block which dominates all other blocks +**Header Block** - The basic block which dominates all other blocks contained within the loop. As such, it is the first one executed if the loop executes at all. Note that a block can be the header of two separate loops at the same time, but only if one is a sub-loop of the other. -Exiting Block - A basic block contained within a given loop which has +**Exiting Block** - A basic block contained within a given loop which has at least one successor outside of the loop and one successor inside the loop. (The latter is a consequence of the block being contained within an SCC which is part of the loop.) That is, it has a successor which is an Exit Block. -Exit Block - A basic block outside of the associated loop which has a +**Exit Block** - A basic block outside of the associated loop which has a predecessor inside the loop. That is, it has a predecessor which is an Exiting Block. -Latch Block - A basic block within the loop whose successors include +**Latch Block** - A basic block within the loop whose successors include the header block of the loop. Thus, a latch is a source of backedge. A loop may have multiple latch blocks. A latch block may be either conditional or unconditional. -Backedge(s) - The edge(s) in the CFG from latch blocks to the header +**Backedge(s)** - The edge(s) in the CFG from latch blocks to the header block. Note that there can be multiple such edges, and even multiple such edges leaving a single latch block. -Loop Predecessor - The predecessor blocks of the loop header which +**Loop Predecessor** - The predecessor blocks of the loop header which are not contained by the loop itself. These are the only blocks through which execution can enter the loop. When used in the singular form implies that there is only one such unique block. -Preheader Block - A preheader is a (singular) loop predecessor which +**Preheader Block** - A preheader is a (singular) loop predecessor which ends in an unconditional transfer of control to the loop header. Note that not all loops have such blocks. -Backedge Taken Count - The number of times the backedge will execute +**Backedge Taken Count** - The number of times the backedge will execute before some interesting event happens. Commonly used without qualification of the event as a shorthand for when some exiting block branches to some exit block. May be zero, or not statically computable. -Iteration Count - The number of times the header will execute before +**Iteration Count** - The number of times the header will execute before some interesting event happens. Commonly used without qualification to refer to the iteration count at which the loop exits. Will always be one greater than the backedge taken count. *Warning*: Preceding @@ -138,18 +141,407 @@ are important for working successfully with this interface. reachability of the loop. +.. _loop-terminology-loop-simplify: + Loop Simplify Form ================== -TBD +The Loop Simplify Form is a canonical form that makes +several analyses and transformations simpler and more effective. +It is ensured by the LoopSimplify +(:ref:`-loop-simplify `) pass and is automatically +added by the pass managers when scheduling a LoopPass. +This pass is implemented in +`LoopSimplify.h `_. +When it is successful, the loop has: + +* A preheader. +* A single backedge (which implies that there is a single latch). +* Dedicated exits. That is, no exit block for the loop + has a predecessor that is outside the loop. This implies + that all exit blocks are dominated by the loop header. +.. _loop-terminology-lcssa: Loop Closed SSA (LCSSA) ======================= -TBD +A program is in Loop Closed SSA Form if it is in SSA form +and all values that are defined in a loop are used only inside +this loop. +Programs written in LLVM IR are always in SSA form but not necessarily +in LCSSA. To achieve the latter, single entry PHI nodes are inserted +at the end of the loops for all values that are live +across the loop boundary [#lcssa-construction]_. +In particular, consider the following loop: + +.. code-block:: C + + c = ...; + for (...) { + if (c) + X1 = ... + else + X2 = ... + X3 = phi(X1, X2); // X3 defined + } + + ... = X3 + 4; // X3 used, i.e. live + // outside the loop + +In the inner loop, the X3 is defined inside the loop, but used +outside of it. In Loop Closed SSA form, this would be represented as follows: + +.. code-block:: C + + c = ...; + for (...) { + if (c) + X1 = ... + else + X2 = ... + X3 = phi(X1, X2); + } + X4 = phi(X3); + + ... = X4 + 4; + +This is still valid LLVM; the extra phi nodes are purely redundant, +but all LoopPass'es are required to preserve them. +This form is ensured by the LCSSA (:ref:`-lcssa `) +pass and is added automatically by the LoopPassManager when +scheduling a LoopPass. +After the loop optimizations are done, these extra phi nodes +will be deleted by :ref:`-instcombine `. + +The major benefit of this transformation is that it makes many other +loop optimizations simpler. + +First of all, a simple observation is that if one needs to see all +the outside users, they can just iterate over all the (loop closing) +PHI nodes in the exit blocks (the alternative would be to +scan the def-use chain [#def-use-chain]_ of all instructions in the loop). + +Then, consider for example +:ref:`-loop-unswitch ` ing the loop above. +Because it is in LCSSA form, we know that any value defined inside of +the loop will be used either only inside the loop or in a loop closing +PHI node. In this case, the only loop closing PHI node is X4. +This means that we can just copy the loop and change the X4 +accordingly, like so: + +.. code-block:: C + + c = ...; + if (c) { + for (...) { + if (true) + X1 = ... + else + X2 = ... + X3 = phi(X1, X2); + } + } else { + for (...) { + if (false) + X1' = ... + else + X2' = ... + X3' = phi(X1', X2'); + } + } + X4 = phi(X3, X3') + +Now, all uses of X4 will get the updated value (in general, +if a loop is in LCSSA form, in any loop transformation, +we only need to update the loop closing PHI nodes for the changes +to take effect). If we did not have Loop Closed SSA form, it means that X3 could +possibly be used outside the loop. So, we would have to introduce the +X4 (which is the new X3) and replace all uses of X3 with that. +However, we should note that because LLVM keeps a def-use chain +[#def-use-chain]_ for each Value, we wouldn't need +to perform data-flow analysis to find and replace all the uses +(there is even a utility function, replaceAllUsesWith(), +that performs this transformation by iterating the def-use chain). + +Another important advantage is that the behavior of all uses +of an induction variable is the same. Without this, you need to +distinguish the case when the variable is used outside of +the loop it is defined in, for example: + +.. code-block:: C + + for (i = 0; i < 100; i++) { + for (j = 0; j < 100; j++) { + k = i + j; + use(k); // use 1 + } + use(k); // use 2 + } + +Looking from the outer loop with the normal SSA form, the first use of k +is not well-behaved, while the second one is an induction variable with +base 100 and step 1. Although, in practice, and in the LLVM context, +such cases can be handled effectively by SCEV. Scalar Evolution +(:ref:`scalar-evolution `) or SCEV, is a +(analysis) pass that analyzes and categorizes the evolution of scalar +expressions in loops. + +In general, it's easier to use SCEV in loops that are in LCSSA form. +The evolution of a scalar (loop-variant) expression that +SCEV can analyze is, by definition, relative to a loop. +An expression is represented in LLVM by an +`llvm::Instruction `. +If the expression is inside two (or more) loops (which can only +happen if the loops are nested, like in the example above) and you want +to get an analysis of its evolution (from SCEV), +you have to also specify relative to what Loop you want it. +Specifically, you have to use +`getSCEVAtScope() `_. + +However, if all loops are in LCSSA form, each expression is actually +represented by two different llvm::Instructions. One inside the loop +and one outside, which is the loop-closing PHI node and represents +the value of the expression after the last iteration (effectively, +we break each loop-variant expression into two expressions and so, every +expression is at most in one loop). You can now just use +`getSCEV() `_. +and which of these two llvm::Instructions you pass to it disambiguates +the context / scope / relative loop. + +.. rubric:: Footnotes + +.. [#lcssa-construction] To insert these loop-closing PHI nodes, one has to + (re-)compute dominance frontiers (if the loop has multiple exits). + +.. [#def-use-chain] A property of SSA is that there exists a def-use chain + for each definition, which is a list of all the uses of this definition. + LLVM implements this property by keeping a list of all the uses of a Value + in an internal data structure. "More Canonical" Loops ====================== -TBD +.. _loop-terminology-loop-rotate: + +Rotated Loops +------------- + +Loops are rotated by the LoopRotate (:ref:`loop-rotate `) +pass, which converts loops into do/while style loops and is +implemented in +`LoopRotation.h `_. Example: + +.. code-block:: C + + void test(int n) { + for (int i = 0; i < n; i += 1) + // Loop body + } + +is transformed to: + +.. code-block:: C + + void test(int n) { + int i = 0; + do { + // Loop body + i += 1; + } while (i < n); + } + +**Warning**: This transformation is valid only if the compiler +can prove that the loop body will be executed at least once. Otherwise, +it has to insert a guard which will test it at runtime. In the example +above, that would be: + +.. code-block:: C + + void test(int n) { + int i = 0; + if (n > 0) { + do { + // Loop body + i += 1; + } while (i < n); + } + } + +It's important to understand the effect of loop rotation +at the LLVM IR level. We follow with the previous examples +in LLVM IR while also providing a graphical representation +of the control-flow graphs (CFG). You can get the same graphical +results by utilizing the :ref:`view-cfg ` pass. + +The initial **for** loop could be translated to: + +.. code-block:: none + + define void @test(i32 %n) { + entry: + br label %for.header + + for.header: + %i = phi i32 [ 0, %entry ], [ %i.next, %latch ] + %cond = icmp slt i32 %i, %n + br i1 %cond, label %body, label %exit + + body: + ; Loop body + br label %latch + + latch: + %i.next = add nsw i32 %i, 1 + br label %for.header + + exit: + ret void + } + +.. image:: ./loop-terminology-initial-loop.png + :width: 400 px + +Before we explain how LoopRotate will actually +transform this loop, here's how we could convert +it (by hand) to a do-while style loop. + +.. code-block:: none + + define void @test(i32 %n) { + entry: + br label %body + + body: + %i = phi i32 [ 0, %entry ], [ %i.next, %latch ] + ; Loop body + br label %latch + + latch: + %i.next = add nsw i32 %i, 1 + %cond = icmp slt i32 %i.next, %n + br i1 %cond, label %body, label %exit + + exit: + ret void + } + +.. image:: ./loop-terminology-rotated-loop.png + :width: 400 px + +Note two things: + +* The condition check was moved to the "bottom" of the loop, i.e. + the latch. This is something that LoopRotate does by copying the header + of the loop to the latch. +* The compiler in this case can't deduce that the loop will + definitely execute at least once so the above transformation + is not valid. As mentioned above, a guard has to be inserted, + which is something that LoopRotate will do. + +This is how LoopRotate transforms this loop: + +.. code-block:: none + + define void @test(i32 %n) { + entry: + %guard_cond = icmp slt i32 0, %n + br i1 %guard_cond, label %loop.preheader, label %exit + + loop.preheader: + br label %body + + body: + %i2 = phi i32 [ 0, %loop.preheader ], [ %i.next, %latch ] + br label %latch + + latch: + %i.next = add nsw i32 %i2, 1 + %cond = icmp slt i32 %i.next, %n + br i1 %cond, label %body, label %loop.exit + + loop.exit: + br label %exit + + exit: + ret void + } + +.. image:: ./loop-terminology-guarded-loop.png + :width: 500 px + +The result is a little bit more complicated than we may expect +because LoopRotate ensures that the loop is in +:ref:`Loop Simplify Form ` +after rotation. +In this case, it inserted the %loop.preheader basic block so +that the loop has a preheader and it introduced the %loop.exit +basic block so that the loop has dedicated exits +(otherwise, %exit would be jumped from both %latch and %entry, +but %entry is not contained in the loop). +Note that a loop has to be in Loop Simplify Form beforehand +too for LoopRotate to be applied successfully. + +The main advantage of this form is that it allows hoisting +invariant instructions, especially loads, into the preheader. +That could be done in non-rotated loops as well but with +some disadvantages. Let's illustrate them with an example: + +.. code-block:: C + + for (int i = 0; i < n; ++i) { + auto v = *p; + use(v); + } + +We assume that loading from p is invariant and use(v) is some +statement that uses v. +If we wanted to execute the load only once we could move it +"out" of the loop body, resulting in this: + +.. code-block:: C + + auto v = *p; + for (int i = 0; i < n; ++i) { + use(v); + } + +However, now, in the case that n <= 0, in the initial form, +the loop body would never execute, and so, the load would +never execute. This is a problem mainly for semantic reasons. +Consider the case in which n <= 0 and loading from p is invalid. +In the initial program there would be no error. However, with this +transformation we would introduce one, effectively breaking +the initial semantics. + +To avoid both of these problems, we can insert a guard: + +.. code-block:: C + + if (n > 0) { // loop guard + auto v = *p; + for (int i = 0; i < n; ++i) { + use(v); + } + } + +This is certainly better but it could be improved slightly. Notice +that the check for whether n is bigger than 0 is executed twice (and +n does not change in between). Once when we check the guard condition +and once in the first execution of the loop. To avoid that, we could +do an unconditional first execution and insert the loop condition +in the end. This effectively means transforming the loop into a do-while loop: + +.. code-block:: C + + if (0 < n) { + auto v = *p; + do { + use(v); + ++i; + } while (i < n); + } + +Note that LoopRotate does not generally do such +hoisting. Rather, it is an enabling transformation for other +passes like Loop-Invariant Code Motion (:ref:`-licm `). diff --git a/gnu/llvm/llvm/docs/MarkdownQuickstartTemplate.md b/gnu/llvm/llvm/docs/MarkdownQuickstartTemplate.md index 734152188e5..1ed9f2f80f9 100644 --- a/gnu/llvm/llvm/docs/MarkdownQuickstartTemplate.md +++ b/gnu/llvm/llvm/docs/MarkdownQuickstartTemplate.md @@ -64,7 +64,7 @@ structure. ### Example Subsection -Make a link [like this](http://llvm.org/). There is also a more +Make a link [like this](https://llvm.org/). There is also a more sophisticated syntax which [can be more readable] for longer links since it disrupts the flow less. You can put the `[link name]: ` block pretty much anywhere later in the document. diff --git a/gnu/llvm/llvm/docs/MarkedUpDisassembly.rst b/gnu/llvm/llvm/docs/MarkedUpDisassembly.rst index df8befe45cd..05feee158e1 100644 --- a/gnu/llvm/llvm/docs/MarkedUpDisassembly.rst +++ b/gnu/llvm/llvm/docs/MarkedUpDisassembly.rst @@ -41,7 +41,7 @@ Instruction Annotations Contextual markups ------------------ -Annoated assembly display will supply contextual markup to help clients more +Annotated assembly display will supply contextual markup to help clients more efficiently implement things like pretty printers. Most markup will be target independent, so clients can effectively provide good display without any target specific knowledge. diff --git a/gnu/llvm/llvm/docs/MemTagSanitizer.rst b/gnu/llvm/llvm/docs/MemTagSanitizer.rst index a27370368b4..62efbfb041c 100644 --- a/gnu/llvm/llvm/docs/MemTagSanitizer.rst +++ b/gnu/llvm/llvm/docs/MemTagSanitizer.rst @@ -13,7 +13,7 @@ functionality is planned but not implemented. Hardware capable of running MemTagSanitizer does not exist as of Oct 2019. MemTagSanitizer is a fast memory error detector and **a code hardening -tool** based on ARMv9 `Memory Tagging Extension`_. It +tool** based on the Armv8.5-A `Memory Tagging Extension`_. It detects a similar class of errors as `AddressSanitizer`_ or `HardwareAssistedAddressSanitizer`_, but with **much** lower overhead. @@ -37,7 +37,7 @@ Implementation ============== See `HardwareAssistedAddressSanitizer`_ for a general overview of a -tag-based approach to memory safety. MemTagSanitizer followes a +tag-based approach to memory safety. MemTagSanitizer follows a similar implementation strategy, but with the tag storage (shadow) provided by the hardware. diff --git a/gnu/llvm/llvm/docs/MemorySSA.rst b/gnu/llvm/llvm/docs/MemorySSA.rst index 1669117fcf5..b448aa10f6a 100644 --- a/gnu/llvm/llvm/docs/MemorySSA.rst +++ b/gnu/llvm/llvm/docs/MemorySSA.rst @@ -14,20 +14,22 @@ interactions between various memory operations. Its goal is to replace unless you're very careful, use of ``MemoryDependenceAnalysis`` can easily result in quadratic-time algorithms in LLVM. Additionally, ``MemorySSA`` doesn't have as many arbitrary limits as ``MemoryDependenceAnalysis``, so you should get -better results, too. +better results, too. One common use of ``MemorySSA`` is to quickly find out +that something definitely cannot happen (for example, reason that a hoist +out of a loop can't happen). At a high level, one of the goals of ``MemorySSA`` is to provide an SSA based form for memory, complete with def-use and use-def chains, which enables users to quickly find may-def and may-uses of memory operations. It can also be thought of as a way to cheaply give versions to the complete -state of heap memory, and associate memory operations with those versions. +state of memory, and associate memory operations with those versions. This document goes over how ``MemorySSA`` is structured, and some basic intuition on how ``MemorySSA`` works. A paper on MemorySSA (with notes about how it's implemented in GCC) `can be found here `_. Though, it's -relatively out-of-date; the paper references multiple heap partitions, but GCC +relatively out-of-date; the paper references multiple memory partitions, but GCC eventually swapped to just using one, like we now have in LLVM. Like GCC's, LLVM's MemorySSA is intraprocedural. @@ -41,9 +43,30 @@ structure that maps ``Instruction``\ s to ``MemoryAccess``\ es, which are Each ``MemoryAccess`` can be one of three types: +- ``MemoryDef`` - ``MemoryPhi`` - ``MemoryUse`` -- ``MemoryDef`` + +``MemoryDef``\ s are operations which may either modify memory, or which +introduce some kind of ordering constraints. Examples of ``MemoryDef``\ s +include ``store``\ s, function calls, ``load``\ s with ``acquire`` (or higher) +ordering, volatile operations, memory fences, etc. A ``MemoryDef`` +always introduces a new version of the entire memory and is linked with a single +``MemoryDef/MemoryPhi`` which is the version of memory that the new +version is based on. This implies that there is a *single* +``Def`` chain that connects all the ``Def``\ s, either directly +or indireclty. For example in: + +.. code-block:: llvm + + b = MemoryDef(a) + c = MemoryDef(b) + d = MemoryDef(c) + +``d`` is connected directly with ``c`` and indirectly with ``b``. +This means that ``d`` potentially clobbers (see below) ``c`` *or* +``b`` *or* both. This in turn implies that without the use of `The walker`_, +initially every ``MemoryDef`` clobbers every other ``MemoryDef``. ``MemoryPhi``\ s are ``PhiNode``\ s, but for memory operations. If at any point we have two (or more) ``MemoryDef``\ s that could flow into a @@ -61,11 +84,6 @@ reach a phi node may or may not clobber a given variable). ``MemoryUse``\ s are operations which use but don't modify memory. An example of a ``MemoryUse`` is a ``load``, or a ``readonly`` function call. -``MemoryDef``\ s are operations which may either modify memory, or which -introduce some kind of ordering constraints. Examples of ``MemoryDef``\ s -include ``store``\ s, function calls, ``load``\ s with ``acquire`` (or higher) -ordering, volatile operations, memory fences, etc. - Every function that exists has a special ``MemoryDef`` called ``liveOnEntry``. It dominates every ``MemoryAccess`` in the function that ``MemorySSA`` is being run on, and implies that we've hit the top of the function. It's the only @@ -75,14 +93,28 @@ defined before the function begins. An example of all of this overlaid on LLVM IR (obtained by running ``opt -passes='print' -disable-output`` on an ``.ll`` file) is below. When -viewing this example, it may be helpful to view it in terms of clobbers. The -operands of a given ``MemoryAccess`` are all (potential) clobbers of said -MemoryAccess, and the value produced by a ``MemoryAccess`` can act as a clobber -for other ``MemoryAccess``\ es. Another useful way of looking at it is in -terms of heap versions. In that view, operands of a given -``MemoryAccess`` are the version of the heap before the operation, and -if the access produces a value, the value is the new version of the heap -after the operation. +viewing this example, it may be helpful to view it in terms of clobbers. +The operands of a given ``MemoryAccess`` are all (potential) clobbers of said +``MemoryAccess``, and the value produced by a ``MemoryAccess`` can act as a clobber +for other ``MemoryAccess``\ es. + +If a ``MemoryAccess`` is a *clobber* of another, it means that these two +``MemoryAccess``\ es may access the same memory. For example, ``x = MemoryDef(y)`` +means that ``x`` potentially modifies memory that ``y`` modifies/constrains +(or has modified / constrained). +In the same manner, ``a = MemoryPhi({BB1,b},{BB2,c})`` means that +anyone that uses ``a`` is accessing memory potentially modified / constrained +by either ``b`` or ``c`` (or both). And finally, ``MemoryUse(x)`` means +that this use accesses memory that ``x`` has modified / constrained +(as an example, think that if ``x = MemoryDef(...)`` +and ``MemoryUse(x)`` are in the same loop, the use can't +be hoisted outside alone). + +Another useful way of looking at it is in terms of memory versions. +In that view, operands of a given ``MemoryAccess`` are the version +of the entire memory before the operation, and if the access produces +a value (i.e. ``MemoryDef/MemoryPhi``), +the value is the new version of the memory after the operation. .. code-block:: llvm @@ -96,7 +128,7 @@ after the operation. br label %while.cond while.cond: - ; 6 = MemoryPhi({%0,1},{if.end,4}) + ; 6 = MemoryPhi({entry,1},{if.end,4}) br i1 undef, label %if.then, label %if.else if.then: @@ -148,8 +180,8 @@ Going from the top down: reaching definition is ``5``. - ``MemoryUse(1)`` notes that ``load i8, i8* %p3`` is just a user of memory, and the last thing that could clobber this use is above ``while.cond`` (e.g. - the store to ``%p3``). In heap versioning parlance, it really only depends on - the heap version 1, and is unaffected by the new heap versions generated since + the store to ``%p3``). In memory versioning parlance, it really only depends on + the memory version 1, and is unaffected by the new memory versions generated since then. As an aside, ``MemoryAccess`` is a ``Value`` mostly for convenience; it's not @@ -222,7 +254,7 @@ second ``MemoryUse`` in ``if.end`` has an operand of ``1``, which is a value numbering, etc, faster and easier. It is not possible to optimize ``MemoryDef`` in the same way, as we -restrict ``MemorySSA`` to one heap variable and, thus, one Phi node +restrict ``MemorySSA`` to one memory variable and, thus, one Phi node per block. @@ -320,14 +352,14 @@ Precision ``MemorySSA`` in LLVM deliberately trades off precision for speed. Let us think about memory variables as if they were disjoint partitions of the -heap (that is, if you have one variable, as above, it represents the entire -heap, and if you have multiple variables, each one represents some -disjoint portion of the heap) +memory (that is, if you have one variable, as above, it represents the entire +memory, and if you have multiple variables, each one represents some +disjoint portion of the memory) First, because alias analysis results conflict with each other, and each result may be what an analysis wants (IE TBAA may say no-alias, and something else may say must-alias), it is -not possible to partition the heap the way every optimization wants. +not possible to partition the memory the way every optimization wants. Second, some alias analysis results are not transitive (IE A noalias B, and B noalias C, does not mean A noalias C), so it is not possible to come up with a precise partitioning in all cases without variables to diff --git a/gnu/llvm/llvm/docs/MergeFunctions.rst b/gnu/llvm/llvm/docs/MergeFunctions.rst index 7c51adac681..13294129538 100644 --- a/gnu/llvm/llvm/docs/MergeFunctions.rst +++ b/gnu/llvm/llvm/docs/MergeFunctions.rst @@ -39,16 +39,16 @@ LLVM code fundamentals. In this article, we assume the reader is familiar with `Single Static Assignment `_ concept and has an understanding of -`IR structure `_. +`IR structure `_. We will use terms such as -"`module `_", -"`function `_", +"`module `_", +"`function `_", "`basic block `_", -"`user `_", -"`value `_", +"`user `_", +"`value `_", "`instruction -`_". +`_". As a good starting point, the Kaleidoscope tutorial can be used: @@ -99,8 +99,8 @@ and a ``void*`` as equal. This is just an example; more possible details are described a bit below. As another example, the reader may imagine two more functions. The first -function performs a multiplication on 2, while the second one performs an -arithmetic right shift on 1. +function performs a multiplication by 2, while the second one performs an +logical left shift by 1. Possible solutions ^^^^^^^^^^^^^^^^^^ diff --git a/gnu/llvm/llvm/docs/ORCv2.rst b/gnu/llvm/llvm/docs/ORCv2.rst index 049dd8b348c..0396fb0ad81 100644 --- a/gnu/llvm/llvm/docs/ORCv2.rst +++ b/gnu/llvm/llvm/docs/ORCv2.rst @@ -10,7 +10,7 @@ Introduction This document aims to provide a high-level overview of the design and implementation of the ORC JIT APIs. Except where otherwise stated, all -discussion applies to the design of the APIs as of LLVM version 9 (ORCv2). +discussion applies to the design of the APIs as of LLVM Version 10 (ORCv2). Use-cases ========= @@ -39,41 +39,42 @@ Features ORC provides the following features: -- *JIT-linking* links relocatable object files (COFF, ELF, MachO) [1]_ into a - target process at runtime. The target process may be the same process that - contains the JIT session object and jit-linker, or may be another process +*JIT-linking* + ORC provides APIs to link relocatable object files (COFF, ELF, MachO) [1]_ + into a target process at runtime. The target process may be the same process + that contains the JIT session object and jit-linker, or may be another process (even one running on a different machine or architecture) that communicates with the JIT via RPC. -- *LLVM IR compilation*, which is provided by off the shelf components - (IRCompileLayer, SimpleCompiler, ConcurrentIRCompiler) that make it easy to - add LLVM IR to a JIT'd process. - -- *Eager and lazy compilation*. By default, ORC will compile symbols as soon as - they are looked up in the JIT session object (``ExecutionSession``). Compiling - eagerly by default makes it easy to use ORC as a simple in-memory compiler for - an existing JIT. ORC also provides a simple mechanism, lazy-reexports, for - deferring compilation until first call. - -- *Support for custom compilers and program representations*. Clients can supply - custom compilers for each symbol that they define in their JIT session. ORC - will run the user-supplied compiler when the a definition of a symbol is - needed. ORC is actually fully language agnostic: LLVM IR is not treated - specially, and is supported via the same wrapper mechanism (the +*LLVM IR compilation* + ORC provides off the shelf components (IRCompileLayer, SimpleCompiler, + ConcurrentIRCompiler) that make it easy to add LLVM IR to a JIT'd process. + +*Eager and lazy compilation* + By default, ORC will compile symbols as soon as they are looked up in the JIT + session object (``ExecutionSession``). Compiling eagerly by default makes it + easy to use ORC as a simple in-memory compiler within an existing JIT + infrastructure. However ORC also provides support for lazy compilation via + lazy-reexports (see :ref:`Laziness`). + +*Support for Custom Compilers and Program Representations* + Clients can supply custom compilers for each symbol that they define in their + JIT session. ORC will run the user-supplied compiler when the a definition of + a symbol is needed. ORC is actually fully language agnostic: LLVM IR is not + treated specially, and is supported via the same wrapper mechanism (the ``MaterializationUnit`` class) that is used for custom compilers. -- *Concurrent JIT'd code* and *concurrent compilation*. JIT'd code may spawn - multiple threads, and may re-enter the JIT (e.g. for lazy compilation) - concurrently from multiple threads. The ORC APIs also support running multiple - compilers concurrently, and provides off-the-shelf infrastructure to track - dependencies on running compiles (e.g. to ensure that we never call into code - until it is safe to do so, even if that involves waiting on multiple - compiles). +*Concurrent JIT'd code* and *Concurrent Compilation* + JIT'd code may spawn multiple threads, and may re-enter the JIT (e.g. for lazy + compilation) concurrently from multiple threads. The ORC APIs also support + running multiple compilers concurrently. Built-in dependency tracking (via the + JIT linker) ensures that ORC does not release code for execution until it is + safe to call. -- *Orthogonality* and *composability*: Each of the features above can be used (or - not) independently. It is possible to put ORC components together to make a - non-lazy, in-process, single threaded JIT or a lazy, out-of-process, - concurrent JIT, or anything in between. +*Orthogonality* and *Composability* + Each of the features above can be used (or not) independently. It is possible + to put ORC components together to make a non-lazy, in-process, single threaded + JIT or a lazy, out-of-process, concurrent JIT, or anything in between. LLJIT and LLLazyJIT =================== @@ -123,7 +124,7 @@ module ``M`` loaded on a ThreadSafeContext ``Ctx``: // Call into JIT'd code. Entry(); -The builder clasess provide a number of configuration options that can be +The builder classes provide a number of configuration options that can be specified before the JIT instance is constructed. For example: .. code-block:: c++ @@ -189,16 +190,17 @@ checking omitted for brevity) as: CXXLayer.add(LibB, MemoryBuffer::getFile("b1.cpp")); CXXLayer.add(LibB, MemoryBuffer::getFile("b2.cpp")); - // Specify the search order for the main JITDylib. This is equivalent to a - // "links against" relationship in a command-line link. - ES.getMainJITDylib().setSearchOrder({{&LibA, false}, {&LibB, false}}); - CXXLayer.add(ES.getMainJITDylib(), MemoryBuffer::getFile("main.cpp")); + // Create and specify the search order for the main JITDylib. This is + // equivalent to a "links against" relationship in a command-line link. + auto &MainJD = ES.createJITDylib("main"); + MainJD.setSearchOrder({{&LibA, false}, {&LibB, false}}); + CXXLayer.add(MainJD, MemoryBuffer::getFile("main.cpp")); // Look up the JIT'd main, cast it to a function pointer, then call it. - auto MainSym = ExitOnErr(ES.lookup({&ES.getMainJITDylib()}, "main")); + auto MainSym = ExitOnErr(ES.lookup({&MainJD}, "main")); auto *Main = (int(*)(int, char*[]))MainSym.getAddress(); -v int Result = Main(...); + int Result = Main(...); This example tells us nothing about *how* or *when* compilation will happen. That will depend on the implementation of the hypothetical CXXCompilingLayer. @@ -288,26 +290,167 @@ of them, but Layer authors will use them: that must be materialized and provides a way to notify the JITDylib once they are either successfully materialized or a failure occurs. -Handy utilities -=============== +Absolute Symbols, Aliases, and Reexports +======================================== + +ORC makes it easy to define symbols with absolute addresses, or symbols that +are simply aliases of other symbols: + +Absolute Symbols +---------------- + +Absolute symbols are symbols that map directly to addresses without requiring +further materialization, for example: "foo" = 0x1234. One use case for +absolute symbols is allowing resolution of process symbols. E.g. + +.. code-block: c++ + + JD.define(absoluteSymbols(SymbolMap({ + { Mangle("printf"), + { pointerToJITTargetAddress(&printf), + JITSymbolFlags::Callable } } + }); + +With this mapping established code added to the JIT can refer to printf +symbolically rather than requiring the address of printf to be "baked in". +This in turn allows cached versions of the JIT'd code (e.g. compiled objects) +to be re-used across JIT sessions as the JIT'd code no longer changes, only the +absolute symbol definition does. + +For process and library symbols the DynamicLibrarySearchGenerator utility (See +:ref:`How to Add Process and Library Symbols to JITDylibs +`) can be used to automatically build absolute +symbol mappings for you. However the absoluteSymbols function is still useful +for making non-global objects in your JIT visible to JIT'd code. For example, +imagine that your JIT standard library needs access to your JIT object to make +some calls. We could bake the address of your object into the library, but then +it would need to be recompiled for each session: + +.. code-block: c++ + + // From standard library for JIT'd code: + + class MyJIT { + public: + void log(const char *Msg); + }; + + void log(const char *Msg) { ((MyJIT*)0x1234)->log(Msg); } + +We can turn this into a symbolic reference in the JIT standard library: + +.. code-block: c++ + + extern MyJIT *__MyJITInstance; + + void log(const char *Msg) { __MyJITInstance->log(Msg); } + +And then make our JIT object visible to the JIT standard library with an +absolute symbol definition when the JIT is started: + +.. code-block: c++ + + MyJIT J = ...; + + auto &JITStdLibJD = ... ; + + JITStdLibJD.define(absoluteSymbols(SymbolMap({ + { Mangle("__MyJITInstance"), + { pointerToJITTargetAddress(&J), JITSymbolFlags() } } + }); + +Aliases and Reexports +--------------------- -TBD: absolute symbols, aliases, off-the-shelf layers. +Aliases and reexports allow you to define new symbols that map to existing +symbols. This can be useful for changing linkage relationships between symbols +across sessions without having to recompile code. For example, imagine that +JIT'd code has access to a log function, ``void log(const char*)`` for which +there are two implementations in the JIT standard library: ``log_fast`` and +``log_detailed``. Your JIT can choose which one of these definitions will be +used when the ``log`` symbol is referenced by setting up an alias at JIT startup +time: + +.. code-block: c++ + + auto &JITStdLibJD = ... ; + + auto LogImplementationSymbol = + Verbose ? Mangle("log_detailed") : Mangle("log_fast"); + + JITStdLibJD.define( + symbolAliases(SymbolAliasMap({ + { Mangle("log"), + { LogImplementationSymbol + JITSymbolFlags::Exported | JITSymbolFlags::Callable } } + }); + +The ``symbolAliases`` function allows you to define aliases within a single +JITDylib. The ``reexports`` function provides the same functionality, but +operates across JITDylib boundaries. E.g. + +.. code-block: c++ + + auto &JD1 = ... ; + auto &JD2 = ... ; + + // Make 'bar' in JD2 an alias for 'foo' from JD1. + JD2.define( + reexports(JD1, SymbolAliasMap({ + { Mangle("bar"), { Mangle("foo"), JITSymbolFlags::Exported } } + }); + +The reexports utility can be handy for composing a single JITDylib interface by +re-exporting symbols from several other JITDylibs. + +.. _Laziness: Laziness ======== -Laziness in ORC is provided by a utility called "lazy-reexports". The aim of -this utility is to re-use the synchronization provided by the symbol lookup -mechanism to make it safe to lazily compile functions, even if calls to the -stub occur simultaneously on multiple threads of JIT'd code. It does this by -reducing lazy compilation to symbol lookup: The lazy stub performs a lookup of -its underlying definition on first call, updating the function body pointer -once the definition is available. If additional calls arrive on other threads -while compilation is ongoing they will be safely blocked by the normal lookup -synchronization guarantee (no result until the result is safe) and can also -proceed as soon as compilation completes. +Laziness in ORC is provided by a utility called "lazy reexports". A lazy +reexport is similar to a regular reexport or alias: It provides a new name for +an existing symbol. Unlike regular reexports however, lookups of lazy reexports +do not trigger immediate materialization of the reexported symbol. Instead, they +only trigger materialization of a function stub. This function stub is +initialized to point at a *lazy call-through*, which provides reentry into the +JIT. If the stub is called at runtime then the lazy call-through will look up +the reexported symbol (triggering materialization for it if necessary), update +the stub (to call directly to the reexported symbol on subsequent calls), and +then return via the reexported symbol. By re-using the existing symbol lookup +mechanism, lazy reexports inherit the same concurrency guarantees: calls to lazy +reexports can be made from multiple threads concurrently, and the reexported +symbol can be any state of compilation (uncompiled, already in the process of +being compiled, or already compiled) and the call will succeed. This allows +laziness to be safely mixed with features like remote compilation, concurrent +compilation, concurrent JIT'd code, and speculative compilation. + +There is one other key difference between regular reexports and lazy reexports +that some clients must be aware of: The address of a lazy reexport will be +*different* from the address of the reexported symbol (whereas a regular +reexport is guaranteed to have the same address as the reexported symbol). +Clients who care about pointer equality will generally want to use the address +of the reexport as the canonical address of the reexported symbol. This will +allow the address to be taken without forcing materialization of the reexport. + +Usage example: + +If JITDylib ``JD`` contains definitions for symbols ``foo_body`` and +``bar_body``, we can create lazy entry points ``Foo`` and ``Bar`` in JITDylib +``JD2`` by calling: + +.. code-block:: c++ -TBD: Usage example. + auto ReexportFlags = JITSymbolFlags::Exported | JITSymbolFlags::Callable; + JD2.define( + lazyReexports(CallThroughMgr, StubsMgr, JD, + SymbolAliasMap({ + { Mangle("foo"), { Mangle("foo_body"), ReexportedFlags } }, + { Mangle("bar"), { Mangle("bar_body"), ReexportedFlags } } + })); + +A full example of how to use lazyReexports with the LLJIT class can be found at +``llvm_project/llvm/examples/LLJITExamples/LLJITWithLazyReexports``. Supporting Custom Compilers =========================== @@ -341,10 +484,11 @@ to be aware of: references are resolved, and symbol resolvers are no longer used. See the section `Design Overview`_ for more details. - Unless multiple JITDylibs are needed to model linkage relationsips, ORCv1 - clients should place all code in the main JITDylib (returned by - ``ExecutionSession::getMainJITDylib()``). MCJIT clients should use LLJIT - (see `LLJIT and LLLazyJIT`_). + Unless multiple JITDylibs are needed to model linkage relationships, ORCv1 + clients should place all code in a single JITDylib. + MCJIT clients should use LLJIT (see `LLJIT and LLLazyJIT`_), and can place + code in LLJIT's default created main JITDylib (See + ``LLJIT::getMainJITDylib()``). 2. All JIT stacks now need an ``ExecutionSession`` instance. ExecutionSession manages the string pool, error reporting, synchronization, and symbol @@ -381,7 +525,7 @@ How-tos ======= How to manage symbol strings -############################ +---------------------------- Symbol strings in ORC are uniqued to improve lookup performance, reduce memory overhead, and allow symbol names to function as efficient keys. To get the @@ -411,10 +555,10 @@ will perform both jobs for you: // ... // Portable IR-symbol-name lookup: - auto Sym = ES.lookup({&ES.getMainJITDylib()}, Mangle("main")); + auto Sym = ES.lookup({&MainJD}, Mangle("main")); How to create JITDylibs and set up linkage relationships -######################################################## +-------------------------------------------------------- In ORC, all symbol definitions reside in JITDylibs. JITDylibs are created by calling the ``ExecutionSession::createJITDylib`` method with a unique name: @@ -427,17 +571,8 @@ calling the ``ExecutionSession::createJITDylib`` method with a unique name: The JITDylib is owned by the ``ExecutionEngine`` instance and will be freed when it is destroyed. -A JITDylib representing the JIT main program is created by ExecutionEngine by -default. A reference to it can be obtained by calling -``ExecutionSession::getMainJITDylib()``: - - .. code-block:: c++ - - ExecutionSession ES; - auto &MainJD = ES.getMainJITDylib(); - How to use ThreadSafeModule and ThreadSafeContext -################################################# +------------------------------------------------- ThreadSafeModule and ThreadSafeContext are wrappers around Modules and LLVMContexts respectively. A ThreadSafeModule is a pair of a @@ -523,8 +658,7 @@ constructs a new ThreadSafeContext value from a std::unique_ptr: for (const auto &IRPath : IRPaths) { auto Ctx = std::make_unique(); auto M = std::make_unique("M", *Ctx); - CompileLayer.add(ES.getMainJITDylib(), - ThreadSafeModule(std::move(M), std::move(Ctx))); + CompileLayer.add(MainJD, ThreadSafeModule(std::move(M), std::move(Ctx))); } Clients who plan to run single-threaded may choose to save memory by loading @@ -536,9 +670,11 @@ all modules on the same context: ThreadSafeContext TSCtx(std::make_unique()); for (const auto &IRPath : IRPaths) { ThreadSafeModule TSM(parsePath(IRPath, *TSCtx.getContext()), TSCtx); - CompileLayer.add(ES.getMainJITDylib(), ThreadSafeModule(std::move(TSM)); + CompileLayer.add(MainJD, ThreadSafeModule(std::move(TSM)); } +.. _ProcessAndLibrarySymbols: + How to Add Process and Library Symbols to the JITDylibs ======================================================= @@ -561,7 +697,7 @@ function: const DataLayout &DL = getDataLayout(); MangleAndInterner Mangle(ES, DL); - auto &JD = ES.getMainJITDylib(); + auto &JD = ES.createJITDylib("main"); JD.define( absoluteSymbols({ @@ -584,7 +720,7 @@ For example, to load the whole interface of a runtime library: .. code-block:: c++ const DataLayout &DL = getDataLayout(); - auto &JD = ES.getMainJITDylib(); + auto &JD = ES.createJITDylib("main"); JD.setGenerator(DynamicLibrarySearchGenerator::Load("/path/to/lib" DL.getGlobalPrefix())); @@ -593,29 +729,29 @@ For example, to load the whole interface of a runtime library: // at '/path/to/lib'. CompileLayer.add(JD, loadModule(...)); -Or, to expose a whitelisted set of symbols from the main process: +Or, to expose an allowed set of symbols from the main process: .. code-block:: c++ const DataLayout &DL = getDataLayout(); MangleAndInterner Mangle(ES, DL); - auto &JD = ES.getMainJITDylib(); + auto &JD = ES.createJITDylib("main"); - DenseSet Whitelist({ + DenseSet AllowList({ Mangle("puts"), Mangle("gets") }); // Use GetForCurrentProcess with a predicate function that checks the - // whitelist. + // allowed list. JD.setGenerator( DynamicLibrarySearchGenerator::GetForCurrentProcess( DL.getGlobalPrefix(), - [&](const SymbolStringPtr &S) { return Whitelist.count(S); })); + [&](const SymbolStringPtr &S) { return AllowList.count(S); })); // IR added to JD can now link against any symbols exported by the process - // and contained in the whitelist. + // and contained in the list. CompileLayer.add(JD, loadModule(...)); Future Features diff --git a/gnu/llvm/llvm/docs/Packaging.rst b/gnu/llvm/llvm/docs/Packaging.rst index 7c2dc956128..176e5b39122 100644 --- a/gnu/llvm/llvm/docs/Packaging.rst +++ b/gnu/llvm/llvm/docs/Packaging.rst @@ -38,7 +38,7 @@ versions of LLVM in parallel. The following configure flags are relevant: should turn it back on to let users debug their programs. ``--enable-optimized`` - (For svn checkouts) Builds LLVM with ``-O2`` and, by default, turns off + (For git checkouts) Builds LLVM with ``-O2`` and, by default, turns off debug symbols. Also available by setting ``ENABLE_OPTIMIZED=0|1`` in ``make``'s environment. This defaults to enabled when not in a checkout. diff --git a/gnu/llvm/llvm/docs/Passes.rst b/gnu/llvm/llvm/docs/Passes.rst index 7a90d189c99..9a6c6944b96 100644 --- a/gnu/llvm/llvm/docs/Passes.rst +++ b/gnu/llvm/llvm/docs/Passes.rst @@ -66,8 +66,8 @@ function. This is inspired and adapted from code by: Naveen Neelakantam, Francesco Spadini, and Wojciech Stryjewski. -``-basicaa``: Basic Alias Analysis (stateless AA impl) ------------------------------------------------------- +``-basic-aa``: Basic Alias Analysis (stateless AA impl) +------------------------------------------------------- A basic alias analysis pass that implements identities (two different globals cannot alias, etc), but does no stateful analysis. @@ -331,6 +331,8 @@ The ``RegionInfo`` pass detects single entry single exit regions in a function, where a region is defined as any subgraph that is connected to the remaining graph at only two spots. Furthermore, a hierarchical region tree is built. +.. _passes-scalar-evolution: + ``-scalar-evolution``: Scalar Evolution Analysis ------------------------------------------------ @@ -711,6 +713,8 @@ An example of when this can occur is code like this: In this case, the unconditional branch at the end of the first if can be revectored to the false side of the second if. +.. _passes-lcssa: + ``-lcssa``: Loop-Closed SSA Form Pass ------------------------------------- @@ -732,7 +736,8 @@ into the right code: This is still valid LLVM; the extra phi nodes are purely redundant, and will be trivially eliminated by ``InstCombine``. The major benefit of this transformation is that it makes many other loop optimizations, such as -``LoopUnswitch``\ ing, simpler. +``LoopUnswitch``\ ing, simpler. You can read more in the +:ref:`loop terminology section for the LCSSA form `. .. _passes-licm: @@ -798,17 +803,24 @@ accomplished by creating a new value to hold the initial value of the array access for the first iteration, and then creating a new GEP instruction in the loop to increment the value by the appropriate amount. +.. _passes-loop-rotate: + ``-loop-rotate``: Rotate Loops ------------------------------ -A simple loop rotation transformation. +A simple loop rotation transformation. A summary of it can be found in +:ref:`Loop Terminology for Rotated Loops `. + + +.. _passes-loop-simplify: ``-loop-simplify``: Canonicalize natural loops ---------------------------------------------- This pass performs several transformations to transform natural loops into a simpler form, which makes subsequent analyses and transformations simpler and -more effective. +more effective. A summary of it can be found in +:ref:`Loop Terminology, Loop Simplify Form `. Loop pre-header insertion guarantees that there is a single, non-critical entry edge from outside of the loop to the loop header. This simplifies a number of @@ -857,6 +869,8 @@ loops into one. When variables or loads can be shared in the new inner loop, thi can lead to significant performance improvements. It uses :ref:`Dependence Analysis ` for proving the transformations are safe. +.. _passes-loop-unswitch: + ``-loop-unswitch``: Unswitch loops ---------------------------------- @@ -1191,6 +1205,8 @@ performing optimizing transformations. Note that this does not provide full security verification (like Java), but instead just tries to ensure that code is well-formed. +.. _passes-view-cfg: + ``-view-cfg``: View CFG of function ----------------------------------- diff --git a/gnu/llvm/llvm/docs/Phabricator.rst b/gnu/llvm/llvm/docs/Phabricator.rst index 9f35af90689..2493d4eea17 100644 --- a/gnu/llvm/llvm/docs/Phabricator.rst +++ b/gnu/llvm/llvm/docs/Phabricator.rst @@ -48,7 +48,11 @@ Requesting a review via the web interface The tool to create and review patches in Phabricator is called *Differential*. -Note that you can upload patches created through git. +Note that you can upload patches created through git, but using `arc` on the +command line (see previous section) is prefered: it adds more metadata to +Phabricator which are useful for the pre-merge testing system and for +propagating attribution on commits when someone else has to push it for you. + To make reviews easier, please always include **as much context as possible** with your diff! Don't worry, Phabricator will automatically send a diff with a smaller context in the review @@ -59,7 +63,8 @@ To get a full diff, use one of the following commands (or just use Arcanist to upload your patch): * ``git show HEAD -U999999 > mypatch.patch`` -* ``git format-patch -U999999 @{u}`` +* ``git diff -U999999 @{u} > mypatch.patch`` +* ``git diff HEAD~1 -U999999 > mypatch.patch`` Before uploading your patch, please make sure it is formatted properly, as described in :ref:`How to Submit a Patch `. @@ -77,8 +82,7 @@ To upload a new patch: * Add reviewers (see below for advice). (If you set the Repository field correctly, llvm-commits or cfe-commits will be subscribed automatically; otherwise, you will have to manually subscribe them.) -* In the Repository field, enter the name of the project (LLVM, Clang, - etc.) to which the review should be sent. +* In the Repository field, enter "rG LLVM Github Monorepo". * Click *Save*. To submit an updated patch: @@ -169,7 +173,7 @@ yourself. Using the Arcanist tool can simplify the process of committing reviewed code as it will retrieve reviewers, the ``Differential Revision``, etc from the review and place it in the commit message. You may also commit an accepted change -directly using ``git llvm push``, per the section in the :ref:`getting started +directly using ``git push``, per the section in the :ref:`getting started guide `. Note that if you commit the change without using Arcanist and forget to add the @@ -178,6 +182,13 @@ that you close the review manually. In the web UI, under "Leap Into Action" put the git revision number in the Comment, set the Action to "Close Revision" and click Submit. Note the review must have been Accepted first. +Arcanist also adds extra tags that are mostly noise in the commit message, for +this reason avoid using `arc land` and push commits to master directly with git +after removing tags other than "Reviewed by" and "Differential Revision". +You can run `llvm/utils/git/arcfilter.sh` to clean the commit message of the +current "HEAD" commit automatically. You can also setup a git hook to catch this +for you (see `Getting Started `). + Committing someone's change from Phabricator ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -194,22 +205,23 @@ This will create a new branch called ``arcpatch-D`` based on the current ``master`` and will create a commit corresponding to ``D`` with a commit message derived from information in the Phabricator review. -Check you are happy with the commit message and amend it if necessary. Then, -make sure the commit is up-to-date, and commit it. This can be done by running -the following: +Check you are happy with the commit message and amend it if necessary. +For example, ensure the 'Author' property of the commit is set to the original author. +You can use a command to correct the author property if it is incorrect: :: - git pull --rebase origin master - git show # Ensure the patch looks correct. - ninja check-$whatever # Rerun the appropriate tests if needed. - git llvm push + git commit --amend --author="John Doe " -Or +Then, make sure the commit is up-to-date, and commit it. This can be done by running +the following: :: - arc land D + git pull --rebase https://github.com/llvm/llvm-project.git master + git show # Ensure the patch looks correct. + ninja check-$whatever # Rerun the appropriate tests if needed. + git push https://github.com/llvm/llvm-project.git HEAD:master Abandoning a change diff --git a/gnu/llvm/llvm/docs/ProgrammersManual.rst b/gnu/llvm/llvm/docs/ProgrammersManual.rst index a96f8b4b714..8d028a64b65 100644 --- a/gnu/llvm/llvm/docs/ProgrammersManual.rst +++ b/gnu/llvm/llvm/docs/ProgrammersManual.rst @@ -24,7 +24,7 @@ continuously growing source code that makes up the LLVM infrastructure. Note that this manual is not intended to serve as a replacement for reading the source code, so if you think there should be a method in one of these classes to do something, but it's not listed, check the source. Links to the `doxygen -`__ sources are provided to make this as easy as +`__ sources are provided to make this as easy as possible. The first section of this document describes general information that is useful @@ -32,7 +32,7 @@ to know when working in the LLVM infrastructure, and the second describes the Core LLVM classes. In the future this manual will be extended with information describing how to use extension libraries, such as dominator information, CFG traversal routines, and useful utilities like the ``InstVisitor`` (`doxygen -`__) template. +`__) template. .. _general: @@ -71,7 +71,7 @@ Here are some useful links: `_. #. `Bjarne Stroustrup's C++ Page - `_. + `_. #. `Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get the book) @@ -108,7 +108,7 @@ they don't have some drawbacks (primarily stemming from the fact that ``dynamic_cast<>`` only works on classes that have a v-table). Because they are used so often, you must know what they do and how they work. All of these templates are defined in the ``llvm/Support/Casting.h`` (`doxygen -`__) file (note that you very +`__) file (note that you very rarely have to include this file directly). ``isa<>``: @@ -231,7 +231,7 @@ and clients can call it using any one of: Similarly, APIs which need to return a string may return a ``StringRef`` instance, which can be used directly or converted to an ``std::string`` using the ``str`` member function. See ``llvm/ADT/StringRef.h`` (`doxygen -`__) for more +`__) for more information. You should rarely use the ``StringRef`` class directly, because it contains @@ -243,7 +243,7 @@ passed by value. The ``Twine`` class ^^^^^^^^^^^^^^^^^^^ -The ``Twine`` (`doxygen `__) +The ``Twine`` (`doxygen `__) class is an efficient way for APIs to accept concatenated strings. For example, a common LLVM paradigm is to name one instruction based on the name of another instruction with a suffix, for example: @@ -261,7 +261,7 @@ of strings until it is actually required, at which point it can be efficiently rendered directly into a character array. This avoids unnecessary heap allocation involved in constructing the temporary results of string concatenation. See ``llvm/ADT/Twine.h`` (`doxygen -`__) and :ref:`here ` +`__) and :ref:`here ` for more information. As with a ``StringRef``, ``Twine`` objects point to external memory and should @@ -453,8 +453,8 @@ recovery. LLVM, there are places where this hasn't been practical to apply. In situations where you absolutely must emit a non-programmatic error and the ``Error`` model isn't workable you can call ``report_fatal_error``, - which will call installed error handlers, print a message, and exit the - program. + which will call installed error handlers, print a message, and abort the + program. The use of `report_fatal_error` in this case is discouraged. Recoverable errors are modeled using LLVM's ``Error`` scheme. This scheme represents errors using function return values, similar to classic C integer @@ -847,7 +847,7 @@ this, use the named constructor idiom and return an ``Expected``: public: static Expected Create(Resource R1, Resource R2) { - Error Err; + Error Err = Error::success(); Foo F(R1, R2, Err); if (Err) return std::move(Err); @@ -946,7 +946,7 @@ following natural iteration idiom for fallible containers like Archive: .. code-block:: c++ - Error Err; + Error Err = Error::success(); for (auto &Child : Ar->children(Err)) { // Use Child - only enter the loop when it's valid @@ -1056,7 +1056,7 @@ The ``function_ref`` class template ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The ``function_ref`` -(`doxygen `__) class +(`doxygen `__) class template represents a reference to a callable object, templated over the type of the callable. This is a good choice for passing a callback to a function, if you don't need to hold onto the callback after the function returns. In this @@ -1106,7 +1106,7 @@ you don't want them to always be noisy. A standard compromise is to comment them out, allowing you to enable them if you need them in the future. The ``llvm/Support/Debug.h`` (`doxygen -`__) file provides a macro named +`__) file provides a macro named ``LLVM_DEBUG()`` that is a much nicer solution to this problem. Basically, you can put arbitrary code into the argument of the ``LLVM_DEBUG`` macro, and it is only executed if '``opt``' (or any other tool) is run with the '``-debug``' command @@ -1203,7 +1203,7 @@ The ``Statistic`` class & ``-stats`` option ------------------------------------------- The ``llvm/ADT/Statistic.h`` (`doxygen -`__) file provides a class +`__) file provides a class named ``Statistic`` that is used as a unified way to keep track of what the LLVM compiler is doing and how effective various optimizations are. It is useful to see what optimizations are contributing to making a particular program run @@ -1298,7 +1298,7 @@ They provide a framework for making parts of your code only execute a certain number of times. The ``llvm/Support/DebugCounter.h`` (`doxygen -`__) file +`__) file provides a class named ``DebugCounter`` that can be used to create command line counter options that control execution of parts of your code. @@ -2341,11 +2341,11 @@ always better. .. _ds_bit: -Bit storage containers (BitVector, SparseBitVector) ---------------------------------------------------- +Bit storage containers (BitVector, SparseBitVector, CoalescingBitVector) +------------------------------------------------------------------------ -Unlike the other containers, there are only two bit storage containers, and -choosing when to use each is relatively straightforward. +There are three bit storage containers, and choosing when to use each is +relatively straightforward. One additional option is ``std::vector``: we discourage its use for two reasons 1) the implementation in many common compilers (e.g. commonly @@ -2395,6 +2395,22 @@ reverse) is O(1) worst case. Testing and setting bits within 128 bits (depends on size) of the current bit is also O(1). As a general statement, testing/setting bits in a SparseBitVector is O(distance away from last set bit). +.. _dss_coalescingbitvector: + +CoalescingBitVector +^^^^^^^^^^^^^^^^^^^ + +The CoalescingBitVector container is similar in principle to a SparseBitVector, +but is optimized to represent large contiguous ranges of set bits compactly. It +does this by coalescing contiguous ranges of set bits into intervals. Searching +for a bit in a CoalescingBitVector is O(log(gaps between contiguous ranges)). + +CoalescingBitVector is a better choice than BitVector when gaps between ranges +of set bits are large. It's a better choice than SparseBitVector when find() +operations must have fast, predictable performance. However, it's not a good +choice for representing sets which have lots of very short ranges. E.g. the set +`{2*x : x \in [0, n)}` would be a pathological input. + .. _debugging: Debugging @@ -2497,7 +2513,7 @@ If you're finding that you commonly iterate over a ``Function``'s ``BasicBlock``\ s and then that ``BasicBlock``'s ``Instruction``\ s, ``InstIterator`` should be used instead. You'll need to include ``llvm/IR/InstIterator.h`` (`doxygen -`__) and then instantiate +`__) and then instantiate ``InstIterator``\ s explicitly in your code. Here's a small example that shows how to dump all instructions in a function to the standard error stream: @@ -2604,7 +2620,7 @@ want to do: for each Function f in the Module for each BasicBlock b in f for each Instruction i in b - if (i is a CallInst and calls the given function) + if (i a Call and calls the given function) increment callCounter And the actual code is (remember, because we're writing a ``FunctionPass``, our @@ -2622,11 +2638,11 @@ method): virtual runOnFunction(Function& F) { for (BasicBlock &B : F) { for (Instruction &I: B) { - if (auto *CallInst = dyn_cast(&I)) { - // We know we've encountered a call instruction, so we - // need to determine if it's a call to the - // function pointed to by m_func or not. - if (CallInst->getCalledFunction() == targetFunc) + if (auto *CB = dyn_cast(&I)) { + // We know we've encountered some kind of call instruction (call, + // invoke, or callbr), so we need to determine if it's a call to + // the function pointed to by m_func or not. + if (CB->getCalledFunction() == targetFunc) ++callCounter; } } @@ -2637,34 +2653,13 @@ method): unsigned callCounter; }; -.. _calls_and_invokes: - -Treating calls and invokes the same way -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You may have noticed that the previous example was a bit oversimplified in that -it did not deal with call sites generated by 'invoke' instructions. In this, -and in other situations, you may find that you want to treat ``CallInst``\ s and -``InvokeInst``\ s the same way, even though their most-specific common base -class is ``Instruction``, which includes lots of less closely-related things. -For these cases, LLVM provides a handy wrapper class called ``CallSite`` -(`doxygen `__) It is -essentially a wrapper around an ``Instruction`` pointer, with some methods that -provide functionality common to ``CallInst``\ s and ``InvokeInst``\ s. - -This class has "value semantics": it should be passed by value, not by reference -and it should not be dynamically allocated or deallocated using ``operator new`` -or ``operator delete``. It is efficiently copyable, assignable and -constructable, with costs equivalents to that of a bare pointer. If you look at -its definition, it has only a single pointer member. - .. _iterate_chains: Iterating over def-use & use-def chains ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Frequently, we might have an instance of the ``Value`` class (`doxygen -`__) and we want to determine +`__) and we want to determine which ``User``\ s use the ``Value``. The list of all ``User``\ s of a particular ``Value`` is called a *def-use* chain. For example, let's say we have a ``Function*`` named ``F`` to a particular function ``foo``. Finding all of the @@ -2682,7 +2677,7 @@ chain of ``F``: } Alternatively, it's common to have an instance of the ``User`` Class (`doxygen -`__) and need to know what +`__) and need to know what ``Value``\ s are used by it. The list of all ``Value``\ s used by a ``User`` is known as a *use-def* chain. Instances of class ``Instruction`` are common ``User`` s, so we might want to iterate over all of the values that a particular @@ -2754,7 +2749,7 @@ will create an ``AllocaInst`` instance that represents the allocation of one integer in the current stack frame, at run time. Each ``Instruction`` subclass is likely to have varying default parameters which change the semantics of the instruction, so refer to the `doxygen documentation for the subclass of -Instruction `_ that +Instruction `_ that you're interested in instantiating. *Naming values* @@ -2912,7 +2907,7 @@ Replacing individual instructions """"""""""""""""""""""""""""""""" Including "`llvm/Transforms/Utils/BasicBlockUtils.h -`_" permits use of two +`_" permits use of two very useful replace functions: ``ReplaceInstWithValue`` and ``ReplaceInstWithInst``. @@ -2958,8 +2953,8 @@ Replacing multiple uses of Users and Values You can use ``Value::replaceAllUsesWith`` and ``User::replaceUsesOfWith`` to change more than one use at a time. See the doxygen documentation for the -`Value Class `_ and `User Class -`_, respectively, for more +`Value Class `_ and `User Class +`_, respectively, for more information. .. _schanges_deletingGV: @@ -2996,7 +2991,7 @@ proper operation in multithreaded mode. Note that, on Unix-like platforms, LLVM requires the presence of GCC's atomic intrinsics in order to support threaded operation. If you need a -multhreading-capable LLVM on a platform without a suitably modern system +multithreading-capable LLVM on a platform without a suitably modern system compiler, consider compiling LLVM and LLVM-GCC in single-threaded mode, and using the resultant compiler to build a copy of LLVM with multithreading support. @@ -3087,7 +3082,7 @@ The ``ValueSymbolTable`` class ------------------------------ The ``ValueSymbolTable`` (`doxygen -`__) class provides +`__) class provides a symbol table that the :ref:`Function ` and Module_ classes use for naming value definitions. The symbol table can provide a name for any Value_. @@ -3108,10 +3103,10 @@ autoinsert it into the appropriate symbol table. The ``User`` and owned ``Use`` classes' memory layout ----------------------------------------------------- -The ``User`` (`doxygen `__) +The ``User`` (`doxygen `__) class provides a basis for expressing the ownership of ``User`` towards other -`Value instance `_\ s. The -``Use`` (`doxygen `__) helper +`Value instance `_\ s. The +``Use`` (`doxygen `__) helper class is employed to do the bookkeeping and to facilitate *O(1)* addition and removal. @@ -3171,143 +3166,9 @@ memory layouts: *(In the above figures* '``P``' *stands for the* ``Use**`` *that is stored in each* ``Use`` *object in the member* ``Use::Prev`` *)* -.. _Waymarking: - -The waymarking algorithm -^^^^^^^^^^^^^^^^^^^^^^^^ - -Since the ``Use`` objects are deprived of the direct (back)pointer to their -``User`` objects, there must be a fast and exact method to recover it. This is -accomplished by the following scheme: - -A bit-encoding in the 2 LSBits (least significant bits) of the ``Use::Prev`` -allows to find the start of the ``User`` object: - -* ``00`` --- binary digit 0 - -* ``01`` --- binary digit 1 - -* ``10`` --- stop and calculate (``s``) - -* ``11`` --- full stop (``S``) - -Given a ``Use*``, all we have to do is to walk till we get a stop and we either -have a ``User`` immediately behind or we have to walk to the next stop picking -up digits and calculating the offset: - -.. code-block:: none - - .---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---------------- - | 1 | s | 1 | 0 | 1 | 0 | s | 1 | 1 | 0 | s | 1 | 1 | s | 1 | S | User (or User*) - '---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---------------- - |+15 |+10 |+6 |+3 |+1 - | | | | | __> - | | | | __________> - | | | ______________________> - | | ______________________________________> - | __________________________________________________________> - -Only the significant number of bits need to be stored between the stops, so that -the *worst case is 20 memory accesses* when there are 1000 ``Use`` objects -associated with a ``User``. - -.. _ReferenceImpl: - -Reference implementation -^^^^^^^^^^^^^^^^^^^^^^^^ - -The following literate Haskell fragment demonstrates the concept: - -.. code-block:: haskell - - > import Test.QuickCheck - > - > digits :: Int -> [Char] -> [Char] - > digits 0 acc = '0' : acc - > digits 1 acc = '1' : acc - > digits n acc = digits (n `div` 2) $ digits (n `mod` 2) acc - > - > dist :: Int -> [Char] -> [Char] - > dist 0 [] = ['S'] - > dist 0 acc = acc - > dist 1 acc = let r = dist 0 acc in 's' : digits (length r) r - > dist n acc = dist (n - 1) $ dist 1 acc - > - > takeLast n ss = reverse $ take n $ reverse ss - > - > test = takeLast 40 $ dist 20 [] - > - -Printing gives: ``"1s100000s11010s10100s1111s1010s110s11s1S"`` - -The reverse algorithm computes the length of the string just by examining a -certain prefix: - -.. code-block:: haskell - - > pref :: [Char] -> Int - > pref "S" = 1 - > pref ('s':'1':rest) = decode 2 1 rest - > pref (_:rest) = 1 + pref rest - > - > decode walk acc ('0':rest) = decode (walk + 1) (acc * 2) rest - > decode walk acc ('1':rest) = decode (walk + 1) (acc * 2 + 1) rest - > decode walk acc _ = walk + acc - > - -Now, as expected, printing gives ``40``. - -We can *quickCheck* this with following property: - -.. code-block:: haskell - - > testcase = dist 2000 [] - > testcaseLength = length testcase - > - > identityProp n = n > 0 && n <= testcaseLength ==> length arr == pref arr - > where arr = takeLast n testcase - > - -As expected gives: - -:: - - *Main> quickCheck identityProp - OK, passed 100 tests. - -Let's be a bit more exhaustive: - -.. code-block:: haskell - - > - > deepCheck p = check (defaultConfig { configMaxTest = 500 }) p - > - -And here is the result of : - -:: - - *Main> deepCheck identityProp - OK, passed 500 tests. - -.. _Tagging: - -Tagging considerations -^^^^^^^^^^^^^^^^^^^^^^ - -To maintain the invariant that the 2 LSBits of each ``Use**`` in ``Use`` never -change after being set up, setters of ``Use::Prev`` must re-tag the new -``Use**`` on every modification. Accordingly getters must strip the tag bits. - -For layout b) instead of the ``User`` we find a pointer (``User*`` with LSBit -set). Following this pointer brings us to the ``User``. A portable trick -ensures that the first bytes of ``User`` (if interpreted as a pointer) never has -the LSBit set. (Portability is relying on the fact that all known compilers -place the ``vptr`` in the first word of the instances.) - .. _polymorphism: -Designing Type Hiercharies and Polymorphic Interfaces +Designing Type Hierarchies and Polymorphic Interfaces ----------------------------------------------------- There are two different design patterns that tend to result in the use of @@ -3351,7 +3212,7 @@ by Sean Parent in several of his talks and papers: describing this technique in more detail. #. `Sean Parent's Papers and Presentations `_ - - A Github project full of links to slides, video, and sometimes code. + - A GitHub project full of links to slides, video, and sometimes code. When deciding between creating a type hierarchy (with either tagged or virtual dispatch) and using templates or concepts-based polymorphism, consider whether @@ -3398,9 +3259,9 @@ The Core LLVM Class Hierarchy Reference ``#include "llvm/IR/Type.h"`` -header source: `Type.h `_ +header source: `Type.h `_ -doxygen info: `Type Clases `_ +doxygen info: `Type Classes `_ The Core LLVM classes are the primary means of representing the program being inspected or transformed. The core LLVM classes are defined in header files in @@ -3502,9 +3363,9 @@ The ``Module`` class ``#include "llvm/IR/Module.h"`` -header source: `Module.h `_ +header source: `Module.h `_ -doxygen info: `Module Class `_ +doxygen info: `Module Class `_ The ``Module`` class represents the top level structure present in LLVM programs. An LLVM module is effectively either a translation unit of the @@ -3595,9 +3456,9 @@ The ``Value`` class ``#include "llvm/IR/Value.h"`` -header source: `Value.h `_ +header source: `Value.h `_ -doxygen info: `Value Class `_ +doxygen info: `Value Class `_ The ``Value`` class is the most important class in the LLVM Source base. It represents a typed value that may be used (among other things) as an operand to @@ -3686,9 +3547,9 @@ The ``User`` class ``#include "llvm/IR/User.h"`` -header source: `User.h `_ +header source: `User.h `_ -doxygen info: `User Class `_ +doxygen info: `User Class `_ Superclass: Value_ @@ -3733,10 +3594,10 @@ The ``Instruction`` class ``#include "llvm/IR/Instruction.h"`` header source: `Instruction.h -`_ +`_ doxygen info: `Instruction Class -`_ +`_ Superclasses: User_, Value_ @@ -3757,7 +3618,7 @@ instructions in LLVM. It describes the enum values that are used as opcodes concrete sub-classes of ``Instruction`` that implement the instruction (for example BinaryOperator_ and CmpInst_). Unfortunately, the use of macros in this file confuses doxygen, so these enum values don't show up correctly in the -`doxygen output `_. +`doxygen output `_. .. _s_Instruction: @@ -3782,7 +3643,7 @@ Important Subclasses of the ``Instruction`` class * ``CmpInst`` This subclass represents the two comparison instructions, - `ICmpInst `_ (integer opreands), and + `ICmpInst `_ (integer operands), and `FCmpInst `_ (floating point operands). .. _m_Instruction: @@ -3874,10 +3735,10 @@ The ``GlobalValue`` class ``#include "llvm/IR/GlobalValue.h"`` header source: `GlobalValue.h -`_ +`_ doxygen info: `GlobalValue Class -`_ +`_ Superclasses: Constant_, User_, Value_ @@ -3932,10 +3793,10 @@ The ``Function`` class ``#include "llvm/IR/Function.h"`` -header source: `Function.h `_ +header source: `Function.h `_ doxygen info: `Function Class -`_ +`_ Superclasses: GlobalValue_, Constant_, User_, Value_ @@ -4041,10 +3902,10 @@ The ``GlobalVariable`` class ``#include "llvm/IR/GlobalVariable.h"`` header source: `GlobalVariable.h -`_ +`_ doxygen info: `GlobalVariable Class -`_ +`_ Superclasses: GlobalValue_, Constant_, User_, Value_ @@ -4084,7 +3945,7 @@ Important Public Members of the ``GlobalVariable`` class * ``bool hasInitializer()`` - Returns true if this ``GlobalVariable`` has an intializer. + Returns true if this ``GlobalVariable`` has an initializer. * ``Constant *getInitializer()`` @@ -4099,10 +3960,10 @@ The ``BasicBlock`` class ``#include "llvm/IR/BasicBlock.h"`` header source: `BasicBlock.h -`_ +`_ doxygen info: `BasicBlock Class -`_ +`_ Superclass: Value_ diff --git a/gnu/llvm/llvm/docs/Proposals/GitHubMove.rst b/gnu/llvm/llvm/docs/Proposals/GitHubMove.rst index ed46f5ae199..d11dbe260c5 100644 --- a/gnu/llvm/llvm/docs/Proposals/GitHubMove.rst +++ b/gnu/llvm/llvm/docs/Proposals/GitHubMove.rst @@ -141,9 +141,9 @@ Unfortunately, GitHub does not support server side hooks to enforce such a policy. We must rely on the community to avoid pushing merge commits. GitHub offers a feature called `Status Checks`: a branch protected by -`status checks` requires commits to be whitelisted before the push can happen. +`status checks` requires commits to be explicitly allowed before the push can happen. We could supply a pre-push hook on the client side that would run and check the -history, before whitelisting the commit being pushed [statuschecks]_. +history, before allowing the commit being pushed [statuschecks]_. However this solution would be somewhat fragile (how do you update a script installed on every developer machine?) and prevents SVN access to the repository. @@ -202,14 +202,14 @@ Step #4 : Post Move 14. Update links on the LLVM website pointing to viewvc/klaus/phab etc. to point to GitHub instead. -Github Repository Description +GitHub Repository Description ============================= Monorepo ---------------- The LLVM git repository hosted at https://github.com/llvm/llvm-project contains all -sub-projects in a single source tree. It is often refered to as a monorepo and +sub-projects in a single source tree. It is often referred to as a monorepo and mimics an export of the current SVN repository, with each sub-project having its own top-level directory. Not all sub-projects are used for building toolchains. For example, www/ and test-suite/ are not part of the monorepo. @@ -281,7 +281,7 @@ Monorepo Drawbacks 1GB for the monorepo), and the commit rate of LLVM may cause more frequent `git push` collisions when upstreaming. Affected contributors may be able to use the SVN bridge or the single-subproject Git mirrors. However, it's - undecided if these projects will continue to be mantained. + undecided if these projects will continue to be maintained. * Using the monolithic repository may add overhead for those *integrating* a standalone sub-project, even if they aren't contributing to it, due to the same disk space concern as the point above. The availability of the @@ -319,7 +319,7 @@ Currently # direct SVN checkout svn co https://user@llvm.org/svn/llvm-project/llvm/trunk llvm # or using the read-only Git view, with git-svn - git clone http://llvm.org/git/llvm.git + git clone https://llvm.org/git/llvm.git cd llvm git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username= git config svn-remote.svn.fetch :refs/remotes/origin/master @@ -356,7 +356,7 @@ Before you push, you'll need to fetch and rebase (`git pull --rebase`) as usual. Note that when you fetch you'll likely pull in changes to sub-projects you don't -care about. If you are using spasre checkout, the files from other projects +care about. If you are using sparse checkout, the files from other projects won't appear on your disk. The only effect is that your commit hash changes. You can check whether the changes in the last fetch are relevant to your commit @@ -381,29 +381,29 @@ Currently :: - svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm -r $REVISION + svn co https://llvm.org/svn/llvm-project/llvm/trunk llvm -r $REVISION cd llvm/tools - svn co http://llvm.org/svn/llvm-project/clang/trunk clang -r $REVISION + svn co https://llvm.org/svn/llvm-project/clang/trunk clang -r $REVISION cd ../projects - svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx -r $REVISION + svn co https://llvm.org/svn/llvm-project/libcxx/trunk libcxx -r $REVISION Or using git-svn:: - git clone http://llvm.org/git/llvm.git + git clone https://llvm.org/git/llvm.git cd llvm/ git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username= git config svn-remote.svn.fetch :refs/remotes/origin/master git svn rebase -l git checkout `git svn find-rev -B r258109` cd tools - git clone http://llvm.org/git/clang.git + git clone https://llvm.org/git/clang.git cd clang/ git svn init https://llvm.org/svn/llvm-project/clang/trunk --username= git config svn-remote.svn.fetch :refs/remotes/origin/master git svn rebase -l git checkout `git svn find-rev -B r258109` cd ../../projects/ - git clone http://llvm.org/git/libcxx.git + git clone https://llvm.org/git/libcxx.git cd libcxx git svn init https://llvm.org/svn/llvm-project/libcxx/trunk --username= git config svn-remote.svn.fetch :refs/remotes/origin/master @@ -657,7 +657,7 @@ done for each branch. Ref paths will need to be updated to map the local branch to the corresponding upstream branch. If local branches have no corresponding upstream branch, then the creation of ``local/octopus/`` need not use ``git-merge-base`` to -pinpont its root commit; it may simply be branched from the +pinpoint its root commit; it may simply be branched from the appropriate component branch (say, ``llvm/local_release_X``). Zipping local history @@ -712,7 +712,7 @@ clang's tree actually looks like in ``Lclang1``. Even so, the edge ``U3 -> Llld1`` could be problematic for future merges from upstream. git will think that we've already merged from ``U3``, and we have, except for the state of the clang tree. One -possible migitation strategy is to manually diff clang between ``U2`` +possible mitigation strategy is to manually diff clang between ``U2`` and ``U3`` and apply those updates to ``local/zip``. Another, possibly simpler strategy is to freeze local work on downstream branches and merge all submodules from the latest upstream before @@ -812,7 +812,7 @@ The tool handles nested submodules (e.g. llvm is a submodule in umbrella and clang is a submodule in llvm). The file ``submodule-map.txt`` is a list of pairs, one per line. The first pair item describes the path to a submodule in the umbrella -repository. The second pair item secribes the path where trees for +repository. The second pair item describes the path where trees for that submodule should be written in the zipped history. Let's say your umbrella repository is actually the llvm repository and @@ -921,7 +921,7 @@ ecosystem, essentially extending it with new tools. If such repositories are tightly coupled with LLVM, it may make sense to import them into your local mirror of the monorepo. -If such repositores participated in the umbrella repository used +If such repositories participated in the umbrella repository used during the zipping process above, they will automatically be added to the monorepo. For downstream repositories that don't participate in an umbrella setup, the ``import-downstream-repo.py`` tool at @@ -945,7 +945,7 @@ getting them into the monorepo. A recipe follows:: --tag-prefix="myrepo-" ) - # Preserve release braches. + # Preserve release branches. for ref in $(git -C my-monorepo for-each-ref --format="%(refname)" \ refs/remotes/myrepo/release); do branch=${ref#refs/remotes/myrepo/} diff --git a/gnu/llvm/llvm/docs/Proposals/TestSuite.rst b/gnu/llvm/llvm/docs/Proposals/TestSuite.rst index 85f3642a2e9..29507495c11 100644 --- a/gnu/llvm/llvm/docs/Proposals/TestSuite.rst +++ b/gnu/llvm/llvm/docs/Proposals/TestSuite.rst @@ -1,5 +1,5 @@ ===================== -Test-Suite Extentions +Test-Suite Extensions ===================== .. contents:: @@ -191,7 +191,7 @@ CORAL-2 Benchmarks ------------------ https://asc.llnl.gov/coral-2-benchmarks/ -Many of its programs have already been integreated in +Many of its programs have already been integrated in MultiSource/Benchmarks/DOE-ProxyApps-C and MultiSource/Benchmarks/DOE-ProxyApps-C++. diff --git a/gnu/llvm/llvm/docs/Proposals/VariableNames.rst b/gnu/llvm/llvm/docs/Proposals/VariableNames.rst index 3e07fc5606d..1739695a518 100644 --- a/gnu/llvm/llvm/docs/Proposals/VariableNames.rst +++ b/gnu/llvm/llvm/docs/Proposals/VariableNames.rst @@ -153,7 +153,7 @@ TargetRegisterInfo tri In some cases renaming acronyms to the full type name will result in overly verbose code. Unlike most classes, a variable's scope is limited and therefore some of its purpose can implied from that scope, meaning that fewer words are -necessary to give it a clear name. For example, in an optization pass the reader +necessary to give it a clear name. For example, in an optimization pass the reader can assume that a variable's purpose relates to optimization and therefore an ``OptimizationRemarkEmitter`` variable could be given the name ``remarkEmitter`` or even ``remarker``. diff --git a/gnu/llvm/llvm/docs/Proposals/VectorPredication.rst b/gnu/llvm/llvm/docs/Proposals/VectorPredication.rst new file mode 100644 index 00000000000..4e93f4fea31 --- /dev/null +++ b/gnu/llvm/llvm/docs/Proposals/VectorPredication.rst @@ -0,0 +1,88 @@ +========================== +Vector Predication Roadmap +========================== + +.. contents:: Table of Contents + :depth: 3 + :local: + +Motivation +========== + +This proposal defines a roadmap towards native vector predication in LLVM, +specifically for vector instructions with a mask and/or an explicit vector +length. LLVM currently has no target-independent means to model predicated +vector instructions for modern SIMD ISAs such as AVX512, ARM SVE, the RISC-V V +extension and NEC SX-Aurora. Only some predicated vector operations, such as +masked loads and stores, are available through intrinsics [MaskedIR]_. + +The Vector Predication (VP) extensions is a concrete RFC and prototype +implementation to achieve native vector predication in LLVM. The VP prototype +and all related discussions can be found in the VP patch on Phabricator +[VPRFC]_. + +Roadmap +======= + +1. IR-level VP intrinsics +------------------------- + +- There is a consensus on the semantics/instruction set of VP. +- VP intrinsics and attributes are available on IR level. +- TTI has capability flags for VP (``supportsVP()``?, + ``haveActiveVectorLength()``?). + +Result: VP usable for IR-level vectorizers (LV, VPlan, RegionVectorizer), +potential integration in Clang with builtins. + +2. CodeGen support +------------------ + +- VP intrinsics translate to first-class SDNodes + (eg ``llvm.vp.fdiv.* -> vp_fdiv``). +- VP legalization (legalize explicit vector length to mask (AVX512), legalize VP + SDNodes to pre-existing ones (SSE, NEON)). + +Result: Backend development based on VP SDNodes. + +3. Lift InstSimplify/InstCombine/DAGCombiner to VP +-------------------------------------------------- + +- Introduce PredicatedInstruction, PredicatedBinaryOperator, .. helper classes + that match standard vector IR and VP intrinsics. +- Add a matcher context to PatternMatch and context-aware IR Builder APIs. +- Incrementally lift DAGCombiner to work on VP SDNodes as well as on regular + vector instructions. +- Incrementally lift InstCombine/InstSimplify to operate on VP as well as + regular IR instructions. + +Result: Optimization of VP intrinsics on par with standard vector instructions. + +4. Deprecate llvm.masked.* / llvm.experimental.reduce.* +------------------------------------------------------- + +- Modernize llvm.masked.* / llvm.experimental.reduce* by translating to VP. +- DCE transitional APIs. + +Result: VP has superseded earlier vector intrinsics. + +5. Predicated IR Instructions +----------------------------- + +- Vector instructions have an optional mask and vector length parameter. These + lower to VP SDNodes (from Stage 2). +- Phase out VP intrinsics, only keeping those that are not equivalent to + vectorized scalar instructions (reduce, shuffles, ..) +- InstCombine/InstSimplify expect predication in regular Instructions (Stage (3) + has laid the groundwork). + +Result: Native vector predication in IR. + +References +========== + +.. [MaskedIR] `llvm.masked.*` intrinsics, + https://llvm.org/docs/LangRef.html#masked-vector-load-and-store-intrinsics + +.. [VPRFC] RFC: Prototype & Roadmap for vector predication in LLVM, + https://reviews.llvm.org/D57504 diff --git a/gnu/llvm/llvm/docs/README.txt b/gnu/llvm/llvm/docs/README.txt index 92b146f0c1c..2a9b2e38302 100644 --- a/gnu/llvm/llvm/docs/README.txt +++ b/gnu/llvm/llvm/docs/README.txt @@ -5,7 +5,7 @@ LLVM's documentation is written in reStructuredText, a lightweight plaintext markup language (file extension `.rst`). While the reStructuredText documentation should be quite readable in source form, it is mostly meant to be processed by the Sphinx documentation generation -system to create HTML pages which are hosted on and +system to create HTML pages which are hosted on and updated after every commit. Manpage output is also supported, see below. If you instead would like to generate and view the HTML locally, install @@ -17,7 +17,7 @@ Sphinx and then do: $BROWSER /docs//html/index.html The mapping between reStructuredText files and generated documentation is -`docs/Foo.rst` <-> `/docs//html/Foo.html` <-> `http://llvm.org/docs/Foo.html`. +`docs/Foo.rst` <-> `/docs//html/Foo.html` <-> `https://llvm.org/docs/Foo.html`. If you are interested in writing new documentation, you will want to read `SphinxQuickstartTemplate.rst` which will get you writing documentation @@ -41,7 +41,7 @@ The correspondence between .rst files and man pages is `docs/CommandGuide/Foo.rst` <-> `/docs//man/Foo.1`. These .rst files are also included during HTML generation so they are also viewable online (as noted above) at e.g. -`http://llvm.org/docs/CommandGuide/Foo.html`. +`https://llvm.org/docs/CommandGuide/Foo.html`. Checking links ============== diff --git a/gnu/llvm/llvm/docs/Reference.rst b/gnu/llvm/llvm/docs/Reference.rst index 8aef4eec587..3911094fbfd 100644 --- a/gnu/llvm/llvm/docs/Reference.rst +++ b/gnu/llvm/llvm/docs/Reference.rst @@ -37,6 +37,7 @@ LLVM and API reference documentation. PDB/index ScudoHardenedAllocator MemTagSanitizer + Security SegmentedStacks StackMaps SpeculativeLoadHardening @@ -53,8 +54,8 @@ LLVM and API reference documentation. API Reference ------------- -`Doxygen generated documentation `_ - (`classes `_) +`Doxygen generated documentation `_ + (`classes `_) :doc:`HowToUseAttributes` Answers some questions about the new Attributes infrastructure. @@ -190,7 +191,7 @@ Additional Topics :doc:`MemTagSanitizer` Security hardening for production code aiming to mitigate memory - related vulnerabilities. Based on ARMv9 Memory Tagging Extension. + related vulnerabilities. Based on the Armv8.5-A Memory Tagging Extension. :doc:`Dependence Graphs ` A description of the design of the various dependence graphs such as diff --git a/gnu/llvm/llvm/docs/ReleaseNotes.rst b/gnu/llvm/llvm/docs/ReleaseNotes.rst index 26f0692da4a..f5f50cbf015 100644 --- a/gnu/llvm/llvm/docs/ReleaseNotes.rst +++ b/gnu/llvm/llvm/docs/ReleaseNotes.rst @@ -1,5 +1,5 @@ ========================= -LLVM 10.0.0 Release Notes +LLVM 11.0.0 Release Notes ========================= .. contents:: @@ -9,7 +9,7 @@ Introduction ============ This document contains the release notes for the LLVM Compiler Infrastructure, -release 10.0.0. Here we describe the status of LLVM, including major improvements +release 11.0.0. Here we describe the status of LLVM, including major improvements from the previous release, improvements in various subprojects of LLVM, and some of the current users of the code. All LLVM releases may be downloaded from the `LLVM releases web site `_. @@ -20,380 +20,385 @@ have questions or comments, the `LLVM Developer's Mailing List `_ is a good place to send them. -Non-comprehensive list of changes in this release +Deprecated and Removed Features/APIs ================================================= +* BG/Q support, including QPX, will be removed in the 12.0.0 release. -* The ISD::FP_ROUND_INREG opcode and related code was removed from SelectionDAG. - -* Enabled MemorySSA as a loop dependency. Since - `r370957 `_ - (`D58311 `_ ``[MemorySSA & LoopPassManager] - Enable MemorySSA as loop dependency. Update tests.``), the MemorySSA analysis - is being preserved and used by a series of loop passes. The most significant - use is in LICM, where the instruction hoisting and sinking relies on aliasing - information provided by MemorySSA vs previously creating an AliasSetTracker. - The LICM step of promoting variables to scalars still relies on the creation - of an AliasSetTracker, but its use is reduced to only be enabled for loops - with a small number of overall memory instructions. This choice was motivated - by experimental results showing compile and run time benefits or replacing the - AliasSetTracker usage with MemorySSA without any performance penalties. - The fact that MemorySSA is now preserved by and available in a series of loop - passes, also opens up opportunities for its use in those respective passes. - -* The BasicBlockPass, BBPassManager and all their uses were deleted in - `this revision `_. - -* The LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB CMake options are no longer - available on Windows. - -* As per :ref:`LLVM Language Reference Manual `, - ``getelementptr inbounds`` can not change the null status of a pointer, - meaning it can not produce non-null pointer given null base pointer, and - likewise given non-null base pointer it can not produce null pointer; if it - does, the result is a :ref:`poison value `. - Since `r369789 `_ - (`D66608 `_ ``[InstCombine] icmp eq/ne (gep - inbounds P, Idx..), null -> icmp eq/ne P, null``) LLVM uses that for - transformations. If the original source violates these requirements this - may result in code being miscompiled. If you are using Clang front-end, - Undefined Behaviour Sanitizer ``-fsanitize=pointer-overflow`` check - will now catch such cases. - -* Windows Control Flow Guard: the ``-cfguard`` option now emits CFG checks on - indirect function calls. The previous behavior is still available with the - ``-cfguard-nochecks`` option. Note that this feature should always be used - with optimizations enabled. - -* ``Callbacks`` have been added to ``CommandLine Options``. These can - be used to validate or selectively enable other options. - -* The function attributes ``no-frame-pointer-elim`` and - ``no-frame-pointer-elim-non-leaf`` have been replaced by ``frame-pointer``, - which has 3 values: ``none``, ``non-leaf``, and ``all``. The values mean what - functions should retain frame pointers. - -* The inter-procedural analysis and optimization capabilities in the Attributor - framework and pass have been substantially advanced (initial commit - `D59918 `_, `LLVM-Dev talk `_). - In this release, 19 different attributes are inferred, including 12 LLVM IR - attributes and 7 "abstract" attributes, such as liveness. The Attributor is - still under heavy development and disabled by default; to enable an early run - pass ``-mllvm -attributor-disable=false`` to an invocation of clang. - -* New matrix math intrinsics have been added to LLVM - (see :ref:`LLVM Language Reference Manual `), together - with the LowerMatrixIntrinsics pass. The pass lowers matrix intrinsics - to a set of efficient vector instructions. The lowering pass is off - by default and can be enabled by passing ``-mllvm -enable-matrix`` to an - invocation of clang. +Non-comprehensive list of changes in this release +================================================= +* The llgo frontend has been removed for now, but may be resurrected in the + future. Changes to the LLVM IR ---------------------- -* Unnamed function arguments now get printed with their automatically - generated name (e.g. "i32 %0") in definitions. This may require front-ends - to update their tests; if so there is a script utils/add_argument_names.py - that correctly converted 80-90% of Clang tests. Some manual work will almost - certainly still be needed. - -* A new ``freeze`` instruction is added. The ``freeze`` instruction is used to stop - IR-level propagation of undef and poison values. Currently its support is - preliminary; a freeze-equivalent operation for SelDag/MIR needs to be added. - - - -Changes to the AArch64 Backend ------------------------------- - -* Added support for Cortex-A65, Cortex-A65AE, Neoverse E1 and Neoverse N1 cores. - -* With a few more bugs fixed in the LLVM 10 release, clang-cl can now target - Windows-on-ARM well, demonstrated by building complex pieces of software such - as Chromium and the Electron framework. - -* Support for ``-fpatchable-function-entry`` was added. - -Changes to the ARM Backend --------------------------- +* The callsite attribute `vector-function-abi-variant + `_ has been + added to describe the mapping between scalar functions and vector + functions, to enable vectorization of call sites. The information + provided by the attribute is interfaced via the API provided by the + ``VFDatabase`` class. When scanning through the set of vector + functions associated with a scalar call, the loop vectorizer now + relies on ``VFDatabase``, instead of ``TargetLibraryInfo``. + +* `dereferenceable` attributes and metadata on pointers no longer imply + anything about the alignment of the pointer in question. Previously, some + optimizations would make assumptions based on the type of the pointer. This + behavior was undocumented. To preserve optimizations, frontends may need to + be updated to generate appropriate `align` attributes and metadata. + +* The DIModule metadata is extended to contain file and line number + information. This information is used to represent Fortran modules debug + info at IR level. + +* LLVM IR now supports two distinct ``llvm::FixedVectorType`` and + ``llvm::ScalableVectorType`` vector types, both derived from the + base class ``llvm::VectorType``. A number of algorithms dealing with + IR vector types have been updated to make sure they work for both + scalable and fixed vector types. Where possible, the code has been + made generic to cover both cases using the base class. Specifically, + places that were using the type ``unsigned`` to count the number of + lanes of a vector are now using ``llvm::ElementCount``. In places + where ``uint64_t`` was used to denote the size in bits of a IR type + we have partially migrated the codebase to using ``llvm::TypeSize``. + +* Branching on ``undef``/``poison`` is undefined behavior. It is needed for + correctly analyzing value ranges based on branch conditions. This is + consistent with MSan's behavior as well. + +* ``memset``/``memcpy``/``memmove`` can take ``undef``/``poison`` pointer(s) + if the size to fill is zero. + +* Passing ``undef``/``poison`` to a standard I/O library function call + (`printf`/`fputc`/...) is undefined behavior. The new ``noundef`` attribute + is attached to the functions' arguments. The full list is available at + ``llvm::inferLibFuncAttributes``. + +Changes to building LLVM +------------------------ -* Optimized ARMv8.1-M code generation, including generating Low Overhead Loops. +* The LLVM project has started the migration towards Python 3, and the build + system now prefers Python 3 whenever available. If the Python 3 interpreter + (or libraries) are not found, the build system will, for the time being, fall + back to Python 2. It is recommended that downstream projects migrate to + Python 3 as Python 2 has been end-of-life'd by the Python Software + Foundation. -* Added auto-vectorization for the ARMv8.1-M MVE vector extension. +Changes to the JIT infrastructure +--------------------------------- -* Support was added for inline asm constraints s,j,x,N,O. +* LLJIT now supports execution of static inits / deinits via the + LLJIT::initialize and LLJIT::deinitialize methods +* Static libraries can now be added to a JITDylib using the + StaticLibraryDefinitionGenerator class -Changes to the MIPS Target --------------------------- +* A C API has been added for OrcV2 (llvm-project/llvm/include/llvm-c/Orc.h) -* Improved support for ``octeon`` and added support for ``octeon+`` - MIPS-family CPU. +* Several OrcV2 example projects have been added to + llvm-project/llvm/examples/OrcV2Examples -* ``min``, ``max``, ``umin``, ``umax`` atomics now supported on MIPS targets. +* Many bug fixes and API improvements -* Now PC-relative relocations are generated for ``.eh_frame`` sections when - possible. That allows to link MIPS binaries without having to pass the - ``-Wl,-z,notext`` option. - -* Fix evaluating J-format branch (``j``, ``jal``, ...) targets when the - instruction is not in the first 256 MB region. +Changes to the AArch64 Backend +------------------------------ -* Fixed ``jal``, ``sc``, ``scs``, ``ll``, ``lld``, ``la``, ``lw``, ``sw`` - instructions expanding. Now they accept more types of expression as arguments, - correctly handle load/store for ``XGOT`` model, expand using less instructions - or registers. +* Back up and restore x18 in functions with windows calling convention on + non-windows OSes. -* Initial MIPS support has been added to ``llvm-exegesis``. +* Clearly error out on unsupported relocations when targeting COFF, instead + of silently accepting some (without being able to do what was requested). -* Generates ``_mcount`` calls using proper MIPS ABI. +* Implemented codegen support for the SVE C-language intrinsics + documented in `Arm C Language Extensions (ACLE) for SVE + `_ (version + ``00bet5``). For more information, see the ``clang`` 11 release + notes. -* Improved support of GlobalISel instruction selection framework. This feature - is still in experimental state for MIPS targets though. +* Added support for Armv8.6-A: -Changes to the PowerPC Target ------------------------------ + Assembly support for the following extensions: -Optimization: + - Enhanced Counter Virtualization (ARMv8.6-ECV). + - Fine Grained Traps (ARMv8.6-FGT). + - Activity Monitors virtualization (ARMv8.6-AMU). + - Data gathering hint (ARMv8.0-DGH). -* Improved register pressure estimates in the loop vectorizer based on type + Assembly and intrinsics support for the Armv8.6-A Matrix Multiply extension + for Neon and SVE vectors. -* Improved the PowerPC cost model for the vectorizer + Support for the ARMv8.2-BF16 BFloat16 extension. This includes a new C-level + storage-only `__bf16` type, a `BFloat` IR type, a `bf16` MVT, and assembly + and intrinsics support. -* Enabled vectorization of math routines on PowerPC using MASSV (Mathematical Acceleration SubSystem) library +* Added support for Cortex-A34, Cortex-A77, Cortex-A78 and Cortex-X1 cores. -compiler-rt: +Changes to the ARM Backend +-------------------------- -* Added/improved conversion functions from IBM long double to 128-bit integers +* Implemented C-language intrinsics for the full Arm v8.1-M MVE instruction + set. ```` now supports the complete API defined in the Arm C + Language Extensions. -Codegen: +* Added support for assembly for the optional Custom Datapath Extension (CDE) + for Arm M-profile targets. -* Optimized memory access instructions in loops (pertaining to update-form instructions and address computation) +* Implemented C-language intrinsics ```` for the CDE instruction set. -* Added options to disable hoisting instructions to hotter blocks based on statically or profile-based block hotness estimates +* Clang now defaults to ``-fomit-frame-pointer`` when targeting non-Android + Linux for arm and thumb when optimizations are enabled. Users that were + previously not specifying a value and relying on the implicit compiler + default may wish to specify ``-fno-omit-frame-pointer`` to get the old + behavior. This improves compatibility with GCC. -* Code generation improvements (particularly with floating point and vector code as well as handling condition registers) +* Added support for Armv8.6-A: -* Various infrastructural improvements, code refactoring, and bug fixes + Assembly and intrinsics support for the Armv8.6-A Matrix Multiply extension + for Neon vectors. -* Optimized handling of control flow based on multiple comparison of same values + Support for the ARMv8.2-AA32BF16 BFloat16 extension. This includes a new + C-level storage-only `__bf16` type, a `BFloat` IR type, a `bf16` MVT, and + assembly and intrinsics support. -Tools: +* Added support for CMSE. -* llvm-readobj supports displaying file header, section headers, symbol table and relocation entries for XCOFF object files +* Added support for Cortex-M55, Cortex-A77, Cortex-A78 and Cortex-X1 cores. -* llvm-objdump supports disassembling physical sections for XCOFF object files +* The Machine Outliner is now supported for ARM and Thumb2, it is not + turned on by default and can be enabled with the ``-moutline`` clang flag. -Changes to the SystemZ Target +Changes to the PowerPC Target ----------------------------- -* Added support for the ``-march=z15`` and ``-mtune=z15`` command line options - (as aliases to the existing ``-march=arch13`` and ``-mtune=arch13`` options). - -* Added support for the ``-march=native`` command line option. +Optimization: -* Added support for the ``-mfentry``, ``-mnop-mcount``, and ``-mrecord-mcount`` - command line options. +* Improved Loop Unroll-and-Jam legality checks, allowing it to handle more than two level loop nests +* Improved Loop Unroll to be able to unroll more loops +* Implemented an option to allow loop fusion to work on loops with different constant trip counts -* Added support for the GHC calling convention. +Codegen: -* Miscellaneous codegen enhancements, in particular to enable better - reuse of condition code values and improved use of conditional - move instructions. +* POWER10 support -Changes to the X86 Target -------------------------- + * Added PC Relative addressing + * Added __int128 vector bool support -* Less-than-128-bit vector types, v2i32, v4i16, v2i16, v8i8, v4i8, and v2i8, are - now stored in the lower bits of an xmm register and the upper bits are - undefined. Previously the elements were spread apart with undefined bits in - between them. +* Security enhancement via probe-stack attribute support to protect against stack clash +* Floating point support enhancements -* v32i8 and v64i8 vectors with AVX512F enabled, but AVX512BW disabled will now - be passed in ZMM registers for calls and returns. Previously they were passed - in two YMM registers. Old behavior can be enabled by passing - ``-x86-enable-old-knl-abi``. + * Improved half precision and quad precision support, including GLIBC + * constrained FP operation support for arithmetic/rounding/max/min + * cleaning up fast math flags checks in DAGCombine, Legalizer, and Lowering -* ``-mprefer-vector-width=256`` is now the default behavior skylake-avx512 and - later Intel CPUs. This tries to limit the use of 512-bit registers which can - cause a decrease in CPU frequency on these CPUs. This can be re-enabled by - passing ``-mprefer-vector-width=512`` to clang or passing - ``-mattr=-prefer-256-bit`` to llc. +* Performance improvements from instruction exploitation, especially for vector permute on LE +* Scheduling enhancements -* Deprecated the mpx feature flag for the Intel MPX instructions. There were no - intrinsics for this feature. This change only this effects the results - returned by getHostCPUFeatures on CPUs that implement the MPX instructions. + * Added MacroFusion for POWER8 + * Added post-ra heuristics for POWER9 -* The feature flag fast-partial-ymm-or-zmm-write which previously disabled - vzeroupper insertion has been removed. It has been replaced with a vzeroupper - feature flag which has the opposite polarity. So -vzeroupper has the same - effect as +fast-partial-ymm-or-zmm-write. +* Target dependent passes tuning + * Updated LoopStrengthReduce to use instruction number as first priority + * Enhanced MachineCombiner to expose more ILP -Changes to the WebAssembly Target ---------------------------------- - -* ``__attribute__((used))`` no longer implies that a symbol is exported, for - consistency with other targets. +* Code quality and maintenance enhancements -* Multivalue function signatures are now supported in WebAssembly object files + * Enabled more machine verification passes + * Added ability to parse and emit additional extended mnemonics + * Numerous bug fixes -* The new ``atomic.fence`` instruction is now supported +AIX Support Improvements: -* Thread-Local Storage (TLS) is now supported. +* Enabled compile and link such that a simple "Hello World" program works with standard headers +* Added support for the C calling convention for non-vector code +* Implemented correct stack frame layout for functions +* In llvm-objdump, added support for relocations, improved selection of symbol labels, and added the --symbol-description option -* SIMD support is significantly expanded. - -Changes to the Windows Target ------------------------------ - -* Fixed section relative relocations in .debug_frame in DWARF debug info Changes to the RISC-V Target ---------------------------- -New Features: - -* The Machine Outliner is now supported, but not enabled by default. - -* Shrink-wrapping is now supported. - -* The Machine Scheduler has been enabled and scheduler descriptions for the - Rocket micro-architecture have been added, covering both 32- and 64-bit Rocket - cores. - -* This release lays the groundwork for enabling LTO in a future LLVM release. - In particular, LLVM now uses a new ``target-abi`` module metadata item to - represent the chosen RISC-V psABI variant. Frontends should add this module - flag to prevent ABI lowering problems when LTO is enabled in a future LLVM - release. - -* Support has been added for assembling RVC HINT instructions. - -* Added code lowering for half-precision floats. - -* The ``fscsr`` and ``frcsr`` (``fssr``, ``frsr``) obsolete aliases have been added to - the assembler for use in legacy code. - -* The stack can now be realigned even when there are variable-sized objects in - the same frame. - -* fastcc is now supported. This is a more efficient, unstandardised, calling - convention for calls to private leaf functions in the same IR module. - -* llvm-objdump now supports ``-M no-aliases`` and ``-M numeric`` for altering the - dumped assembly. These match the behaviour of GNU objdump, respectively - disabling instruction aliases and printing the numeric register names rather - than the ABI register names. +New features: + +* After consultation through an RFC, the RISC-V backend now accepts patches for + proposed instruction set extensions that have not yet been ratified. For these + experimental extensions, there is no expectation of ongoing support - the + compiler support will continue to change until the specification is finalised. + In line with this policy, MC layer and code generation support was added for + version 0.92 of the proposed Bit Manipulation Extension and MC layer support + was added for version 0.8 of the proposed RISC-V Vector instruction set + extension. As these extensions are not yet ratified, compiler support will + continue to change to match the specifications until they are finalised. +* ELF attribute sections are now created, encoding information such as the ISA + string. +* Support for saving/restoring callee-saved registers via libcalls (a code + size optimisation). +* llvm-objdump will now print branch targets as part of disassembly. Improvements: -* Trap and Debugtrap now lower to RISC-V-specific trap instructions. - -* LLVM IR Inline assembly now supports using ABI register names and using - floating point registers in constraints. - -* Stack Pointer adjustments have been changed to better match RISC-V's immediates. - -* ``ra`` (``x1``) can now be used as a callee-saved register. - -* The assembler now suggests spelling corrections for unknown assembly - mnemonics. - -* Stack offsets of greater than 32-bits are now accepted on RV64. - -* Variadic functions can now be tail-call optimised, as long as they do not use - stack memory for passing arguments. - -* Code generation has been changed for 32-bit arithmetic operations on RV64 to - reduce sign-extensions. +* If an immediate can be generated using a pair of `addi` instructions, that + pair will be selected rather than materialising the immediate into a + separate register with an `lui` and `addi` pair. +* Multiplication by a constant was optimised. +* `addi` instructions are now folded into the offset of a load/store instruction + even if the load/store itself has a non-zero offset, when it is safe to do + so. +* Additional target hooks were implemented to minimise generation of + unnecessary control flow instruction. +* The RISC-V backend's load/store peephole optimisation pass now supports + constant pools, improving code generation for floating point constants. +* Debug scratch register names `dscratch0` and `dscratch1` are now recognised in + addition to the legacy `dscratch` register name. +* Codegen for checking isnan was improved, removing a redundant `and`. +* The `dret` instruction is now supported by the MC layer. +* `.option pic` and `.option nopic` are now supported in assembly and `.reloc` + was extended to support arbitrary relocation types. +* Scheduling info metadata was improved. +* The `jump` pseudo instruction is now supported. + +Bug fixes: + +* A failure to insert indirect branches in position independent code + was fixed. +* The calculated expanded size of atomic pseudo operations was fixed, avoiding + "fixup value out of range" errors during branch relaxation for some inputs. +* The `mcountinhibit` CSR is now recognised. +* The correct libcall is now emitted for converting a float/double to a 32-bit + signed or unsigned integer on RV64 targets lacking the F or D extensions. -Bug Fixes: +Changes to the SystemZ Target +----------------------------- -* There was an issue with register preservation after calls in interrupt - handlers, where some registers were marked as preserved even though they were - not being preserved by the call. This has been corrected, and now only - callee-saved registers are live over a function call in an interrupt handler - (just like calls in regular functions). +* Added support for the MemorySanitizer and the LeakSanitizer. +* Added support for the ``-fstack-clash-protection`` command line option. +* Enhanced the assembler parser to allow using `%r0` even in an address + register context, and to allow specifying registers using plain integer + numbers instead of register names everywhere. +* Fixed wrong code generation violating the platform ABI when passing + a C++ class (not struct) type having only a single member of + floating-point type. +* Fixed wrong code generation when using the `vec_store_len_r` or + `vec_load_len_r` intrinsics with an immediate length argument of + 16 or larger. +* Miscellaneous codegen enhancements, in particular to improve vector code. -* Atomic instructions now only accept GPRs (plus an offset) in memory operands. +Changes to the X86 Target +------------------------- -* Fixed some issues with evaluation of relocations and fixups. +* Functions with the probe-stack attribute set to "inline-asm" are now protected + against stack clash without the need of a third-party probing function and + with limited impact on performance. +* -x86-enable-old-knl-abi command line switch has been removed. v32i16/v64i8 + vectors are always passed in ZMM register when avx512f is enabled and avx512bw + is disabled. +* Vectors larger than 512 bits with i16 or i8 elements will be passed in + multiple ZMM registers when avx512f is enabled. Previously this required + avx512bw otherwise they would split into multiple YMM registers. This means + vXi16/vXi8 vectors are consistently treated the same as + vXi32/vXi64/vXf64/vXf32 vectors of the same total width. +* Support was added for Intel AMX instructions. +* Support was added for TSXLDTRK instructions. +* A pass was added for mitigating the Load Value Injection vulnerability. +* The Speculative Execution Side Effect Suppression pass was added which can + be used to as a last resort mitigation for speculative execution related + CPU vulnerabilities. +* Improved recognition of boolean vector reductions with better MOVMSKB/PTEST + handling +* Exteded recognition of rotation patterns to handle funnel shift as well, + allowing us to remove the existing x86-specific SHLD/SHRD combine. + +Changes to the AMDGPU Target +----------------------------- -* The error messages around missing RISC-V extensions in the assembler have been - improved. +* The backend default denormal handling mode has been switched to on + for all targets for all compute function types. Frontends wishing to + retain the old behavior should explicitly request f32 denormal + flushing. -* The error messages around unsupported relocations have been improved. +Changes to the AVR Target +----------------------------- -* Non-PIC code no longer forces Local Exec TLS. +* Moved from an experimental backend to an official backend. AVR support is now + included by default in all LLVM builds and releases and is available under + the "avr-unknown-unknown" target triple. -* There have been some small changes to the code generation for atomic - operations. +Changes to the WebAssembly Target +--------------------------------- -* RISC-V no longer emits incorrect CFI directives in function prologues and - epilogues. +* Programs which don't have a "main" function, called "reactors" are now + properly supported, with a new `-mexec-model=reactor` flag. Programs which + previously used `-Wl,--no-entry` to avoid having a main function should + switch to this new flag, so that static initialization is properly + performed. -* RV64 no longer clears the upper bits when returning complex types from - libcalls using the LP64 psABI. +* `__attribute__((visibility("protected")))` now evokes a warning, as + WebAssembly does not support "protected" visibility. -Compiler-RT: +Changes to the Windows Target +----------------------------- -* RISC-V (both 64-bit and 32-bit) is now supported by compiler-rt, allowing - crtbegin and crtend to be built. +* Produce COFF weak external symbols for IR level weak symbols without a comdat + (e.g. for `__attribute__((weak))` in C) -* The Sanitizers now support 64-bit RISC-V on Linux. +Changes to the DAG infrastructure +--------------------------------- +* A SelDag-level freeze instruction has landed. It is simply lowered as a copy + operation to MachineIR, but to make it fully correct either IMPLICIT_DEF + should be fixed or the equivalent FREEZE operation should be added to + MachineIR. -Changes to the C API --------------------- -* C DebugInfo API ``LLVMDIBuilderCreateTypedef`` is updated to include an extra - argument ``AlignInBits``, to facilitate / propagate specified Alignment information - present in a ``typedef`` to Debug information in LLVM IR. +Changes to the Debug Info +------------------------- +* LLVM now supports the debug entry values (DW_OP_entry_value) production for + the x86, ARM, and AArch64 targets by default. Other targets can use + the utility by using the experimental option ("-debug-entry-values"). + This is a debug info feature that allows debuggers to recover the value of + optimized-out parameters by going up a stack frame and interpreting the values + passed to the callee. The feature improves the debugging user experience when + debugging optimized code. -Changes to the Go bindings +Changes to the Gold Plugin -------------------------- -* Go DebugInfo API ``CreateTypedef`` is updated to include an extra argument ``AlignInBits``, - to facilitate / propagate specified Alignment information present in a ``typedef`` - to Debug information in LLVM IR. - - - -Changes to LLDB -=============== -* Improved support for building with MinGW +* ``--plugin-opt=whole-program-visibility`` is added to specify that classes have hidden LTO visibility in LTO and ThinLTO links of source files compiled with ``-fwhole-program-vtables``. See `LTOVisibility `_ for details. + (`D71913 `_) -* Initial support for debugging Windows ARM and ARM64 binaries - -* Improved error messages in the expression evaluator. +Changes to the LLVM tools +--------------------------------- -* Tab completions for command options now also provide a description for each option. +* Added an option (--show-section-sizes) to llvm-dwarfdump to show the sizes + of all debug sections within a file. -* Fixed that printing structs/classes with the ``expression`` command sometimes did not - print the members/contents of the class. +* llvm-nm now implements the flag ``--special-syms`` and will filter out special + symbols, i.e. mapping symbols on ARM and AArch64, by default. This matches + the GNU nm behavior. -* Improved support for using classes with bit-field members in the expression evaluator. +* llvm-rc now tolerates -1 as menu item ID, supports the language id option + and allows string table values to be split into multiple string literals -* Greatly improved support for DWARF v5. +* llvm-lib supports adding import library objects in addition to regular + object files -External Open Source Projects Using LLVM 10 +External Open Source Projects Using LLVM 11 =========================================== Zig Programming Language ------------------------ -`Zig `_ is a system programming language intended to be -an alternative to C. It provides high level features such as generics, compile -time function execution, and partial evaluation, while exposing low level LLVM -IR features such as aliases and intrinsics. Zig uses Clang to provide automatic -import of .h symbols, including inline functions and simple macros. Zig uses -LLD combined with lazily building compiler-rt to provide out-of-the-box -cross-compiling for all supported targets. - - +`Zig `_ is a general-purpose programming language and +toolchain for maintaining robust, optimal, and reusable software. In addition +to supporting LLVM as an optional backend, Zig links Clang and LLD to provide +an out-of-the-box cross compilation experience, not only for Zig code but for +C and C++ code as well. Using a sophisticated caching system, Zig lazily builds +from source compiler-rt, mingw-w64, musl, glibc, libcxx, libcxxabi, and +libunwind for the selected target - a "batteries included" drop-in for GCC/Clang +that works the same on every platform. Additional Information ====================== @@ -401,7 +406,7 @@ Additional Information A wide variety of additional information is available on the `LLVM web page `_, in particular in the `documentation `_ section. The web page also contains versions of the -API documentation which is up-to-date with the Subversion version of the source +API documentation which is up-to-date with the Git version of the source code. You can access versions of these documents specific to this release by going into the ``llvm/docs/`` directory in the LLVM tree. diff --git a/gnu/llvm/llvm/docs/ReleaseProcess.rst b/gnu/llvm/llvm/docs/ReleaseProcess.rst index 0cd455fdb79..69a209cbc66 100644 --- a/gnu/llvm/llvm/docs/ReleaseProcess.rst +++ b/gnu/llvm/llvm/docs/ReleaseProcess.rst @@ -115,7 +115,7 @@ Test Suite :local: Follow the `LNT Quick Start Guide -`__ link on how to set-up the +`__ link on how to set-up the test-suite The binary location you'll have to use for testing is inside the @@ -160,7 +160,7 @@ candidates, on the previous release. You should: * Download the previous release sources from - http://llvm.org/releases/download.html. + https://llvm.org/releases/download.html. * Run the test-release.sh script on ``final`` mode (change ``-rc 1`` to ``-final``). @@ -190,7 +190,7 @@ to them), and run the release test as above. You should: * Download the current candidate sources from where the release manager points - you (ex. http://llvm.org/pre-releases/3.3/rc1/). + you (ex. https://llvm.org/pre-releases/3.3/rc1/). * Repeat the steps above with ``-rc 1``, ``-rc 2`` etc modes and run the test-suite the same way. @@ -204,7 +204,7 @@ and that will be the official binary. * Rename (or link) ``clang+llvm-REL-ARCH-ENV`` to the .install directory -* Tar that into the same name with ``.tar.gz`` extensioan from outside the +* Tar that into the same name with ``.tar.gz`` extension from outside the directory * Make it available for the release manager to download diff --git a/gnu/llvm/llvm/docs/Remarks.rst b/gnu/llvm/llvm/docs/Remarks.rst index 653b418e6fd..b6cec12b326 100644 --- a/gnu/llvm/llvm/docs/Remarks.rst +++ b/gnu/llvm/llvm/docs/Remarks.rst @@ -612,6 +612,38 @@ The typical usage through the C API is like the following: bool HasError = LLVMRemarkParserHasError(Parser); LLVMRemarkParserDispose(Parser); +Remark streamers +================ + +The ``RemarkStreamer`` interface is used to unify the serialization +capabilities of remarks across all the components that can generate remarks. + +All remark serialization should go through the main remark streamer, the +``llvm::remarks::RemarkStreamer`` set up in the ``LLVMContext``. The interface +takes remark objects converted to ``llvm::remarks::Remark``, and takes care of +serializing it to the requested format, using the requested type of metadata, +etc. + +Typically, a specialized remark streamer will hold a reference to the one set +up in the ``LLVMContext``, and will operate on its own type of diagnostics. + +For example, LLVM IR passes will emit ``llvm::DiagnosticInfoOptimization*`` +that get converted to ``llvm::remarks::Remark`` objects. Then, clang could set +up its own specialized remark streamer that takes ``clang::Diagnostic`` +objects. This can allow various components of the frontend to emit remarks +using the same techniques as the LLVM remarks. + +This gives us the following advantages: + +* Composition: during the compilation pipeline, multiple components can set up + their specialized remark streamers that all emit remarks through the same + main streamer. +* Re-using the remark infrastructure in ``lib/Remarks``. +* Using the same file and format for the remark emitters created throughout the + compilation. + +at the cost of an extra layer of abstraction. + .. FIXME: add documentation for llvm-opt-report. .. FIXME: add documentation for Passes supporting optimization remarks .. FIXME: add documentation for IR Passes diff --git a/gnu/llvm/llvm/docs/ReportingGuide.rst b/gnu/llvm/llvm/docs/ReportingGuide.rst index f7ecbb38d45..ad2a035e864 100644 --- a/gnu/llvm/llvm/docs/ReportingGuide.rst +++ b/gnu/llvm/llvm/docs/ReportingGuide.rst @@ -102,7 +102,7 @@ appropriateness of our response, but we don't guarantee we'll act on it. After any incident, the advisory committee will make a report on the situation to the LLVM Foundation board. The board may choose to make a public statement about the incident. If that's the case, the identities of anyone involved will -remain confidential unless instructed by those inviduals otherwise. +remain confidential unless instructed by those individuals otherwise. Appealing ========= @@ -114,7 +114,7 @@ the case. In general, it is **not** appropriate to appeal a particular decision on a public mailing list. Doing so would involve disclosure of information which -whould be confidential. Disclosing this kind of information publicly may be +would be confidential. Disclosing this kind of information publicly may be considered a separate and (potentially) more serious violation of the Code of Conduct. This is not meant to limit discussion of the Code of Conduct, the advisory board itself, or the appropriateness of responses in general, but diff --git a/gnu/llvm/llvm/docs/Security.rst b/gnu/llvm/llvm/docs/Security.rst new file mode 100644 index 00000000000..62085cc1c20 --- /dev/null +++ b/gnu/llvm/llvm/docs/Security.rst @@ -0,0 +1,220 @@ +=================== +LLVM Security Group +=================== + +The LLVM Security Group has the following goals: + +1. Allow LLVM contributors and security researchers to disclose security-related issues affecting the LLVM project to members of the LLVM community. +2. Organize fixes, code reviews, and release management for said issues. +3. Allow distributors time to investigate and deploy fixes before wide dissemination of vulnerabilities or mitigation shortcomings. +4. Ensure timely notification and release to vendors who package and distribute LLVM-based toolchains and projects. +5. Ensure timely notification to users of LLVM-based toolchains whose compiled code is security-sensitive, through the `CVE process`_. +6. Strive to improve security over time, for example by adding additional testing, fuzzing, and hardening after fixing issues. + +*Note*: these goals ensure timely action, provide disclosure timing when issues are reported, and respect vendors' / packagers' / users' constraints. + +The LLVM Security Group is private. It is composed of trusted LLVM contributors. Its discussions remain within the Security Group (plus issue reporter and key experts) while an issue is being investigated. After an issue becomes public, the entirety of the group’s discussions pertaining to that issue also become public. + + +Group Composition +================= + +Security Group Members +---------------------- + +The members of the group represent a wide cross-section of the community, and meet the criteria for inclusion below. + +* Akila Srinivasan (Apple) +* Dimitry Andric (invidual; FreeBSD) +* Ed Maste (individual; FreeBSD) +* JF Bastien (Apple) +* Josh Eads (Sony) +* Kristof Beyls (ARM) +* Matthew Riley (Google) +* Oliver Hunt (Apple) +* Paul Robinson (Sony) +* Peter Smith (ARM) +* Philip Reames (Azul Systems Inc) +* Pietro Albini (individual; Rust) +* Serge Guelton (RedHat) +* Shayne Hiet-Block (Microsoft) +* Steve Klabnik (Oxide Computer Company; Rust) + +Criteria +-------- + +* Nominees for LLVM Security Group membership should fall in one of these groups: + + - Individual contributors: + + + Specializes in fixing compiler-based security related issues or often participates in their exploration and resolution. + + Has a track record of finding security vulnerabilities and responsible disclosure of those vulnerabilities. + + Is a compiler expert who has specific interests in knowing about, resolving, and preventing future security vulnerabilities. + + Has actively contributed non-trivial code to the LLVM project in the last year. + + - Researchers: + + + Has a track record of finding security vulnerabilities and responsible disclosure of those vulnerabilities. + + Is a compiler expert who has specific interests in knowing about, resolving, and preventing future security vulnerabilities. + + - Vendor contacts: + + + Represents an organization or company which ships products that include their own copy of LLVM. Due to their position in the organization, the nominee has a reasonable need to know about security issues and disclosure embargoes. + +* Additionally, the following are necessary but not sufficient criteria for membership in the LLVM Security Group: + + - If already in the LLVM Security Group, has actively participated in one (if any) security issue in the last year. + - If already in the LLVM Security Group, has actively participated in most membership discussions in the last year. + - If already in the LLVM Security Group, has actively participated in writing or reviewing a transparency report in the last year. + - When employed by a company or other entity, the parent entity has no more than three members already in the LLVM Security Group. + - When nominated as a vendor contact, their position with that vendor remains the same as when originally nominated. + - Nominees are trusted by existing Security Group members to keep communications embargoed while still active. + +Nomination process +------------------ + +Anyone who feels they meet these criteria can nominate themselves, or may be nominated by a third party such as an existing LLVM Security Group member. The nomination should state whether the nominee is nominated as an individual, researcher, or as a vendor contact. It should clearly describe the grounds for nomination. + +*FUTURE*: where nomination occurs (mailing list, GitHub, etc), can be decided later. See `Discussion Medium`_ below. + + +Choosing new members +-------------------- + +If a nomination for LLVM Security Group membership is supported by a majority of existing LLVM Security Group members, then it carries within five business days unless an existing member of the Security Group objects. If an objection is raised, the LLVM Security Group members should discuss the matter and try to come to consensus; failing this, the nomination will succeed only by a two-thirds supermajority vote of the LLVM Security Group. + +Accepting membership +-------------------- + +Before new LLVM Security Group membership is finalized, the successful nominee should accept membership and agree to abide by this security policy, particularly `Privileges and Responsibilities of LLVM Security Group Members`_ below. + +Keeping Membership Current +-------------------------- + +* At least every six months, the LLVM Security Group applies the above criteria. The membership list is pruned accordingly. +* Any Security Group member can ask that the criteria be applied within the next five business days. +* If a member of the LLVM Security Group does not act in accordance with the letter and spirit of this policy, then their LLVM Security Group membership can be revoked by a majority vote of the members, not including the person under consideration for revocation. After a member calls for a revocation vote, voting will be open for five business days. +* Emergency suspension: an LLVM Security Group member who blatantly disregards the LLVM Security Policy may have their membership temporarily suspended on the request of any two members. In such a case, the requesting members should notify the Security Group with a description of the offense. At this point, membership will be temporarily suspended for five business days, pending outcome of the vote for permanent revocation. +* The LLVM Board may remove any member from the LLVM Security Group. + +Transparency Report +------------------- + +Every year, the LLVM Security Group must publish a transparency report. The intent of this report is to keep the community informed by summarizing the disclosures that have been made public in the last year. It shall contain a list of all public disclosures, as well as statistics on time to fix issues, length of embargo periods, and so on. + + +Privileges and Responsibilities of LLVM Security Group Members +============================================================== + +Access +------ + +LLVM Security Group members will be subscribed to a private `Discussion Medium`_ (*FUTURE*: see section below). It will be used for technical discussions of security issues, as well as process discussions about matters such as disclosure timelines and group membership. Members have access to all security issues. + +Confidentiality +--------------- + +Members of the LLVM Security Group will be expected to treat LLVM security issue information shared with the group as confidential until publicly disclosed: + +* Members should not disclose security issue information to non-members unless both members are employed by the same vendor of a LLVM based product, in which case information can be shared within that organization on a need-to-know basis and handled as confidential information normally is within that organization. +* If the LLVM Security Group agrees, designated members may share issues with vendors of non-LLVM based products if their product suffers from the same issue. The non-LLVM vendor should be asked to respect the issue’s embargo date, and to not share the information beyond the need-to-know people within their organization. +* If the LLVM Security Group agrees, key experts can be brought in to help address particular issues. The key expert should be asked to respect the issue’s embargo date, and to not share the information. + +Disclosure +---------- + +Following the process below, the LLVM Security Group decides on embargo date for public disclosure for each Security issue. An embargo may be lifted before the agreed-upon date if all vendors planning to ship a fix have already done so, and if the reporter does not object. + +Collaboration +------------- + +Members of the LLVM Security Group are expected to: + +* Promptly share any LLVM vulnerabilities they become aware of. +* Volunteer to drive issues forward. +* Help evaluate the severity of incoming issues. +* Help write and review patches to address security issues. +* Participate in the member nomination and removal processes. + + +Discussion Medium +================= + +*FUTURE*: this section needs more work! Where discussions occur is influenced by other factors that are still open in this document. We can figure it out later. +See other existing systems: `chromium issue tracker`_, tentative `GitHub security`_. It seems like bugzilla and email don’t meet security requirements. + +The medium used to host LLVM Security Group discussions is security-sensitive. It should therefore run on infrastructure which can meet our security expectations. + +This is where all security discussions occur: + +* File security issues. +* Nominate new members. +* Propose member removal. +* Suggest policy changes. +* Discuss security improvements to LLVM. + + +When a new issue is filed, a template is provided to help issue reporters provide all relevant information. + + +Process +======= + +The following process occurs on the discussion medium for each reported issue: + +* A security issue reporter (not necessarily an LLVM contributor) reports an issue. +* Within two business days, a member of the Security Group is put in charge of driving the issue to an acceptable resolution. This champion doesn’t need to be the same person for each issue. This person can self-nominate. +* Members of the Security Group discuss in which circumstances (if any) an issue is relevant to security, and determine if it is a security issue. +* Negotiate an embargo date for public disclosure, with a default minimum time limit of ninety days. +* Security Group members can recommend that key experts be pulled in to specific issue discussions. The key expert can be pulled in unless there are objections from other Security Group members. +* Patches are written and reviewed. +* Backporting security patches from recent versions to old versions cannot always work. It is up to the Security Group to decide if such backporting should be done, and how far back. +* The Security Group figures out how the LLVM project’s own releases, as well as individual vendors’ releases, can be timed to patch the issue simultaneously. +* Embargo date can be delayed or pulled forward at the Security Group’s discretion. +* The issue champion obtains a CVE entry from MITRE_. +* Once the embargo expires, the patch is posted publicly according to LLVM’s usual code review process. +* All security issues (as well as nomination / removal discussions) become public within approximately fourteen weeks of the fix landing in the LLVM repository. Precautions should be taken to avoid disclosing particularly sensitive data included in the report (e.g. username and password pairs). + + +Changes to the Policy +===================== + +The LLVM Security Policy may be changed by majority vote of the LLVM Security Group. Such changes also need to be approved by the LLVM Board. + + +What is considered a security issue? +==================================== + +*FUTURE*: this section will be expanded once the Security Group is formed, and it agrees on an initial security surface area. + +The LLVM Project has a significant amount of code, and not all of it is considered security-sensitive. This is particularly true because LLVM is used in a wide variety of circumstances: there are different threat models, untrusted inputs differ, and the environment LLVM runs in is varied. Therefore, what the LLVM Project considers a security issue is what its members have signed up to maintain securely. + +As this security process matures, members of the LLVM community can propose that a part of the codebase be designated as security-sensitive (or no longer security-sensitive). This requires a rationale, and buy-in from the LLVM community as for any RFC. In some cases, parts of the codebase could be handled as security-sensitive but need significant work to get to the stage where that's manageable. The LLVM community will need to decide whether it wants to invest in making these parts of the code secure-able, and maintain these security properties over time. In all cases the LLVM Security Group should be consulted, since they'll be responding to security issues filed against these parts of the codebase. + +If you're not sure whether an issue is in-scope for this security process or not, err towards assuming that it is. The Security Group might agree or disagree and will explain its rationale in the report, as well as update this document through the above process. + +The security-sensitive parts of the LLVM Project currently are: + +* None (this process is new, the list hasn't been populated yet) +* *FUTURE*: this section will be expanded. + +The parts of the LLVM Project which are currently treated as non-security sensitive are: + +* Language front-ends, such as clang, for which a malicious input file can cause undesirable behavior. For example, a maliciously-crafter C or Rust source file can cause arbitrary code to execute in LLVM. These parts of LLVM haven't been hardened, and compiling untrusted code usually also includes running utilities such as `make` which can more readily perform malicious things. +* *FUTURE*: this section will be expanded. + +.. _report-security-issue: + +How to report a security issue? +=============================== + +*FUTURE*: this section will be expanded once we’ve figured out other details above. + +Not everyone who wants to report a security issue will be familiar with LLVM, its community, and processes. Therefore, this needs to be easy to find on the LLVM website, and set clear expectations to issue reporters. + + + +.. _CVE process: https://cve.mitre.org +.. _chromium issue tracker: https://crbug.com +.. _GitHub security: https://help.github.com/en/articles/about-maintainer-security-advisories +.. _MITRE: https://cve.mitre.org diff --git a/gnu/llvm/llvm/docs/SourceLevelDebugging.rst b/gnu/llvm/llvm/docs/SourceLevelDebugging.rst index f6db104a075..7944d09dba5 100644 --- a/gnu/llvm/llvm/docs/SourceLevelDebugging.rst +++ b/gnu/llvm/llvm/docs/SourceLevelDebugging.rst @@ -86,11 +86,12 @@ information provides the following guarantees: * LLVM debug information **always provides information to accurately read the source-level state of the program**, regardless of which LLVM - optimizations have been run, and without any modification to the - optimizations themselves. However, some optimizations may impact the - ability to modify the current state of the program with a debugger, such - as setting program variables, or calling functions that have been - deleted. + optimizations have been run. :doc:`HowToUpdateDebugInfo` specifies how debug + info should be updated in various kinds of code transformations to avoid + breaking this guarantee, and how to preserve as much useful debug info as + possible. Note that some optimizations may impact the ability to modify the + current state of the program with a debugger, such as setting program + variables, or calling functions that have been deleted. * As desired, LLVM optimizations can be upgraded to be aware of debugging information, allowing them to update the debugging information as they @@ -1006,13 +1007,13 @@ Given a class declaration with copy constructor declared as deleted: foo(const foo&) = deleted; }; -A C++ frontend would generate follwing: +A C++ frontend would generate following: .. code-block:: text !17 = !DISubprogram(name: "foo", scope: !11, file: !1, line: 5, type: !18, scopeLine: 5, flags: DIFlagPublic | DIFlagPrototyped, spFlags: DISPFlagDeleted) -and this will produce an additional DWARF attibute as: +and this will produce an additional DWARF attribute as: .. code-block:: text @@ -1993,180 +1994,3 @@ Improving LLVM's CodeView support is a process of finding interesting type records, constructing a C++ test case that makes MSVC emit those records, dumping the records, understanding them, and then generating equivalent records in LLVM's backend. - -Testing Debug Info Preservation in Optimizations -================================================ - -The following paragraphs are an introduction to the debugify utility -and examples of how to use it in regression tests to check debug info -preservation after optimizations. - -The ``debugify`` utility ------------------------- - -The ``debugify`` synthetic debug info testing utility consists of two -main parts. The ``debugify`` pass and the ``check-debugify`` one. They are -meant to be used with ``opt`` for development purposes. - -The first applies synthetic debug information to every instruction of the module, -while the latter checks that this DI is still available after an optimization -has occurred, reporting any errors/warnings while doing so. - -The instructions are assigned sequentially increasing line locations, -and are immediately used by debug value intrinsics when possible. - -For example, here is a module before: - -.. code-block:: llvm - - define void @f(i32* %x) { - entry: - %x.addr = alloca i32*, align 8 - store i32* %x, i32** %x.addr, align 8 - %0 = load i32*, i32** %x.addr, align 8 - store i32 10, i32* %0, align 4 - ret void - } - -and after running ``opt -debugify`` on it we get: - -.. code-block:: text - - define void @f(i32* %x) !dbg !6 { - entry: - %x.addr = alloca i32*, align 8, !dbg !12 - call void @llvm.dbg.value(metadata i32** %x.addr, metadata !9, metadata !DIExpression()), !dbg !12 - store i32* %x, i32** %x.addr, align 8, !dbg !13 - %0 = load i32*, i32** %x.addr, align 8, !dbg !14 - call void @llvm.dbg.value(metadata i32* %0, metadata !11, metadata !DIExpression()), !dbg !14 - store i32 10, i32* %0, align 4, !dbg !15 - ret void, !dbg !16 - } - - !llvm.dbg.cu = !{!0} - !llvm.debugify = !{!3, !4} - !llvm.module.flags = !{!5} - - !0 = distinct !DICompileUnit(language: DW_LANG_C, file: !1, producer: "debugify", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2) - !1 = !DIFile(filename: "debugify-sample.ll", directory: "/") - !2 = !{} - !3 = !{i32 5} - !4 = !{i32 2} - !5 = !{i32 2, !"Debug Info Version", i32 3} - !6 = distinct !DISubprogram(name: "f", linkageName: "f", scope: null, file: !1, line: 1, type: !7, isLocal: false, isDefinition: true, scopeLine: 1, isOptimized: true, unit: !0, retainedNodes: !8) - !7 = !DISubroutineType(types: !2) - !8 = !{!9, !11} - !9 = !DILocalVariable(name: "1", scope: !6, file: !1, line: 1, type: !10) - !10 = !DIBasicType(name: "ty64", size: 64, encoding: DW_ATE_unsigned) - !11 = !DILocalVariable(name: "2", scope: !6, file: !1, line: 3, type: !10) - !12 = !DILocation(line: 1, column: 1, scope: !6) - !13 = !DILocation(line: 2, column: 1, scope: !6) - !14 = !DILocation(line: 3, column: 1, scope: !6) - !15 = !DILocation(line: 4, column: 1, scope: !6) - !16 = !DILocation(line: 5, column: 1, scope: !6) - -The following is an example of the -check-debugify output: - -.. code-block:: none - - $ opt -enable-debugify -loop-vectorize llvm/test/Transforms/LoopVectorize/i8-induction.ll -disable-output - ERROR: Instruction with empty DebugLoc in function f -- %index = phi i32 [ 0, %vector.ph ], [ %index.next, %vector.body ] - -Errors/warnings can range from instructions with empty debug location to an -instruction having a type that's incompatible with the source variable it describes, -all the way to missing lines and missing debug value intrinsics. - -Fixing errors -^^^^^^^^^^^^^ - -Each of the errors above has a relevant API available to fix it. - -* In the case of missing debug location, ``Instruction::setDebugLoc`` or possibly - ``IRBuilder::setCurrentDebugLocation`` when using a Builder and the new location - should be reused. - -* When a debug value has incompatible type ``llvm::replaceAllDbgUsesWith`` can be used. - After a RAUW call an incompatible type error can occur because RAUW does not handle - widening and narrowing of variables while ``llvm::replaceAllDbgUsesWith`` does. It is - also capable of changing the DWARF expression used by the debugger to describe the variable. - It also prevents use-before-def by salvaging or deleting invalid debug values. - -* When a debug value is missing ``llvm::salvageDebugInfo`` can be used when no replacement - exists, or ``llvm::replaceAllDbgUsesWith`` when a replacement exists. - -Using ``debugify`` ------------------- - -In order for ``check-debugify`` to work, the DI must be coming from -``debugify``. Thus, modules with existing DI will be skipped. - -The most straightforward way to use ``debugify`` is as follows:: - - $ opt -debugify -pass-to-test -check-debugify sample.ll - -This will inject synthetic DI to ``sample.ll`` run the ``pass-to-test`` -and then check for missing DI. - -Some other ways to run debugify are avaliable: - -.. code-block:: bash - - # Same as the above example. - $ opt -enable-debugify -pass-to-test sample.ll - - # Suppresses verbose debugify output. - $ opt -enable-debugify -debugify-quiet -pass-to-test sample.ll - - # Prepend -debugify before and append -check-debugify -strip after - # each pass on the pipeline (similar to -verify-each). - $ opt -debugify-each -O2 sample.ll - -``debugify`` can also be used to test a backend, e.g: - -.. code-block:: bash - - $ opt -debugify < sample.ll | llc -o - - -``debugify`` in regression tests -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``-debugify`` pass is especially helpful when it comes to testing that -a given pass preserves DI while transforming the module. For this to work, -the ``-debugify`` output must be stable enough to use in regression tests. -Changes to this pass are not allowed to break existing tests. - -It allows us to test for DI loss in the same tests we check that the -transformation is actually doing what it should. - -Here is an example from ``test/Transforms/InstCombine/cast-mul-select.ll``: - -.. code-block:: llvm - - ; RUN: opt < %s -debugify -instcombine -S | FileCheck %s --check-prefix=DEBUGINFO - - define i32 @mul(i32 %x, i32 %y) { - ; DBGINFO-LABEL: @mul( - ; DBGINFO-NEXT: [[C:%.*]] = mul i32 {{.*}} - ; DBGINFO-NEXT: call void @llvm.dbg.value(metadata i32 [[C]] - ; DBGINFO-NEXT: [[D:%.*]] = and i32 {{.*}} - ; DBGINFO-NEXT: call void @llvm.dbg.value(metadata i32 [[D]] - - %A = trunc i32 %x to i8 - %B = trunc i32 %y to i8 - %C = mul i8 %A, %B - %D = zext i8 %C to i32 - ret i32 %D - } - -Here we test that the two ``dbg.value`` instrinsics are preserved and -are correctly pointing to the ``[[C]]`` and ``[[D]]`` variables. - -.. note:: - - Note, that when writing this kind of regression tests, it is important - to make them as robust as possible. That's why we should try to avoid - hardcoding line/variable numbers in check lines. If for example you test - for a ``DILocation`` to have a specific line number, and someone later adds - an instruction before the one we check the test will fail. In the cases this - can't be avoided (say, if a test wouldn't be precise enough), moving the - test to its own file is preferred. diff --git a/gnu/llvm/llvm/docs/SphinxQuickstartTemplate.rst b/gnu/llvm/llvm/docs/SphinxQuickstartTemplate.rst index cd23b61d408..5ebb92affb8 100644 --- a/gnu/llvm/llvm/docs/SphinxQuickstartTemplate.rst +++ b/gnu/llvm/llvm/docs/SphinxQuickstartTemplate.rst @@ -84,7 +84,7 @@ To create a new paragraph, simply insert a blank line. Links ===== -You can format a link `like this `_. A more `sophisticated syntax`_ allows you to place the ``.. _`link text`: `` block +You can format a link `like this `_. A more `sophisticated syntax`_ allows you to place the ``.. _`link text`: `` block pretty much anywhere else in the document. This is useful when linking to especially long URLs. .. _`sophisticated syntax`: http://en.wikipedia.org/wiki/LLVM diff --git a/gnu/llvm/llvm/docs/Statepoints.rst b/gnu/llvm/llvm/docs/Statepoints.rst index 3832a43b287..f55445a1063 100644 --- a/gnu/llvm/llvm/docs/Statepoints.rst +++ b/gnu/llvm/llvm/docs/Statepoints.rst @@ -434,6 +434,8 @@ removed by the backend during dead machine instruction elimination. Intrinsics =========== +.. _gc_statepoint: + 'llvm.experimental.gc.statepoint' Intrinsic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -522,18 +524,17 @@ of the callee. The '# transition args' field indicates how many operands are to be interpreted as 'transition parameters'. The 'deopt parameters' arguments contain an arbitrary list of Values -which is meaningful to the runtime. The runtime may read any of these -values, but is assumed not to modify them. If the garbage collector -might need to modify one of these values, it must also be listed in -the 'gc pointer' argument list. The '# deopt args' field indicates -how many operands are to be interpreted as 'deopt parameters'. +which is meaningful to the runtime. The '# deopt args' field +indicates how many operands are to be interpreted as 'deopt parameters'. The 'gc parameters' arguments contain every pointer to a garbage collector object which potentially needs to be updated by the garbage collector. Note that the argument list must explicitly contain a base pointer for every derived pointer listed. The order of arguments is unimportant. Unlike the other variable length parameter sets, this -list is not length prefixed. +list is not length prefixed. Use of the 'gc parameters' list is +deprecated and will eventually be replaced entirely with the +:ref:`gc-live ` operand bundle. Semantics: """""""""" @@ -614,21 +615,25 @@ safepoint sequence of which this ``gc.relocation`` is a part. Despite the typing of this as a generic token, *only* the value defined by a ``gc.statepoint`` is legal here. -The second argument is an index into the statepoints list of arguments -which specifies the allocation for the pointer being relocated. -This index must land within the 'gc parameter' section of the -statepoint's argument list. The associated value must be within the -object with which the pointer being relocated is associated. The optimizer -is free to change *which* interior derived pointer is reported, provided that -it does not replace an actual base pointer with another interior derived -pointer. Collectors are allowed to rely on the base pointer operand -remaining an actual base pointer if so constructed. - -The third argument is an index into the statepoint's list of arguments -which specify the (potentially) derived pointer being relocated. It -is legal for this index to be the same as the second argument -if-and-only-if a base pointer is being relocated. This index must land -within the 'gc parameter' section of the statepoint's argument list. +The second and third arguments are both indices into operands of their +corresponding statepoint. If the statepoint has a :ref:`gc-live ` +operand bundle, then both arguments are indices into the operand bundle's +operands. If there is no "gc-live" bundle, then the index is into the +statepoint's list of arguments. This index must land within the 'gc +parameter' section of the statepoint's argument list. Use of the "gc-live" +form is recommended. + +The second argument is an index which specifies the allocation for the pointer +being relocated. The associated value must be within the object with which the +pointer being relocated is associated. The optimizer is free to change *which* +interior derived pointer is reported, provided that it does not replace an +actual base pointer with another interior derived pointer. Collectors are +allowed to rely on the base pointer operand remaining an actual base pointer if +so constructed. + +The third argument is an index which specify the (potentially) derived pointer +being relocated. It is legal for this index to be the same as the second +argument if-and-only-if a base pointer is being relocated. Semantics: """""""""" @@ -767,7 +772,7 @@ relocation sequence, including all required ``gc.relocates``. Note that by default, this pass only runs for the "statepoint-example" or "core-clr" gc strategies. You will need to add your custom strategy to this -whitelist or use one of the predefined ones. +list or use one of the predefined ones. As an example, given this code: diff --git a/gnu/llvm/llvm/docs/TableGen/LangRef.rst b/gnu/llvm/llvm/docs/TableGen/LangRef.rst index 74af1ee659f..bb10b43fa0b 100644 --- a/gnu/llvm/llvm/docs/TableGen/LangRef.rst +++ b/gnu/llvm/llvm/docs/TableGen/LangRef.rst @@ -136,13 +136,13 @@ TableGen's top-level production consists of "objects". TemplateArgList: "<" `Declaration` ("," `Declaration`)* ">" A ``class`` declaration creates a record which other records can inherit -from. A class can be parametrized by a list of "template arguments", whose +from. A class can be parameterized by a list of "template arguments", whose values can be used in the class body. A given class can only be defined once. A ``class`` declaration is considered to define the class if any of the following is true: -.. break ObjectBody into its consituents so that they are present here? +.. break ObjectBody into its constituents so that they are present here? #. The :token:`TemplateArgList` is present. #. The :token:`Body` in the :token:`ObjectBody` is present and is not empty. diff --git a/gnu/llvm/llvm/docs/TableGen/index.rst b/gnu/llvm/llvm/docs/TableGen/index.rst index 0697bd0298e..6100c13bea7 100644 --- a/gnu/llvm/llvm/docs/TableGen/index.rst +++ b/gnu/llvm/llvm/docs/TableGen/index.rst @@ -28,7 +28,7 @@ hands the result off to a domain-specific `backend`_ for processing. The current major users of TableGen are :doc:`../CodeGenerator` and the -`Clang diagnostics and attributes `_. +`Clang diagnostics and attributes `_. Note that if you work on TableGen much, and use emacs or vim, that you can find an emacs "TableGen mode" and a vim language file in the ``llvm/utils/emacs`` and diff --git a/gnu/llvm/llvm/docs/TestSuiteGuide.md b/gnu/llvm/llvm/docs/TestSuiteGuide.md index b41d7ec5934..6128636ce5e 100644 --- a/gnu/llvm/llvm/docs/TestSuiteGuide.md +++ b/gnu/llvm/llvm/docs/TestSuiteGuide.md @@ -19,7 +19,7 @@ Quickstart % mkdir venv % virtualenv venv % . venv/bin/activate - % pip install svn+http://llvm.org/svn/llvm-project/llvm/trunk/utils/lit + % pip install svn+https://llvm.org/svn/llvm-project/llvm/trunk/utils/lit % lit --version lit 0.8.0dev ``` @@ -279,7 +279,7 @@ Example usage: LNT is a set of client and server tools for continuously monitoring performance. You can find more information at -[http://llvm.org/docs/lnt](http://llvm.org/docs/lnt). The official LNT instance +[https://llvm.org/docs/lnt](https://llvm.org/docs/lnt). The official LNT instance of the LLVM project is hosted at [http://lnt.llvm.org](http://lnt.llvm.org). @@ -348,7 +348,7 @@ Cross Compilation and External Devices CMake allows to cross compile to a different target via toolchain files. More information can be found here: -- [http://llvm.org/docs/lnt/tests.html#cross-compiling](http://llvm.org/docs/lnt/tests.html#cross-compiling) +- [https://llvm.org/docs/lnt/tests.html#cross-compiling](https://llvm.org/docs/lnt/tests.html#cross-compiling) - [https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html](https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html) @@ -389,7 +389,7 @@ Running the test-suite via LNT The LNT tool can run the test-suite. Use this when submitting test results to an LNT instance. See -[http://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite](http://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite) +[https://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite](https://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite) for details. Running the test-suite via Makefiles (deprecated) diff --git a/gnu/llvm/llvm/docs/TestingGuide.rst b/gnu/llvm/llvm/docs/TestingGuide.rst index 7216c7c838e..c8ee65f132f 100644 --- a/gnu/llvm/llvm/docs/TestingGuide.rst +++ b/gnu/llvm/llvm/docs/TestingGuide.rst @@ -45,7 +45,7 @@ Unit tests ---------- Unit tests are written using `Google Test `_ -and `Google Mock `_ +and `Google Mock `_ and are located in the ``llvm/unittests`` directory. Regression tests @@ -129,7 +129,7 @@ in release mode, i.e. % cmake -DCMAKE_BUILD_TYPE="Release" -DLLVM_ENABLE_ASSERTIONS=On -If you have `Clang `_ checked out and built, you +If you have `Clang `_ checked out and built, you can run the LLVM and Clang tests simultaneously using: .. code-block:: bash @@ -556,7 +556,7 @@ RUN lines: output affects test results. It's usually easy to tell: just look for redirection or piping of the ``FileCheck`` call's stdout or stderr. -To add more substituations, look at ``test/lit.cfg`` or ``lit.local.cfg``. +To add more substitutions, look at ``test/lit.cfg`` or ``lit.local.cfg``. Options @@ -593,7 +593,7 @@ To make the output more useful, :program:`lit` will scan the lines of the test case for ones that contain a pattern that matches ``PR[0-9]+``. This is the syntax for specifying a PR (Problem Report) number that is related to the test case. The number after "PR" specifies the -LLVM bugzilla number. When a PR number is specified, it will be used in +LLVM Bugzilla number. When a PR number is specified, it will be used in the pass/fail reporting. This is useful to quickly get some context when a test fails. diff --git a/gnu/llvm/llvm/docs/TransformMetadata.rst b/gnu/llvm/llvm/docs/TransformMetadata.rst index 68649424b71..817b41b4371 100644 --- a/gnu/llvm/llvm/docs/TransformMetadata.rst +++ b/gnu/llvm/llvm/docs/TransformMetadata.rst @@ -343,7 +343,7 @@ all of the aforementioned output loops. It is recommended to add ``llvm.loop.disable_nonforced`` to ``llvm.loop.distribute.followup_fallback``. This avoids that the -fallback version (which is likely never executed) is further optimzed +fallback version (which is likely never executed) is further optimized which would increase the code size. Versioning LICM diff --git a/gnu/llvm/llvm/docs/TypeMetadata.rst b/gnu/llvm/llvm/docs/TypeMetadata.rst index 7d0745b9279..74d43941149 100644 --- a/gnu/llvm/llvm/docs/TypeMetadata.rst +++ b/gnu/llvm/llvm/docs/TypeMetadata.rst @@ -29,7 +29,7 @@ or functions. An intrinsic, :ref:`llvm.type.test `, is used to test whether a given pointer is associated with a type identifier. -.. _control flow integrity: http://clang.llvm.org/docs/ControlFlowIntegrity.html +.. _control flow integrity: https://clang.llvm.org/docs/ControlFlowIntegrity.html Representing Type Information using Type Metadata ================================================= @@ -160,7 +160,7 @@ as the former will be the jump table entry if a jump table is necessary. The `GlobalLayoutBuilder`_ class is responsible for laying out the globals efficiently to minimize the sizes of the underlying bitsets. -.. _control flow integrity design document: http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html +.. _control flow integrity design document: https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html :Example: diff --git a/gnu/llvm/llvm/docs/UserGuides.rst b/gnu/llvm/llvm/docs/UserGuides.rst index 16437783603..6e4329128fa 100644 --- a/gnu/llvm/llvm/docs/UserGuides.rst +++ b/gnu/llvm/llvm/docs/UserGuides.rst @@ -2,7 +2,7 @@ User Guides =========== NOTE: If you are a user who is only interested in using an LLVM-based compiler, -you should look into `Clang `_ instead. The +you should look into `Clang `_ instead. The documentation here is intended for users who have a need to work with the intermediate LLVM representation. @@ -35,6 +35,7 @@ intermediate LLVM representation. HowToBuildWithPGO HowToCrossCompileBuiltinsOnArm HowToCrossCompileLLVM + HowToUpdateDebugInfo LinkTimeOptimization LoopTerminology MarkdownQuickstartTemplate @@ -71,7 +72,7 @@ Clang `How to build the C, C++, ObjC, and ObjC++ front end`__ Instructions for building the clang front-end from source. - .. __: http://clang.llvm.org/get_started.html + .. __: https://clang.llvm.org/get_started.html :doc:`CoverageMappingFormat` This describes the format and encoding used for LLVM’s code coverage mapping. @@ -95,7 +96,10 @@ LLVM Builds and Distributions :doc:`Support Library ` This document describes the LLVM Support Library (``lib/Support``) and - how to keep LLVM source code portable + how to keep LLVM source code portable. + +:doc:`AdvancedBuilds` + This document describes more advanced build configurations. Optimizations ------------- @@ -192,4 +196,8 @@ Additional Topics This document describes using the NVPTX backend to compile GPU kernels. :doc:`AMDGPUUsage` - This document describes using the AMDGPU backend to compile GPU kernels. \ No newline at end of file + This document describes using the AMDGPU backend to compile GPU kernels. + +:doc:`AMDGPUDwarfProposalForHeterogeneousDebugging` + This document describes a DWARF proposal to support heterogeneous debugging + for targets such as the AMDGPU backend. diff --git a/gnu/llvm/llvm/docs/Vectorizers.rst b/gnu/llvm/llvm/docs/Vectorizers.rst index f8477f20f03..c322797025f 100644 --- a/gnu/llvm/llvm/docs/Vectorizers.rst +++ b/gnu/llvm/llvm/docs/Vectorizers.rst @@ -80,7 +80,7 @@ specifying a vector width and interleaving count: See the Clang `language extensions -`_ +`_ for details. Diagnostics @@ -116,7 +116,7 @@ Consider the following loop: } } -The command line ``-Rpass-missed=loop-vectorized`` prints the remark: +The command line ``-Rpass-missed=loop-vectorize`` prints the remark: .. code-block:: console @@ -133,7 +133,7 @@ switch statement cannot be vectorized. To ensure line and column numbers are produced include the command line options ``-gline-tables-only`` and ``-gcolumn-info``. See the Clang `user manual -`_ +`_ for details Features diff --git a/gnu/llvm/llvm/docs/WritingAnLLVMBackend.rst b/gnu/llvm/llvm/docs/WritingAnLLVMBackend.rst index f8ca9563a3c..c153114db38 100644 --- a/gnu/llvm/llvm/docs/WritingAnLLVMBackend.rst +++ b/gnu/llvm/llvm/docs/WritingAnLLVMBackend.rst @@ -1100,21 +1100,21 @@ Branch Folding and If Conversion -------------------------------- Performance can be improved by combining instructions or by eliminating -instructions that are never reached. The ``AnalyzeBranch`` method in +instructions that are never reached. The ``analyzeBranch`` method in ``XXXInstrInfo`` may be implemented to examine conditional instructions and -remove unnecessary instructions. ``AnalyzeBranch`` looks at the end of a +remove unnecessary instructions. ``analyzeBranch`` looks at the end of a machine basic block (MBB) for opportunities for improvement, such as branch folding and if conversion. The ``BranchFolder`` and ``IfConverter`` machine function passes (see the source files ``BranchFolding.cpp`` and -``IfConversion.cpp`` in the ``lib/CodeGen`` directory) call ``AnalyzeBranch`` +``IfConversion.cpp`` in the ``lib/CodeGen`` directory) call ``analyzeBranch`` to improve the control flow graph that represents the instructions. -Several implementations of ``AnalyzeBranch`` (for ARM, Alpha, and X86) can be -examined as models for your own ``AnalyzeBranch`` implementation. Since SPARC -does not implement a useful ``AnalyzeBranch``, the ARM target implementation is +Several implementations of ``analyzeBranch`` (for ARM, Alpha, and X86) can be +examined as models for your own ``analyzeBranch`` implementation. Since SPARC +does not implement a useful ``analyzeBranch``, the ARM target implementation is shown below. -``AnalyzeBranch`` returns a Boolean value and takes four parameters: +``analyzeBranch`` returns a Boolean value and takes four parameters: * ``MachineBasicBlock &MBB`` --- The incoming block to be examined. @@ -1130,12 +1130,12 @@ shown below. In the simplest case, if a block ends without a branch, then it falls through to the successor block. No destination blocks are specified for either ``TBB`` or ``FBB``, so both parameters return ``NULL``. The start of the -``AnalyzeBranch`` (see code below for the ARM target) shows the function +``analyzeBranch`` (see code below for the ARM target) shows the function parameters and the code for the simplest case. .. code-block:: c++ - bool ARMInstrInfo::AnalyzeBranch(MachineBasicBlock &MBB, + bool ARMInstrInfo::analyzeBranch(MachineBasicBlock &MBB, MachineBasicBlock *&TBB, MachineBasicBlock *&FBB, std::vector &Cond) const @@ -1145,7 +1145,7 @@ parameters and the code for the simplest case. return false; If a block ends with a single unconditional branch instruction, then -``AnalyzeBranch`` (shown below) should return the destination of that branch in +``analyzeBranch`` (shown below) should return the destination of that branch in the ``TBB`` parameter. .. code-block:: c++ @@ -1171,7 +1171,7 @@ instruction and return the penultimate branch in the ``TBB`` parameter. A block may end with a single conditional branch instruction that falls through to successor block if the condition evaluates to false. In that case, -``AnalyzeBranch`` (shown below) should return the destination of that +``analyzeBranch`` (shown below) should return the destination of that conditional branch in the ``TBB`` parameter and a list of operands in the ``Cond`` parameter to evaluate the condition. @@ -1186,7 +1186,7 @@ conditional branch in the ``TBB`` parameter and a list of operands in the } If a block ends with both a conditional branch and an ensuing unconditional -branch, then ``AnalyzeBranch`` (shown below) should return the conditional +branch, then ``analyzeBranch`` (shown below) should return the conditional branch destination (assuming it corresponds to a conditional evaluation of "``true``") in the ``TBB`` parameter and the unconditional branch destination in the ``FBB`` (corresponding to a conditional evaluation of "``false``"). A @@ -1209,14 +1209,14 @@ parameter. For the last two cases (ending with a single conditional branch or ending with one conditional and one unconditional branch), the operands returned in the ``Cond`` parameter can be passed to methods of other instructions to create new -branches or perform other operations. An implementation of ``AnalyzeBranch`` -requires the helper methods ``RemoveBranch`` and ``InsertBranch`` to manage +branches or perform other operations. An implementation of ``analyzeBranch`` +requires the helper methods ``removeBranch`` and ``insertBranch`` to manage subsequent operations. -``AnalyzeBranch`` should return false indicating success in most circumstances. -``AnalyzeBranch`` should only return true when the method is stumped about what +``analyzeBranch`` should return false indicating success in most circumstances. +``analyzeBranch`` should only return true when the method is stumped about what to do, for example, if a block has three terminating branches. -``AnalyzeBranch`` may return true if it encounters a terminator it cannot +``analyzeBranch`` may return true if it encounters a terminator it cannot handle, such as an indirect branch. .. _instruction-selector: diff --git a/gnu/llvm/llvm/docs/WritingAnLLVMPass.rst b/gnu/llvm/llvm/docs/WritingAnLLVMPass.rst index ecd1db1344d..88f481ba6b0 100644 --- a/gnu/llvm/llvm/docs/WritingAnLLVMPass.rst +++ b/gnu/llvm/llvm/docs/WritingAnLLVMPass.rst @@ -17,7 +17,7 @@ build the analysis results that are used by these transformations, and they are, above all, a structuring technique for compiler code. All LLVM passes are subclasses of the `Pass -`_ class, which implement +`_ class, which implement functionality by overriding virtual methods inherited from ``Pass``. Depending on how your pass works, you should inherit from the :ref:`ModulePass ` , :ref:`CallGraphSCCPass @@ -98,8 +98,8 @@ Start out with: #include "llvm/Support/raw_ostream.h" Which are needed because we are writing a `Pass -`_, we are operating on -`Function `_\ s, and we will +`_, we are operating on +`Function `_\ s, and we will be doing some printing. Next we have: @@ -336,7 +336,7 @@ The ``ImmutablePass`` class --------------------------- The most plain and boring type of pass is the "`ImmutablePass -`_" class. This pass +`_" class. This pass type is used for passes that do not have to be run, do not change state, and never need to be updated. This is not a normal type of transformation or analysis, but can provide information about the current compiler configuration. @@ -353,7 +353,7 @@ invalidated, and are never "run". The ``ModulePass`` class ------------------------ -The `ModulePass `_ class +The `ModulePass `_ class is the most general of all superclasses that you can use. Deriving from ``ModulePass`` indicates that your pass uses the entire program as a unit, referring to function bodies in no predictable order, or adding and removing @@ -388,7 +388,7 @@ The ``CallGraphSCCPass`` class ------------------------------ The `CallGraphSCCPass -`_ is used by +`_ is used by passes that need to traverse the program bottom-up on the call graph (callees before callers). Deriving from ``CallGraphSCCPass`` provides some mechanics for building and traversing the ``CallGraph``, but also allows the system to @@ -460,7 +460,7 @@ The ``FunctionPass`` class -------------------------- In contrast to ``ModulePass`` subclasses, `FunctionPass -`_ subclasses do have a +`_ subclasses do have a predictable, local behavior that can be expected by the system. All ``FunctionPass`` execute on each function in the program independent of all of the other functions in the program. ``FunctionPass``\ es do not require that @@ -498,7 +498,7 @@ being processed. The ``doInitialization`` method call is not scheduled to overlap with any other pass executions (thus it should be very fast). A good example of how this method should be used is the `LowerAllocations -`_ pass. This pass +`_ pass. This pass converts ``malloc`` and ``free`` instructions into platform dependent ``malloc()`` and ``free()`` function calls. It uses the ``doInitialization`` method to get a reference to the ``malloc`` and ``free`` functions that it @@ -761,7 +761,7 @@ The ``getAnalysisUsage`` method By implementing the ``getAnalysisUsage`` method, the required and invalidated sets may be specified for your transformation. The implementation should fill in the `AnalysisUsage -`_ object with +`_ object with information about which passes are required and not invalidated. To do this, a pass may call any of the following methods on the ``AnalysisUsage`` object: @@ -914,19 +914,19 @@ be registered with :ref:`RegisterAnalysisGroup `. As a concrete example of an Analysis Group in action, consider the -`AliasAnalysis `_ +`AliasAnalysis `_ analysis group. The default implementation of the alias analysis interface -(the `basicaa `_ pass) +(the `basic-aa `_ pass) just does a few simple checks that don't require significant analysis to compute (such as: two different globals can never alias each other, etc). Passes that use the `AliasAnalysis -`_ interface (for -example the `gvn `_ pass), do not +`_ interface (for +example the `gvn `_ pass), do not care which implementation of alias analysis is actually provided, they just use the designated interface. From the user's perspective, commands work just like normal. Issuing the -command ``opt -gvn ...`` will cause the ``basicaa`` class to be instantiated +command ``opt -gvn ...`` will cause the ``basic-aa`` class to be instantiated and added to the pass sequence. Issuing the command ``opt -somefancyaa -gvn ...`` will cause the ``gvn`` pass to use the ``somefancyaa`` alias analysis (which doesn't actually exist, it's just a hypothetical example) instead. @@ -963,14 +963,14 @@ implementations of the interface by using the following code: This just shows a class ``FancyAA`` that uses the ``INITIALIZE_AG_PASS`` macro both to register and to "join" the `AliasAnalysis -`_ analysis group. +`_ analysis group. Every implementation of an analysis group should join using this macro. .. code-block:: c++ namespace { // Declare that we implement the AliasAnalysis interface - INITIALIZE_AG_PASS(BasicAA, AliasAnalysis, "basicaa", + INITIALIZE_AG_PASS(BasicAA, AliasAnalysis, "basic-aa", "Basic Alias Analysis (default AA impl)", false, // Is CFG Only? true, // Is Analysis? @@ -982,13 +982,13 @@ argument to the ``INITIALIZE_AG_PASS`` template). There must be exactly one default implementation available at all times for an Analysis Group to be used. Only default implementation can derive from ``ImmutablePass``. Here we declare that the `BasicAliasAnalysis -`_ pass is the default +`_ pass is the default implementation for the interface. Pass Statistics =============== -The `Statistic `_ class is +The `Statistic `_ class is designed to be an easy way to expose various success metrics from passes. These statistics are printed at the end of a run, when the :option:`-stats` command line option is enabled on the command line. See the :ref:`Statistics @@ -999,8 +999,8 @@ section ` in the Programmer's Manual for details. What PassManager does --------------------- -The `PassManager `_ `class -`_ takes a list of +The `PassManager `_ `class +`_ takes a list of passes, ensures their :ref:`prerequisites ` are set up correctly, and then schedules passes to run efficiently. All of the LLVM tools that run passes use the PassManager for execution of these passes. @@ -1030,7 +1030,7 @@ series of passes: touching the LLVM program representation for a single function at a time, instead of traversing the entire program. It reduces the memory consumption of compiler, because, for example, only one `DominatorSet - `_ needs to be + `_ needs to be calculated at a time. This also makes it possible to implement some :ref:`interesting enhancements ` in the future. diff --git a/gnu/llvm/llvm/docs/XRayFDRFormat.rst b/gnu/llvm/llvm/docs/XRayFDRFormat.rst index 46f72c54228..eb11a3c8fb8 100644 --- a/gnu/llvm/llvm/docs/XRayFDRFormat.rst +++ b/gnu/llvm/llvm/docs/XRayFDRFormat.rst @@ -28,7 +28,7 @@ Each trace file corresponds to a sequence of events in a particular thread. The file has a header followed by a sequence of discriminated record types. -The endianness of byte fields matches the endianess of the platform which +The endianness of byte fields matches the endianness of the platform which produced the trace file. diff --git a/gnu/llvm/llvm/docs/YamlIO.rst b/gnu/llvm/llvm/docs/YamlIO.rst index ac4f8d18322..9dbb2b2766f 100644 --- a/gnu/llvm/llvm/docs/YamlIO.rst +++ b/gnu/llvm/llvm/docs/YamlIO.rst @@ -12,7 +12,7 @@ YAML is a human readable data serialization language. The full YAML language spec can be read at `yaml.org `_. The simplest form of yaml is just "scalars", "mappings", and "sequences". A scalar is any number -or string. The pound/hash symbol (#) begins a comment line. A mapping is +or string. The pound/hash symbol (#) begins a comment line. A mapping is a set of key-value pairs where the key ends with a colon. For example: .. code-block:: yaml @@ -730,7 +730,7 @@ The YAML syntax supports tags as a way to specify the type of a node before it is parsed. This allows dynamic types of nodes. But the YAML I/O model uses static typing, so there are limits to how you can use tags with the YAML I/O model. Recently, we added support to YAML I/O for checking/setting the optional -tag on a map. Using this functionality it is even possbile to support different +tag on a map. Using this functionality it is even possible to support different mappings, as long as they are convertible. To check a tag, inside your mapping() method you can use io.mapTag() to specify diff --git a/gnu/llvm/llvm/docs/conf.py b/gnu/llvm/llvm/docs/conf.py index c92ede3ea44..a13eb63a632 100644 --- a/gnu/llvm/llvm/docs/conf.py +++ b/gnu/llvm/llvm/docs/conf.py @@ -32,9 +32,24 @@ extensions = ['sphinx.ext.intersphinx', 'sphinx.ext.todo'] templates_path = ['_templates'] # The suffix of source filenames. -source_suffix = ['.rst', '.md'] +source_suffix = { + '.rst': 'restructuredtext', +} -source_parsers = {'.md': 'recommonmark.parser.CommonMarkParser'} +try: + import recommonmark +except ImportError: + # manpages do not use any .md sources + if not tags.has('builder-man'): + raise +else: + import sphinx + if sphinx.version_info >= (3, 0): + # This requires 0.5 or later. + extensions.append('recommonmark') + else: + source_parsers = {'.md': 'recommonmark.parser.CommonMarkParser'} + source_suffix['.md'] = 'markdown' # The encoding of source files. #source_encoding = 'utf-8-sig' @@ -51,9 +66,9 @@ copyright = u'2003-%d, LLVM Project' % date.today().year # built documents. # # The short version. -version = '10' +version = '11' # The full version, including alpha/beta/rc tags. -release = '10' +release = '11' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. diff --git a/gnu/llvm/llvm/docs/doxygen.cfg.in b/gnu/llvm/llvm/docs/doxygen.cfg.in index fe74edc0866..7a6d531ad25 100644 --- a/gnu/llvm/llvm/docs/doxygen.cfg.in +++ b/gnu/llvm/llvm/docs/doxygen.cfg.in @@ -1433,7 +1433,7 @@ MATHJAX_FORMAT = HTML-CSS # The default value is: http://cdn.mathjax.org/mathjax/latest. # This tag requires that the tag USE_MATHJAX is set to YES. -MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest +MATHJAX_RELPATH = https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.7/MathJax.js # The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax # extension names that should be enabled during MathJax rendering. For example diff --git a/gnu/llvm/llvm/docs/index.rst b/gnu/llvm/llvm/docs/index.rst index c150c75bc8f..0df1ea79b4f 100644 --- a/gnu/llvm/llvm/docs/index.rst +++ b/gnu/llvm/llvm/docs/index.rst @@ -1,5 +1,5 @@ About -======== +===== The LLVM compiler infrastructure supports a wide range of projects, from industrial strength compilers to specialized JIT applications to small @@ -22,7 +22,7 @@ Several introductory papers and presentations. `Introduction to the LLVM Compiler`__ Presentation providing a users introduction to LLVM. - .. __: http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.html + .. __: https://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.html `Intro to LLVM`__ A chapter from the book "The Architecture of Open Source Applications" that @@ -34,12 +34,12 @@ Several introductory papers and presentations. `LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation`__ Design overview. - .. __: http://llvm.org/pubs/2004-01-30-CGO-LLVM.html + .. __: https://llvm.org/pubs/2004-01-30-CGO-LLVM.html `LLVM: An Infrastructure for Multi-Stage Optimization`__ More details (quite old now). - .. __: http://llvm.org/pubs/2002-12-LattnerMSThesis.html + .. __: https://llvm.org/pubs/2002-12-LattnerMSThesis.html Documentation ============= @@ -78,6 +78,10 @@ LLVM welcomes contributions of all kinds. To learn more, see the following artic * :ref:`meetups-social-events` * :ref:`community-proposals` + Reporting a security issue + +* :ref:`report-security-issue` + Indices and tables ================== diff --git a/gnu/llvm/llvm/docs/loop-terminology-guarded-loop.png b/gnu/llvm/llvm/docs/loop-terminology-guarded-loop.png new file mode 100644 index 0000000000000000000000000000000000000000..d235b1421189ab7185974d3dd7d78ec30684a2a6 GIT binary patch literal 72585 zcmb@u2{_hW`!@QcSu!Mr%%w6!NJXYX11f|fQA8q<5}7M9RuqYZ$P^NV$WZ1Gkuf49 zQ)SAKai7ccKHvBM_TK-!_jeq-<9*-feRR9;-@VqguIs$c^SqXi#?gao=s4&oidu8{ zkg^s<(auuTk`pVJ<0psz_^ro3mR{L^SbHV@IIleCO;NnmVdZ_=4>)UO%a$)2c8m z7PExGJt{g%`iyTE(=A{9pbI@3)}{m9-qJlLab{nJ_ngYxQvJ|OFOp)+{>sGQjV0krR#bnRymH#GM8+xAB{gsIORw3hi7&hO`FZ)t zpQLk^1C%%UlQ6oYb1V5#y0Q9{5BW(l8;dLX0l#pmMW3o={EiQ-(TMz;kvzV&+Y%epIYL|;lqcg@Bsfjs@}FO zv&v>7Vq%O-meVV$s`@4>@!=s>mv}@btX;Qm-M87lW8VJ$#b4jr+lfAS^5jlsh}aTJ zTZq-z*w|*`r(VxkTblv>#$EK{;^Gd&-)QPSf6f@FsH`k%NIF47g@%Uix!ko>dFkZu zuS$-NIiq5mHYp_?J@PltX_BJ)`}+?aJ-TaJp6uh;JCDfn@@qrwcWx|MVLUfIe)6?B zv%%@pX=mQkCNx-3ipt7Mmosp#w70kSxP6;nNQmy^0*S>FrXbdZ)REGoME z>x&fi?#1c1J4`FqC7*t~zU&@PS+NgGXJ_XP0kwy`va+0OHtteZRHSxYYV$rGf0S>> z4yH?&F0G`aD}1Wt71Uf;SGU7u`s!=*TH38g!{6On!T9ahuRCTR!}tUR69??qV{>(6 zoQ|(hJa^>U?>3*F%8>4R3iIwMR-Hqiv4HP>w!Es1+PB1i<8FqpId(<;pX1Z4T6dBC zPB1EvuMU@9LiM%0+PdpvvwK#%*X&nSr8^oS>%*sX`^=Zu7bthh^VQ$p-&#># zUj8mr^8BZlXO%8~dA&+4MAS1RWJ84O^o3-D?6p`QrH^4!BNf7_+eV}=wXqo*8ahmV zwIBKUs)m2>-i>$f-Yu`GIngD6l^ra!cHrNnnbhz|#!jg89#3kpEF;IxmDEeeaSO^l zCT7#kn>Q)S>dWi*TO*xs=GYBJU;3KECUbQg^$klWa4FtpW4>TmDUG6>*E32TuGe1B7GAqkVHTLF{CtN>&t$u5mVbSn< zz~=I08Y<=TWX>KL8Cr^#miDUaB@>fd?2=|@riMFD<~oRHT6Zu|d#;ae&dtsJ^z1N; zsovJDTbG(Pa_OPPG!>LFwac< zDoRStw;1?@@0CD@lp=Be$H&J@s7$NYxUsSNdTnJD6&=$S#~|KZ{K(A+OAT6_LwVs?wPfd43~Zs8PC7Cp@DTMe@2u#Q}^t! z!_2R&ks?NgGav2?^tEM6-e%zP{gPq1gqoio6r&`|HY9A3^p!2 zc24=qkE-{%*T=r~^?8fsPtk5V;QubG!__ZVEhO5gz?E|Ea9iM7y@Vw&O&*L^@hng?dt04 zQuR;VcWZgy*SA^KZ)b#p>F^)y$g*Y2O53@}_AS5o>{;3}<$H+%0ZbmAo_u0rscm)% z+Cm1|w#)1W8$G?e4tjQdsH{}lzn?ZYFE5x+{x*(E8Ot%*8!TIo_WAczKiRu&+cx*N zZ=F25HuLj4a?-O)EPZP~Bsy`z@k;3hX&<2*h*JHmOIATSoLpSBaYr88rWV)_87^J1 zB4o1!4F}hPU16I+I4o1q3d7Mp5Dac z@zKagTm12N-s(Q&FGt44iV!o*EG)O044u}zI$yKP?hyHo`?1-{{&$g)6~FaQ58UB+wAcPc`p=Y8Sxih!?kG~mc*!37-<%Ab zd))ty^>!m8lEOUh+hepay@3?i-)++MDW^72pI)6mhUnUas)x>6w!KN)Z&&kV?+F}$c%Ah;JYu_c?dt08j?tMPNJ_0} z&vVMCnE2VU2|uM(jE;$^Y-`8CUFz;UH{PV*6Myu{T51%JAM#4Tle>3twWiKYQ^C9d zo;Qx6hx&2gIe>4T582u6jV z;IiUkUS3{`S`3O)S(o~n(_#$md{<%(Q1@@Ve*M}w^1P`jpPU>Qpo_!QFdwBDt0icP zf05y7Q&UqbLSeM|*(`qU{P_(tvcOb`tYy?WGqWxfQW>6W>gwt^y&jrnTek`boL!io zdvmp4E3q>6*|TpbN?09zA4X%d^XI!qdnzfqNi}tK`sxU|Q^rq%Ya>R5Qszv5#o(NU zE4Uf{{fl7P<1lLF=+---_(_U+$)Q|r98c95-MpPI4_&NeDDJ+ir} zeE4IOa2zbYEnAi|a?2_LkF|Ht`2D_zgSX+-59}{6>8?2S(CDC^o}ROf$$Bz_&I5_@ z6ve>65PNCwrcFyUH8stfU-F>{#f^vFxw9tcYX8k=&otZZk15qW`rK6_g~2 z8vrsCm2>UabDez4Cefu!m-6Br)EMxqWcs;PK!>EL;4#hsk*Larh#4IK4%AIP zdBekFsXvbb_v78xFFwuhb(#<{bm&}`te-)5;)TIJ>{4fMZ~W$Pj`(Ad2SP+ozcenP zD=sTDX?t^d_|KnWEMBlF((VqMZ;Ef;zTLEQ=Q^@V?YYuOFQ4*VocuYZwUVkU%#U4v z_Uzf2{<_%Vu`#8`yR3Y_t`W85QBhGj+x+q@0=Ud+D9=my#EU4W$=|@E`)eZPY7>ud zB~>sjEe&h44<9}Z&=P|xq5rB5`HCM{YkaV&3?=67P{9JXsHiA@^JZ4o?whx61x7>| znmJwS$iLGY;lzOYRf;Soj`X+F{8LoD-M?tr)8%|ckl@L;*Q~N9^)z{0{xIjyj;i@{ z?bQ{u#8#th*@>q9?MXE+5FJ3WW(r)}8ZX$ix#hM*<9NxZ{C&#ni=Qp=^{&z|_3vB& z`dsR6kn5l+cq;vz&+OmcNc1z;N6)2>-Je3W$p04Mmpy3EYCv5yi3P=f58iz*}8iy>|WjxQx6AIj4tCRZi;a z{%_vAIb>iEu9bOx%#4Ot&hd{%g|UfA$@};Ffb0{4619ccWgT8p0a#!^??aa^y%0H_ zqfH&Ee7L_qw`9YVI;HrK45WHj~pv^!*!^?@6k07S*5=^sYEGB`G2C-Dhh=!2H}y<;1U6 zQxvas+a6VB=4|J`={v2yX#egg5aZ`Rd-iPCj~`q3`1m9&8%6qCvr>V*Vqc(#SVifj z8GCBQ=_Zv_R;mp&rX*$j3^8&|l^ua>rjnv-8JudEm(#Y&&5MES^;#w7K;*?$3=9tsKiDE@`ed*D zL$qwHrxXMQ52LpRD%Jsy*vcyRyz)h)weD>M$?;fU3V2n!REvZ!aG zY^VS9Yqi!sRaybS_5g4s_F_*(u&M%6qC;WoQ_IK;Nc!b|V)@(T<>hG=sYB=<1OS2R zWlW5Xi)(Asnr{{4ps`S=4t33D%b&n*^GlYkSzqIMxPcZA^VV?QDw<=PB2dJiO zq`NFQXQvVeH<#I2v{69&1arxheH}DGFL~(jVNLE)zkBx%Uc4wmZR>u<#l=OV$i87V z;q~jC7r*AP-nen2gxexT@0D4$v8t--eggwe?kK7L%2nm;W>1+{Ryxw(bQUSA7r!wIyq zg2EDLdB(+w9IkblNci^c%+J;=#@?DpRGL|u^XJb486L2Fq_4?;69IA-h_ZxxwgFMN znoV5s)JDyXjo5!B z(og@6sSEnEcFU1$KIni${a&C02cQoTmHx({*GdrakuG&pe1RSQECy+t;HhGJo6R)4%} zjo$__K=|#XFwV|8lk_xLDJ3d;^e`J01yJ-z!j$eVkHXy&zYQ@_QPlbB@O@XW?#xFw zU|WXsaZ}!9`pi&!9${||U@t#$mEo6YKFwDusazPSo7IWg9JcojC@2|)rp;QQUL37k z*?wg^O^Q}WDx@|QU}1tRH{$y~@A~em5v)K{TQEN@i~_LY)TvV8j6`L`Aihc$yb+IF#3mYpo@fX>c za6&!XpYOiZ2Gk{kbR3@%Zq~@A)UILaKk>7pz$i2+PXvsaSQFPJmr2dq&fUQR($ehI zCv*u~A$#5CWxr%v`JrZ*ln3y!$vf{st+|apr|VUXe3Gw*T{_5Yk z<=7H?d8l2k{>AB2=bs=H_k(@7{G*B;SX8KB-G$=P(r8eWGVyfVQ+*ALyvwISoJ!pI z`SW5`sN@Rdr{fjr>FJ=pQi6A0Y<@{&o&VP?Z5$Bam#|h?{n$(KXlN+9-T=3tAEM9A z5)R<(-{qF01NutoFZg9O>O+<=%U`v6U8=)aiWnO$=urOzx;)vSJjOGrfeaWY})r=aC zDE3!!sCgp}L9@DgXGXG+WMDnRD2F1>R5L9Qt zo+bDmLUwW=*$7XQXCjnSqsoFF56>CpwlJ^Xvx1Sk7zZ{DCB%4;Q_gW+Z}pQRlv&l} zNszR~dxvswp?hQzE0|5!nr||4L#d;QIdDg-^n>3@JZ0yvU#DL@)o0Dl@B6&lyPP(( z>+o6rE4u8j{;ZR7n|DsRAf=*=T)hb$vaZ?ZJy-hzsxM6QZ`!oXJ$K@Z39M>;>OF@u02$kpHdPvc*6^H9dtg@MK_VOjrW6t1+HDYMyn`4 zKV>5AGX2_l^uyLVfKM9UNSBFFtcC`9uC3I$Pf`11S~JXR`Du88YeJT+U^wLJnokg0 zs8vZ*(}`<8n>8;sKCVmFdvzdGF7{ZYd^%oCAk}NDR$WWF+QFt&zoeuj*^y$F`}glh z2l4E&QM71!v3={Y2<-|iF22Q7m!E#?bYIN9rS7vc9SbjBPiTASr>sXBrioHd6pUVw z_x1DpEWNSDbM=O$?hcNQ7Qsf@wkni&NJxlow%NkpnVCxLRM04Dmf8~;yCA(Ms@;Qw z!hqHKrtR(Rqb=tn1r@R^8dRxraKORohyuamML*E=qMQjxO1>)o74*7hi~1wpNassFu6rG3!!|6jI#w?c0ZR&rf>gjJ)gDuak8HO!sTNxX(Io z{9%2nkr83cVnM@Rpj8Y*r7_FP(f4oae6Ms6UM!GW|Mk=`FH-GseK%yfcegys*Q@CmD3|%EH1z)$ozn=(Q{?=)msAM>sw=80;u;<3TYf zLp8aFqWUZ@j$cZO^}~k`B;$d@zKfP%ThR&kLN8itG;CnL-d9&MKs`x7Y^SA7gM}-_ zk@%E*{Yval@U=HmQd0IY=00z*Agm_g!d|_Sl#rC{{Qmu!dhbbY{+sA&k^J9QwWx#i zvKb%H*=gCR&fcia3@V}GOu77XZ@hD-+kCGZkxHPbbRmtPw?CVf)*p)p+c!SYaJjdd zYqNmBQ(z{?)X0z!FTAOPlhcOB#@a^wH#hFS^o{&Z-LqBtugx`o=gspxL)K2}(i+VppSWlcd@g^rnNFgNXWWVa#O3Cf9`0|b6Q}-@eH@!IR z*fdrpS+i~MOLKFd++%Oh)XvV%f7*}gsaoEX7C*UMjBxs$trha2y85<$$}Wc=5sQ`45iET=FU}5xEDs45 zRm}?*F6_DXlMQUTeo0{e5cHo$rxxs3sFm&99+oBCHwB8m0xW{8EkzzT9nkPDS4DMA z=LPaR0NqC1>dQ{fJvI~+H7~Mjz{j11%bHtTP0;Md=IhnhbGsyM)r(6ykxIMc_udVC z3p=6jY}|EmhaH>pIhCod?fk2|pl3BVpTxmi0`_YPxDzzTUEp-}2w8UU>~gZQvg%x0 z^wNOROvZkEG;c{407CSHpakWtqW-KN>lLS69^N86JYNKaqSNuepfD;;eHed@GAN*H zW)5UEDLjV0MfqF_A#(!J?zZLFCDjc;Gf_Nn;6P}l>G|^~^y#T#R6xB3n*^{HeB$D@ z^=H|F)4p8&hf@x*{94h+$m$cnb2|KUaE6uT@VEC%UJWSysE=>)61tb);d5^_ z&atx0LT>vr*u)4xdNS+Mlf)wN$MPTLwg3M4d(^oN%zCuyF6Sv5P%hC?QBif7ooElh zRunchWi_Ao@$n(F?Z|kO5di4MzNXa3_v5`_&FQ z+B5B0$SEx?{S;*jOm2dI?UofQR-kOJcPe_7@Bd$)>-;4b>A2U~|9Sz+4Z6+D z*}6qQpp&qEbq-ZGdOB`zN~h2mZE3v*q)bJ%StsZHzY)X8C)%=SB#kS&b@luk;(Xgu zlKkf^4#}3v$ES3P=?9mzO$SJq6v=Ck6ORAPI|`-uQ~gtI>2`u^A$yS0B#@uDQ%vmG z^~V>?%(fg2-$UbK7<#$CP9Uaq6$Q|z?CL5HU>2jp4M6JdPEnpFs&DNEZv$(iIrZk1 zm*>X8IHaZ~JaJuDcRd&dlHk1_>g#`sy%}fr7jj{bt!Z)niB;r4!`nI;M(9rjwxlFXv)qSk0)p&W^^JG*}NLzc* z0ie0N*S{`H2mLMWz- zk@@5OP7(c1^MkLxjv78*WBOD6T-E#%?V~(G+e`867N-|JfByVbD={E6G;uaL>GVBA z>nm5Th+k~pQCwV1glK^mCMhHZJO#1g;o%X5{@(%3<)X~ZEvJ9j@E*EB^vVQTgWcWd z;IIcRk~bFciCfrGIu;M~DTOsPj1ZV_sK!cIRH0?0aW{6O>&UR&08KX_Fpy~T-$)`& z%AcBY0G+#}HPfmH3{WjF38bMj&`gPVO->SE(NdB+k*{@M7_6e+xGl)%&rO`V+V_bD zr*{hYIY@?l1IIt+{%qp3NY~zX@80(EB24pg#ezA<8UY z0Wx-%=LW-f&vlY)dMa4|40Z6hy1J^S#}a+}YJc4_Vcld!XJ=WQ@fF989sAjyw~>O5 zdjo!j!mnSso<4nwRo{HIhoz3+b7sA}p_5 z*FL}_aczOdzr(A-S6o0~*_GaEPplxJ(Xn7iBr8Cq-F*9Y?`=k&yFe^g9=@}Wz zfZl@k#H)wi#Q%Bd#B-99kAFLOkab7_F^$;{BgQnmIGaH_NxB~Z=g)nPJJR+0wSB|1FnHnvu~^)!6%Z%t{zPd`m{5M_>4wlL5A0Q*Z{^ZK*ryRuGUqpi!ZXgAb$O z1+!59+yp%*L^A94-{bEh_nZ=g&e+m z_4V4KMMAiBO=3*4YfMcVSm79o$;ikECG^;4VPUo3?RmoB?`RcW|MqM!J?(NYL%uhZ zueU(Hb$d-lwunxx*PpNP0wu@SnoRI18Pl&?#Y{<remZgO*?G@>!sn zh*Ia!W0+>9?Od2{Dk%Q&A#uN*wiJrEindwd0+Os{@Ie)oRn%o0n*gxZzTV|%YnHiB z{r$`S`VJ@q9o53fz(BrZvLhZiU`D{cq9$c`gM)=n;H6*zVj-p4Lg-;;UbT8P3#1>? z4j|i1--b|`ND{C0eB}t zQ!tC`skIw73iHPfHNiLFla-YPk|$*pY|Dvl(!W1Fy#=$*(IhyajzKgrg>OPt4^bM6 z&n#&?rmDJj@7}$a?d*d8{JGl0hT?2wDg9B5HmqAK)T-`NFlXNtPUSyCj8Hew81e%X z*Xv&zY)qk5l)2icVIeCZ{zLk7UFNu4+-=dfa01crq6ewd-z6ob10x6@^&M*)o7oW{ zqdKsAntS7s!iB!SqN8qePVa9nTi&oWy5oA>&|mBFYn4t`qK8cjnsh$%^E1{@#BqF`!&zMAFDPq!0t~)({aqKkdUkH^a#!&x z<%0){z>7>a>YdkNwcbVXnekX|L%da-32R2ab2t$ zAu_3V2YFmP(1gVxkx)^y(&M$4<51FxG&k}4s~?D@9zGK#^rg#j?6kSn@BT|Go9tBk zl8T(%oMR`9PC)DDzBd3M9Grd!w6xZu4c|f3B3on^K+kOoF!OAZk>P-y#5hd`UvmWV z*Cu{`TBu0-u#gmmeg3Rp4N9B}60Znuh)c(QaO>#0LAu>^sXf;RyKK4UG2~@0DD~)_ zQRvQqh|mZxm5sL(|NdzD@8ABsi$vr5_Kl(vPG!AlOh*-Q7;iYi3{wyhCPBmtl%7At zB{2RN2&mug;!fX7Nv?C#)clZsl(h?J7t@IIx5F21U(CvFGE-uE#rUh`RlL?T=EfRz;-JkA}?caB%1PUI%$=a4=ehsNJhNI=f;ZK&(B_`wvB8LLK?@KFU4_< z-#n|rdc;B~>4<4!`Q=XzuNBPmzi$vV@aC3tWRuc0dGa}j%~l=#$&1N!$SGoWZ&BN6 zG^TVvkJe=|e7x1wBeyFoWXA`$vf+(dMtUUCxT& zAJ8Hu&bFnT+N~Zcv5a{Ax=Q>sH8hBaju&y$;XHOEyBlQlK9~buVm(CkU$2Zgc<(j{ zNW(!3!y`st=*4?R`kqwQng8A|ARy2WuGsZWc6NW>uL_IfdP26GJGp-`hIt+IlmBMG zUg30f(70S&>c>b^8|#bm4CM|Pf0v8&iK)qBRRLoKLN($p*!>IhVVXKt!pF!rtf{U( zU~J5fqkaRXwV-DELyJWF=eDOiO8>a&^my^Ox&xUwPW)UIWwU%W*zMdub!rt7Ff^g7 zZ~zbey76@8MRu}EKt{Q96Rpj!&NE`;bOxAw4*J{`943YsP6b!aB;6FP+roWnERkl7 zt4uC5JZGiOAX~~P6gdBt0GS)KdtdvT%SyfU!eJ6h?QD90C2A^nZo z5)%`FV1$fbs%U=?7p({|v8d{f3=gNL%+Y9vR_eZHFyYy#G$1@EEBSpkwc?684|Wvn z8TI^yRZqWCPs;+~I6PLd>;TW%_ST*e?U1DY#$r=FfA6-MtVGlcj z;@IGgLhvfWH@45*JVEPWaPTr~Yiq(;3%0&IyQJND?4$AEu_rRDpyAdNq0;$pPsmh_ z+kDIwdb2wmQq;O?vAF~^QA@UQcCT8uWgBQEPtf2J>eROIQWnL~&q34E)6rNhplT7| z=M4GJ^sk^02xc&x2Hm?9RoN|KZ)lM z2YSDwsprifD=!7znfxido>h*4tGWbqIxnoB?@3$Ttd|obnI*6~V zKESlncKF*qn0PF|%EI+3dihO2zFlARP+D#HW0jiP=$`4u_?qix<$tY{uT*i)Xdq&r zKU**#Kp;t6U047bc;h%ObikkO2G~n}*j9-o0=JKb$d=O`K4Bq#a(9((5S&i)@#OdD z4WVfH@Qs&%0Xtryr3C{w_|4k4uFU(;x==xT@=qSO21c2`G5GS_hqZrxwQc}Cp<5B* zHh+Ed)~(&Z{giu=7h^XLl*2^J`HaRnK+!bkzqZ5|u`pAx;0N`C12%?2QhR^0FNYA` z+}wNy0FW^K;2p#v|MqNfk93_z315|lt#&_+GI&KzL2^43$UFnJdl zl*LX66+mctU*Zp6+$pxKZgLMbJ-Gt#Ja^{zTgn{_SSO^wQrHiOM=1(bkJ!uZtFOCL z#smsM?Mr4pLGDrvJo3pId0cz1eZ#_?%(GCMVLGS4w1 zosl#<%`GjY4!p7L@zt_E+~EUhigHJxdW!XeK}z%CD@UEZf=q#bll(78f3B-L2e(yS zg65`vR3_r4K;`9!Y;hkwpGX!2lK+KDt_U|4laSCN8U?k~ot|xnqU*w(ea{$Jm{9l- zzyJ!5=YysreDJN-!0>PpoW=WY^M4N}$!^-D1e5kQ^!4|dHyt=+Zf>5IxLSoSes1tf zM$%f#S~p;ZCVkiW*}uk?mcrCC)Y0@Sy+{AT?o;yh>uI!BTT$DY0}G{Rq$;6P><8i! zLz}wZ$;l}#BO~~P;q}=1x#$01m~JuV!2cbt8b{}XS_yXp&VWORl}*OugELkzkhhpW4Hj8ZM5-}^#`}*@$6i~A-hOepou|95L@tlY&@JI^1mQ%WSD}N55uPADm zyA9kmt8Z$8Z^Y;69p4{4%t+p%7b#)t3)oPJq!etDq-Ja!4O7+2{dPem&1DB7r~k;+ z(D#34wepgld|EM}z+XD36wKZoV|(RF5A=uok&#BfWkB-xz7AK`sY0Xw`}glSh8P3T z*1oX*KD0cYp??QT-1?!s$%xT+56#-m?mXOnYW+s*p92GQNFhDvKZ@|HTri7s2zvTi z>&urfT_3haid;Sg-$~uu7r=xE^g2pQEABm@xhQ0AZ^A=59LMOmpAy$o$^W{N956*6nxx z`8Mt&(;B9wQ`d-b9JGn-v&zal6W&3x>Z4L`o)G(M7Z%9O|t ztqKVmv2oRD*!QK`tGo@MHCl*JGmyr3knoGZfP6w%zh^Hzf}56LuifF8hk?ty(fXjQ z>+G9ErG#~en?~u%WucMLjOLG@Gt`yJEC0Cr>JO7V`f zF6xP+0sn7avWHQDS*{U?`4$f5#@E$g%{>sFx?1=`7HCGAbFWLjFe-S_G`jcNPemjZ zA!(uLQ9}OT%K&c*(tkB1WOn#CeK8thj8=&ZHK3FSJbL5}O7K~Hya{69Bv9(&^6X;P ziN-9;w~QvkTk-K*!IFxDNC5ZDk(ueaWD^}79hgR+4%eAANDd|FVbnRr7hUDGCffm= zz@p*({k7ohTu!}AOWOwwNkbv29)wx*g+caBw3ZKwRh4z(At<6pV8;h^_V=$s$Jir@ zRvqR>3b>^Vgk(TS$oaxUJ{4s0i`$a_CSlr#df*)Q0PUp;n|+mMo=eMxIwI&prPbND zQ@N*X@wHe53G=_O%IausRz7!u*j+$p9{1X(y`{QN2@8EL3N^_XJ$f9&twUnDMMNpl z_C>SCD4&@i&QI2r32f89;uusAKu-+1HgvO&`7>PSUjrBFAJoeeN zsSd6qC@|4l$ZAXg#I-_xettznH;eZ6rY{m-+}`B_Xs?HcAC#O~lxDOUP?DtVRw_H5 z{V!4tGbFc3Sd;1RbUTX$|?$Dh)@ z;J#kNi;jAS(|XPr?ECQO=zhF`Iu{*ts1JbA3hG;Tcah~1y>;@h)s(e8Fz2KiyB{ES z@fFOcS_@wvPSJh5XDxpb8DJFR-@SVSg#`&*zh(AZB3T*Mr-!HD$2-EgiaC_!fBY~I z9n&Id;j@X4|4N}pqzEg%YcxO31PuiNSMoB#_voYH2eBB?QPy6HzpV3IrJyH7(uE57 zsMG)5Up|YCr6FPV<$t`O7>5uniTmv}8!I2~~_=UQVkM#=$3n8j7whzdw48X87mtt9Bl zG93iuSOxIXtCr=Rz;>h%6KOfN$2^Dd_!VffF!EU?0i1ko=F{-ZbsPwy%+eukwb&%l6Z;9ocI1N=NjrV|#| z??+!>IhOFBzmtCnm;Y+mBNrpLsJ4eG;^h&K`P`QbWfwkF;mHo`IkLGzL*cnDOb3KLyYpVmJB#=odf!#D94s zZYSi$ZN#0q6Li!XShvDA#U{z0esg^)bNzhFRODy8!Uk#>nX|QTZ zqV$L8#W!w*W0sg8WZ~#p{B>pcWNF;(|1SPLf0F&w@L3ozVoyq!4Y341h1g2r_bPD^ zy_3mo%%|r%!dHJbGsA|o3PwTts2!cw@YF+sR_Ekn)}up=`;cSa@G2{71qG^gIRH&D zCZx!OOBbdiFqY(T=gu9UO`G}Ep0d{!g*uksCwrL`e|SnoS@7-E{Fww?)=)GsECNJkb_ z{fAX8Eur>P{|SirL52m8T*EMAJm%%#Prr%|)U@!}dL&(Dy}W}gu3-4kKX+qxRN^dP z#0T)S(#REbI9chA_Za#U4fA9`@_K@udb9&;eU2Q)+knYB>EOA>jt2NZJKnaSVE@|y zrZIkb`F0QH&`3y$ed7m=`GwS{hQ7XCk)gll)T#Ep0%PYl@f#2DdMCF$5;ytJfO)jm z*WBwY;0wqZ;U@+XATE4G?H@f`CC=wQQPN(9{*#G=!(w0u_bCWIrQmsdfu?Np=lIE> znvvUF11hav&_Sbovgb6!E-e91%W<#aW|=EL=#jRTK^{HsWxSCg%JE+>z%?{8p~Ecf z-qx)GY9!|*8v-yK;i6^MV?I(?)BCDiYxpn=DlPvKxP53T*kaTAN0F)><-7ZYkQRf1Q1 z-af*X?uz0#s`rmI;wkHiefwx&$-W2gdtSs@C@2R}BNnI8X8t5f!q^4DxG>G6Ea1tL z(*wI$SO~t={P8IXf^%a&6zYR8;w857Mn69eRsk0Y@RI8go-zfK!B$Thm+75kc8pb6 zm)I(R@ky_MJa+oU|Eu~PJOB4f!1#Y_I)H1BnR*E!mmq04fXYBPe*+u1Z1sA@6y3o# z*OMpNi0lp5SQHGQ4!<&*d-<>;0vYRF+ zCpS>{A3lr=Dk&}X1xHOLlmw3_YD)kn)9@0fl0yp^es*zV4=MotSp_DkzXNct<>E>y z9)>qPm@S@fu@yO*@5`4v$gB#$;V1UTe1m)cbC<#E zhs5>tACXd6N#DJ2c)*T3oUOa z-y}SrbDK?NzqHENU^(;B;B}kUW-QH()iPB5AR;wx&LKE364aAdxnanqYU$?jN12|Dko00)qMDHxYts-ehMNj&8*84zWWkL zqPjoe;isamB3ap9@Gc!>))C4Dj7EJO0MpPUA>!fhpfuZnw38T$%BI;rwnpL zQ-aBdp2-UPTxysO_5Lvq!e}MmP9q_XX#?*=VfCvP z(3pyFuF{-y_$(S2ta)$wV9xd9b83g4YOrZ%$`5E-L#8OA-DTr8zQ$%C*tKe3hs@a6 zm^ie0a{a_SvKoT_UE z{OR&I3`#&i(uK!#Z;+Y)%ZM6GokwX4p?@*z9*02$@wWfH84Aq%PIg%Xx@ap z8w?YARx_V-b+B;_nloY)y0>VG%orWD%^hz%6(+W3pl2tK!Sk{AzozT^fB(Kqco)F8 zFu{G44S+4BXlEzo?qqZqIE1*IP!la0VlUl8wc~IW9T(iby=T--d2M%pKgi%@TC9Q3 z@eUEkg(XoSl$Jm~gO$K?E?wGT7{rIfOV>Hak85IY2kGo}{FBf)LU1X7_gRSal>7JZ z=ZGn%cZ28j#ERcXB5B+~v0wN#2ZK6*fWI z^uQb?JU&M|UEc!k5n|IfIHXSIJ4>V8CCU_NWr~8o{xVQGxt;>0jdDi@?uLsk;ra7I zP#Gf_9iXAsu3h``d<{2n#(uOe>y@WJIM-q;>rSaKQ?)H;wlezQ`_ zNS^RhvLa28Y5!>W?4imj9sdn*zkkaEA0*{LD{D zZEfwo+##<+bZ(f%g#g}|O3 zTWM~mpW+{D>|D~s#|>~#(Vg}XZ;soD91o^#A|g9mqn2taed7e-qOtJ4rdeS&G)I9s zP)d_=`Ecp!`!Yz5&z|PDG&Dc{r2aM1yFAQhyXzuPw~`{`P#ANhLp?7B`+XPY&RdP% zyX|nPh~;MlKJ^Zq#dhSluX{jdQxr~E39NP7Gx7cznl-Jxw%MEQIMF0x^qP!6Vm=0LC^(b!L-w*zr)z=tXez30++x*peT79}NpBx_xPIg%#$^04i?pfBFtFxpCG( z`J9ZHnAn!t&DV1;gp^mPKiWY9Qv^=3MZh!=6p?JPMr;`c+1--6A}T6W$ps|1RbcA( z+o4Z@3-Gj<;V-pjl z(6edzmY$OcjVVac`TYa=6Y@qXCAIew8Z2)~22u5NTfLV4X& zrv74P6q$Oqm_r$N90rs4x+FJ8U?7}aet?4aXvf)`W=^Op@WU*jG=zf5eNUuDoIia> z&bW+uKmVZZLR~nWXJKJ2Q^Va&v&xKQppVRc^?v3S78aH|_I|sd;6B{B;lXr(C-vn^ zCP=OC0njuI4KLX`>*(kZn*`=o)+1>6A?>oE~#K!dc(pL_wDY-33 zv+S|#bqV;RybBBWgPldmfJMK~NfWH+$dO2?VFo>bZXim z5iu~6^Jte9NB;DHaEe61!u(zY##4=LB;Lrt)|md;vwR3&R1+C^nskP)@bQm<<7xyw z70BB9=JF<(3@_u}G!%m+NKehLFR+k?nX<95L4IRLpk5xR7bKzzys!jdBFrs^M;?mk z-Gu0S76`=w2zLYoLw9y>1koZ=HdT$6WTBoBD+`P|h`a-UN+i*W7`$P^v`}{KFW|)` z6fWcWeDPF<1uO9k;nEm#8HKmMfBkHBaU#Q~CI6OG1*gni=^cfxZi2r9eSVGzs|(1rBp2>##?upIXOirviTn~(MuEEC-Cv(q?QS+$ZCpz`}U7fQ;>=HF)u5O zG!&;}2K|oK9c-m#-bkO8fq@7ZS21uwTR^i2AX)JP$!zjq>VjV*8u_6M{-MKTb4#@d>Z3du`#LL`G#+7Xke(MGzQyda=K=) z4wo_RMY=sUiF4jRI`CaF-{Fra>*usey_b|EjEho++pg4fB56I^ZOskjMMFJOaFZvF zbT}@PPo~i#OBRt~H8?M6QDarWh7)=6Ry7$*#*8E!Or`iDx+X?EJUoOD!Fig(0F36z zlis*~fq&=D*QG~t5CBpWAs^0>H>Y^FY&r014n9X*@udQP{~GJf{1U6Nf1pk-t1=$u zIML7NSWbq14jnmC0z+_>VV3%qTW~`HuaV1M2#Jf^CO?Ipcwy~4Al*ys_;3Y(HVN>BfRmS!cOHs+`&eX%E~khB9nF_ z^D9&$G|J|+(Vk|l$nZNZ)NRfi%qvLw+SaxMb1U0|EA)AOkYPk2Dmq7&&NzuKI$D94tkl}(_0M2Z)Jq-wq^i>Xi(tFg&Q&tV#*&#=PtfHrHFz{ zY+?4!z|inh>{`64!vTdT4ZI1N#0NBIQ*h1Im6$&xdmB{=Bkg;@H|=bNmC8FeS2id( zn1;e|y)O%{~n2F3(+kAMvp@4Va(tZyvJyB&98*=q($n8KjNQ85u-Z$0J#(~Tdxfkn=acx6h?AUyek*kG5_~Te=x4=9CMuYIXtWK#otdG3^ypn;%0r4^ zLhEOY%Qi`S)&&wxzXt{*T#LYrE_nmxfr(H!Og4aaV1<{*7X zp1u}L`)yQ}Cu2W#gjjLQ;!&$%s3(q>7=3VEOV_3?!w~@sl1FE$<)A_2_pe0uf2x4L5A(aBF}#e^TZXS zbvK!rYi}Vref#~p8l8y9;>#LQ-O2Q-pr9bR%!{~(`UAWZ)??$*%zPl4-R86KZ%)A~ zxE;6bHWanCwtn;KXO>$3V$pwbjvqk^et&R|X@7JnQ68ZKC?m@yym;|qBtV{D@E_a6 zIevMokZ1pRX##!TtXDWp{K@#kf+k6@TS!j%&SvN;b$m<>Hn=fE%}eo*2FbIqkt8s$ z3Dy?akwIT)#H%EAy-}WlTvF86q~DGK3;ilSC!Srp#oU zA}SdQDMJ|&ib^76R-%xZ24u>tHi}X-z26njJiO26efQ`2V?XRqf-OPoHk<4b(BG{8^`CAew-Ck)vDJA2Gz#x-Vss z4GgE*1K|%(Avj1T5{$F4aV2{=DYTclRi`o%*yhmAhv)DR$3C>YA7f_V@4pi`6o-k@6Kf+k%7loje&V z++MRgtQ}dSTd(@fq0V10fBtH3@9Ny$!K#;0b$0>8W;P@jy|wBUK!vDH1og0=?-QmY z6rs7gJQ`av3rcLus^1_bZOEhI1;-PEOluWjIVX|DM?zB7`!nTE#69oWsZ*z_J|f!x z;E^4P&s`Cq2pO+4ezG@=+qNO$iqf=sbNfHk_b;#d_5!{0rqk%|3`(zh2YOw)T;WhV zQ;X~B2o9tS8b3bJw}aL>Ke@O@n&*a@X0mb2c`e#o+jP5OZklN^FoOTlyk^yZ;isnE z=JqUwq0^B+n%D~gBtifA$x&NHGokaIWw+(VwB2l3+Z(B=wLorUd&}0`8iaBI{}?J0 zJ2-yr1D%_~kn6ORH@%?hn*QXP#(dQJ_30`SaSttvBTCE-WJ?QBiO^ zEg#mZypsnDu!XLpwd6`S{s+E-id)irR*T3S%(2X7|%a)wPUn0jFD5yHHP_Vr9jpRj}pS$)u$E71+{B`L& z5q_LGe?DvCaNQthC^2b8X{9G$-S5vohw26uL^^D(A+NiqVMqhdpM|R@A1$@i@kv7S zmc4E~4(NAKHj@7HZq4PPG|vDyIBXql?-X=n+LF&_-&2x2y)GX-3OdJXSC=<9EW>EC zQ=Qe|*okTfw6qO1!8lm~b>-RYr*KAoG|uJxjlAWJPkc@_5z9|?+i`&6M#`j`2Y4g_K|xK@ z($czey2y83sQtbm##$e2cd%~I#Lk=$4|)7iRkxGH?TlW~eaFoLApfa6pyr$CU+m3M zefaRk4Zuz7B?jZi7MYpq3?^A2k4;#lv21*&GFMku+a|pR?!L7(e>3^D zka<;q-Hoo5UQfoF7VaZa1!;Zw!1=@53cS^~^2zF6plg&9w{6<08TF)U#qgs#X;p22 ztxQC}@jOM0V1I4#J5E+%SFFyW3a^N_tzwZ02Lcd7uJ`~)`TQd(^bKkHq zO_N0+D(Rg?OeU9jVn*^8il}?{?hWs^oz;OFCZqE;eqP&hbN&QtYr8+x-EzAc`#I?b z4Gfn5zCUtww;fk9Gq-mrn>IgTd!v_wxncpj#SE0wXwO@Ub~3cp^oL)8GyKaijP`$^ zltrA!sqWxp_L@UNENVfmD8-iou%oG+baCzn1N)Oi?q+CAW$hJ=sX2U%Q2w4DNQxwWfrW6C(GXS|l*bi<~JJ7^3G z(lA|}r&f3j!NvPJCKGp0Qx|=xHm<~f-QAl4^+yW2TF@(?mQcgo8s!+6UnVZDBl5T) zD8?~EQ~J&+Yt=>E<4d366r6_bfU2l9#aM%)%&qMS@FzPeAFt)3{%WXcJo%eF&?}^k z7^A%o`D?GrJa`c@S+SCz+$|&$DUkO11@q>yW1DvhIpRShrIcL-C9gNTfWL*Rm2#PG z!y%c&8UbTmDEoRdwEWG2es~y)KO*0H;LI5fFnD85ZSuZHt*$M(cQ1UX^!M|0U%|WB z$E94m#_tUIb^_}ep5lCt8myO7Cm$NaGij^`BFu@kF~}nM%iFgRMGL94K(HD_Sgr>m zc=PtH7I@0$f#2-{JUv&ekeJrAMT^%wnz`}-)Q`c z6@@vp_-mS}%`7a^^$%36^`vxbRSMVsD)#jAAxoF`Vaeh zN|Tk;Lj>n{F;G1X1s2AfY}Tazxxj`hRcqF)rlK)$S?@;e2CR#Y*2l57orvU>_CP@N zU){H;9KVakG8&F?g9`w?%v@LWZzSVJYWi=z6)s}n$&!}_TdQp}nfW)-2;IpQ#09HK z55hT@kT2Kb8^mOUBhD=iOtKwT(*i%!r`^LXy>l5mLt29Y^m_OG%!+BT;A|Udk)VCf zdG6fJ=rbf*U%>@)HQhP@)#-LA*N6@9ECSoO2b`iZ&B(~$?Fp}PW;nAy_WM;MqpCOU z)n(^79mE6!L9@sT&5KCAIaD;jUW$w#MgMEj8g}RGcNPH!?iv;gc3R^sEvtbeqVCAB zcLYsAW&@-bd)(r%h(ah*YLew$8MBFq@4uZ`*lF*QYAm6hn2$wVxu3mGtpkpsfvtMA zT-PcnWkkuB_c=M?e{0X?hLVz!`rjm-jP)pWm^?YRYuJ`8UdSu<+%Q&z&26U1GYzET zpxlqRvQKx6W!+USO@_QAEAbu@?nMDZkNh!Emr;I*2~8WP_WtNY|4uCd+9PQC z-~k4cqIh_ml1sSrDz8fWKJbVfbCQs8%&nfct=-l&e!4k{SbpzmoPhq$bpHI~ce1Gc z5rjNe4L8~uA8!cfmS>Z2>095E7m$nNMG|nRS)RUoRKi78296HdAFjp5nM4DkH5wTa zuZEalZQ+;HarXB5QA-Y9P0yQab?9zU^46?+QJ&3X8_G*PqMh@CE=oFve2^`HWkk;@0xOF$NfRnG-)%-CCE=L#;#u#ByRF30F4UEjiSiAp`+ zA#ux9bNjCvdh`AJ_pdobhoNQ2dHdEEEcqp2KC0-(mB^E`VS?oVj2P8I9JwJOlM#>< zZAfGd@r}aJQ3d(RB_XbwKI#vPPn+r57OPQEw~cV$lD$n|pGWU}<(wJ+`E<{e^^KA) z2X4od@8YLKiV&3B`|XJuz5gjXt=A)>ysKwykD?QgRLdW?B8$`8QaJkjwr$&XvP?@TlepnPT+3wwHhD{@ zE88{&7mI=y*q`(q^Kc5pfkdR`Z|t*vw6?#*?g2H`M*r-K58X@p+r*k2ADi_=J!c^c z;v*AcRjY}sDhK0n*PG2RzOpU7W>T>lDDgK|T|)sOP-xu&%w0n#`{1IekQkF%wQFC2 zW1)$shyEtNJ>li&!!Q2Kjggo_LeQ$rj`c%mtFHX>R@$YTN7kiS&C}FZ}lO zdvf%I3T(b_m$=VNA}s$rV67`L!m)**5sD~Q^Xa+i~e%AlP>h> z*>N+&-LvtP@UhTsf;EYK_UPH!Y_xjHRD`*;s@R13%2bF5`|MRDBr1berrD; z1Ni5Rgcig;QW!!ow(rWVGLkq9{1dw}8%5*&~E&AKL8J=k^v*Y|@55&h?ezP|>uM3)a zYHAGH9CEEH!O4X;KYyOSRMf0_^H(%SiO(KYQr>{+zsTju?=NcpY;*cj!j}DOFI8k7 zf+A?q-LZyZJz;{xX7aeqiH=#NVo4Vc{ha57x=CPalbD+%>oU4%7*sYT-bu$^)-I0S zb8{d5+-o&v3~BTq`?8iFy!)lqgX!qnmB|~!x{l=0qS8_n1ho&IRQwm-c-&tDc`uTq z;xxYrceBagR=YntXN0!i?b(R(`W2U5`W~c%j(_&iQCU))SQ#K0E@-68O#w3&hY=1W z`(hZ4KbzL8`Lp=TW}x3Gl#`+Lk01S(m2&T^WS`O~kHN*T6SpmAFUP*Lj@HYMA1CJJ z<$lUFO;&xEyZNU~K*B^q>`q>DI*C^nmvIdDdGDJc590izUPB2jfmMG=Xr>7Lhlvjy z#lz{81eK_zKyz!-@)Q8FU@1_E`3%^I=%2LiDS3ElZ z0@;R4AwZ!u9J-8NpS5ULqKBXTxhZDsBr}_#POCinttjcim&;%V_?r&6paGC~76(6W zR{8{Ej*oTtG8Ff<=G`3|_zqF=9kQAjD)WJ;J?cpA&C~+n=aVk(az7Ct-}^mL#{ysC z!C(5EcXFBBoxHDT&qJz-0%%RK_hzn!I@@Y3U*Ue~k;&mpceOJ>HME2N!GQQ%kelId{){a1P3bh@-+;)SniU6NB%hhHFq zi{s$)@9IM;6O5)mFW@YysoalqO0;(hGjiXqw3qJhzxTMY3W}`~l6@Gp;sVk8fJYd9t^1_EA(40!zEcXZ7 zZEsa6)?LbR=PR{t_wg)cTLJ?tujVC@VS09#xC`2}E2oh5L_OXf5~4@qca=Lj^<+wt zmx}$j%|-p@c+MWLIqFW%>GY!0`}YsQIb!6)tmmsLJ;z&GYO^m*`LUWx0Vaeq)AC9y zMwpt`QABV8;ZMSQm9TN@dy^sSz(4F1Rn!5?PTS1B<$3Y&C;RZZVVNFdpbC<)_D3w? zp5RI4TFood$o|FMsh*)<+f)!y>MQ$Co=krbKCX%GW1qw`XY2sK9Ay9kN8l*gP*_3? z=f`Ly8^$?*l|;%%bqL1Y4j_-DcUs7Z+v6hUKKVM7QPEFd{LQt=$lagrw%>&wVj~%M zUeOn5oaocWMGX&${vq=_wzNWrvb+W?wX9Q6JZuTN0DD&xHnGYeZ2oT@{+4y9Ea!?} z3XU4xt5vUFQ-Kou_+S{kW&gb12WJPETXHJZP_XoLq_}NvpsrkH`xYIwy8X0#{JJNr z))(UuhFUPA^RA$v4v7Dey6oz#um9luZq>C#T^t%jx$yE4Jv_g7-u5vv!uxFUR(%`O zA7rJdf+%OqdU$A6Ys(iDsy-;GuHU|$F>5(}*EN+uB=)kSyAEk60+{PVD*S z3_?jwkU9g8@@B7|52~k#MPTfw-0szK|7fsO6Nps0ihS^9!?B}^>6Bytg}38 z-!G}cF^t}YRwc3Y#>7dPLi3xr%hPQoT46Dal^`rCnwQUe2caIq;ip~bPhM2sz)00< z;$lTCaFdrtL6p%iE`40?(oeY&IvK=V>1P$Ic8rMzA)Yac8)%n6v{uHseC*|U$LYma z@+?@e>htEFyN1V_53^UC5idv<@1Z#~J5%G*rAsKB_f%H3()!zPfB3Zgc%R=230|<% zYop%^2|D9av5}9Na2CB%Gu%FVMLP|=zNLS<=ZJw5CK`06E) zH6gDuZ~YznX-RSM+@ZOXAb2t6R{3GH|L->b5R535pT51lZ{Y){9d ziEg>At=qO~<94-1*+7GPTZ#b-T9QByf@7BR2Cn}A$-?lH{wrI(UPjK4i3Xvzj5lIE zoJz=k{5XfOaO(4cFJD?kuZQ}mr?V@+dU3bVxfcr7W+rgHi34%m#qX^o1?H0WLsHxK z4Pa|Z}|z^LQL91i71&ln_K4nAjaOW7es%ImXB`W%dl-$5m zQ$z>=4bqYV&^dkcm%$C6twa{>kX~#+4b*yx?JDDviN|nbQPp z1jN>m?2ty28Rdq^sj_rd{iJ+pO{KOG8S}@BcZrqjfn#!u7=w9b-;#C*+odd>SJYBZ z!^o}an*~c_$7a{`cc0`UR+iG09c%A2VRM5}_mdgy`+@aBk+e`nm-{r;9LCl`&M#=$#wbl`>% zpI<>4;IVRLs|{zfNf=`{p4%KV_e011eqlBp%aGABbaKb^fFgF)&~7_q`aq~5wLX9o zWc0=7MPhKm;1EVYEDFfVZ8a0Wa0SK2kt`D{%`R9**H)N3c*4A>cMZ@Y0R%$LT4yJu z%6KH)1l9t41_uYHFBwQb5n$%2Zr$CGLX9X2GK-sh)-o@xU+!!aoDX7l8;|W{G$QfA z=}pk{O%*qXmbK5E9=?xmXA%0z0En`Q4tZm?nqFEP8lPxh%$k;ua=a4 zpIuT~DoXUw*)osdpm~tnKXDZ&UVE=vIbhKTRgsee47Vzk`5zv}4=%8e@hXaQtQ5DR z{C*}Hf1v`OetUXRSS`)6CgDdvox9`IVrbf-hzK_0+0;Tct0$Ru^qJ8V{=j1Sc#fi0 zg2$q>pyC`-N5&FrT)dMIMPT98YxJ3=0li1n>V9GGFOf?Fnp)x(6x~*-<@UYHOUG() z?&mO-wer0zc%>sguPZME{?;*0lAkIn0Ui0Gycion5LLMS+ud*}A;6!KN0h2I;NI}9~_ zp!2a`Suq_`|3LwR;vEIdWmnV7!yWMKiV#ti)T}F-?Wz=_-^dnPs4oBrwKo#ir z$qJEKupWOvkT_ag{ ziW`;!WAzuu4fWlU$aRP*AOnvi@$6AY1oXFTr_)22iOj8N82uu+qO*@GrT0`o zu+Z1c=rxlr!Eej{7hzM;he=~ztnBDh)!tzkVu9M{uT(=b|r) zpso`STSkckF42TfkXgyp6(okS;1?}$e`x}*u&gbG`Qfp%Z)&u9ICu1qu66JC$a2zh z`{GXK8#Mi*r^hbJ+(~jr(g&odqJFj?wJ@{D`0$P~kT#h|R(HR8@vWsM?O`f|BvThM zDl`GZ7W5rc2lY(EDGdXEQ}2xK&2kUAp~f5nctw<0PmG+{ziY#7BRgVWbG4$pG=;h? z&*ASEO(S*nhCH3rp#mcD6+!Bh?sJj?88)chv17`FE#JBf%-R~6OgRvh<^6=|c zqb97GHY3rf=tTOK@{0+VrZ-r4sWIAlXo~}>MWZ)l)rYY=x={VqbB}U%zBcp222Zti zNoG1**PHs0g($fiQTRg42Ba|`B=2sbW&5BT(1BTpyVQJU(jsFVardrq>5)5GY$4>N z4IED$I{xzjq$nlGZQDk0Pp4*QXTIs5%kWK?%!=5to~I11MZ4D>b9VBkYwea>d^>Se zugyE-&82nQE_@vD>2&JK?XBVyv$C=ZnX+@42BH(`|CAqG@+;DJdimVrVozI}2N_}O z56`!|J^K9U)jjf4pG3ZdG?O+1>V*Ix?h_fyvD$`WpZRXO$*o)W;~w>G4RmfK|1)of z_`33N!8yJ1gmB|gqX%1^bKGg=Sst>k)n*(2{JzZ^KM&3fe*EN#$gGtL$NopzQYC<; z&f9-xBhYj4-Q>5e-_K^H(_bSYyaG7U+XN}U-8XCZq%$kC?}bG~?$dMVeknspgxZGCX*Jniu=uj?e5-h!NAxt&_1QMje&h{UNcpzGr2 zhzy2*3RQn`;rvU`qGTsa%Qc8QYYj~0tOMC=_&hFrDjhCArGY!O!#}O_9u=X~8A_3V zKy!ywB6?eE z!Acuiu9`Qm2Q5{o4;y(G&tCV)Kj09MKB?9Se9|v5dJc@CHHqvMRG^X=ym~biac9lu zvFZP!1(-_F^@z5JS+nJrPx?ktZ-WG`0}1Z)^Ef`?>q6_9Z^}oXz+}ynmvc{_IN=SC z1A5l*`DrbAEEv;G6$2_tBWN)M^2i~kON$3BW?~lVE#7PZ%rY_W*0O(UzkT!OWnyJ{ z+~87F81rY25Z1ny?hPN!GsS1VthLQvciOm>exISQ{tpQ7^nu^K>5}RR7004!ePOQ4 zg}d@TM~6&nQc;@$8Pa;#Kdg`jnW&|$X8Zy?ozr@y)T>{AK6ZIx@ffXiJX^e9DC(ww=3nWx$RhGS7Ud$JT9jJ^4TM+^GN8o|`F!Jqu@Uq%BOlOP5g# z|DlwdN@I z{q%e;L_yWS^E-cjX+LmaTak{_cH%Rl-O?J|2`EQ(a9`1H6C=W@c!@)`N!V)QVdA~{ zG<}wgcd9ERUWwW&ikPdiF!D+AB=KK%t(N#|%H&#qinxg}xGgE19N#qd)M zPHe2q7#O*nZr3GDL>8+g>7PODfx^0$!W7Ki^fx2hLA_iX(B{^I<}RuJgMmH8|8)NA zRA(ya&~h<0kjWb+45-E;p_(ET0T)|<18i008(jWw*W7y`Ot?Y}LY;-olxm~9q~VD8 zuO9Bhbu$HABS*8}0v$YbM-QOM8l)vdVAdT=WMFAS86pUk z>b-daq=s~5oIB^1uypxyCJs;Tq?PP;l|9PWR8PZ;Rlj46KHvyAnx6qOT zke!`f-D~>ib9$L^PMZq;nfab4Vj!v`KiqZ!vGv%e_;oDr+9SE)1H;i*| zm~FiqcwRWOg?9(~;mRO}Ihd!^`p>8np7D(Yn!i-?s=o99%8I02`Sz3Mjb#Wk@_*p? zs8i1{61 zPy}3~1GHHJVKtKVD5~&rG$!>J_!?YW2X%gg&!DU;#*>cu3BGKt(qlF zfRcVLdGk5(gDALcEHt60nVI*kJUu_twi`2q3ZofMf=r49oHZ#-Z?=p@R+2D8aq}#v zZHq~e34=X^j}Oe@p2nJ+U*?q<jJM+{JXD-#zd4eIGwZPNfuv&gF+ilLDexKy4*{ z#LVh+blk*n!%-)G21HS*{pW5I`!4lo!+9ld|`DtEQZdVBE!CbMIBZa=?hZY>x==1^STel$qfK{J7HKfZBuk_4z?5wzk;Ylu~H=Qfk@&3QpgBP>c;5Ir2$s29|q=FGcdtOI) z0;auxzcwoL(K{{bJlrvu$#N#hDx}BMDkj>7eqL!#{_-Wx=;Fa}nKH`>5!$Z=s%sog z=JX(rKTf&unw*~@UakRe2aMjvR^TheRBn1~i+hO%q#%JIA$6%(Z#UI6(y9S?Bt`1& z(YM)zYp-9wp44RQfYr!BW4FCO`0umRqGJ~OQ>QhHDWoSM>B^M@_cu+LWEt()qGIsR zRCv$>M$b}rqu2IBCuU^!>}P^6)k3>fWd-(mNVvs+?y-w#?DqdOU;Jxom|BQvUis(# z(BEdI|6l**)~vBlE-rlEh{3Y07uw*}B`B(h?pQDam-1jDhVs*;oPu`!YiP%~Cis}( zXVm>-;nuU!9pZO##N4Olf@=v0n5bSsps9oS?A_rFhcC0>weYFM?q1p$X;wJt$W2`< zxIaR3aJTmseWP~4p91I#?<(yB0soNQA6rz%)b?7}x~rg8ZjWym_?Y4>hae-v*9stq zUy>)+P+|`{>IR9clQ63N7ymOOYTOM4XfGLjNP!3d8Oe~|4mI=8$B~7q<|$y?B0dq^ zqlBF{-oc^a*~yKzjf~J+SXt?-Dp_riXBR`1+aiCEqy=fR_Wot4Q)3QUM&jY0=6{PI1M5 z-p$J`T6qzDO@PzNAH&SPuYM3zmi&oBG4)%LduOC#0~m78IX%v!vwzQ2yHlxkO=6mf zRW666-l8i8YR;q=_(hs`9G(#yYzNTuS44EYu9!A z@@3b6azreCBk*_{t!32!pJ6#`Q-nu1^6QzZ5tHyo&R?h2q7-AU_h8eA%qAOC7;?~- zkTZT5fAb2%Ewbp>yi@Dn*ObCF+0d1=4(-Xd5`#oDoi%n{5mEk0!1C7Lv`KFl0?_n~ zjHULCUHp66)*DkYF_zBc`gEQML(;#0|CBrLJ874Jdtz%lez1?l;|2{I-lxA@X4TGp zeqp@FA5}MhRc^kW$;t-QJjiTBafae(T%gS|?wZommn9R^d8BPi2(bLzj4o|VR!+`f zo`i-=hI*&6BdO;Z@o^+Jwg45q3p1`B;nu?^k>F~jt8GlVmzgQ7e>xUR8U|JgVl;sz z(#x3x<+tndRE(aG4XyzxXrR8n2CP^T-V(mWUx+mL3RSk9Yf#0j&o7F%2Ht+)7UZSK%Q6h6f z<+Eq8%amGYK&&kK<+ZuwCt6jee~7_od#EFZ4RE8;{kz&$UuUXKZ7xmBXne-~ekMsg z6WfE9dWbNNO~2iW54@tJopEp9>gX#|jn=Uhl_{|J`kQ=YSG8mPWDKXG0lqkfc1^Nm zkOZ{kYvtn>oa@eW=4?V;ry3Z2#hE2%y@{(gAcnuZ**(#eg((UWTs;Pn-ex!-Z{-Hu zhJfxWGc9AQ?ziW**FIrUlOZk;AI!(ml$5tN<)W{dj-`j)ky^B1wqc*VxNwu_xVp*8 z$f=f5O=&U`B?)CKfY`Mg#xchv5Zc<>0swnk>;GB+J4ce5Sg&0t^H6`6F>IeM)@{{e zhRIfYbEAm}Mt;41eZqki({kTUA&KO*=gb^n@sUsMi;PUIdg~cWcjx!oCX(o541%xH zH!}+I>Qv)qAq!fzZY|>~rE1erU;q0-tUb}y_N^!Zk-oSPQ$!9OmwH8Cno=AuELkmc zpMU?h><>%G&?KlkNz}n{hgw-#WoR9@pM`erUV8eQs{NeXn;^8U9|B?NE4t*leC3*M zG3v{fEfcc|a4g5fm9e?=cuqaHz4QsQSr3^j6Z6>Ae<0au)pw38{kHV7V|P4DnstBw z{$+lD5tajD-@h;^P~GWl_-ria*=@3Q|>{l{MnEg-T)`+IJa61U4_{(P|D7-~<`e z$wR89e14I*nHu8q)2D6rFy{%0m35nryrsw$1G3iW-4+%Z4fTbA0SVc7+W_7?_bQgn1j~<<&)l*lJL!>BTvcmqC zA(^The>C3BpXJtK@%T17db;ve3Vl|?F0*U-i?y;8j8|xgE|vtNeV|$U<{Jl_D$k$K zO=cx!)Fg7%D+L^y|MiWz@UE!mEP1#p3Y?gXO(lwk`v)aW_W_HxYaVe@v`aqysy#10BxKdKde_J}Db zVG<(b@I!~Lb@|46j0q}PWn$Znv~xHDL>kbR>Nk%0jv=%!PBBVn&nJy4n|bktvpKV^ z9>GG-lbgofDl;=vUhG+!>Wj!aIbNQqodX-kipPAJT*P_Ww5wwux*BcTv7-f%%%*KE z$r>UEpr}3Hhl%U3)c-Tm4_7@AE$zTMiRIs0-@1K!sj-P{E$_-}E(?}dl=Y)#TMM3p zL#k{d+iqkUqMPJgwAT6fzF!%??ABpSNyt-D9qBxxN~%~KoH2s~DHYyHW!_eKa^GJc z3AphVb(#1xh>MO8#`5UuF}&IYjQ5AGBk%0g-gD8_rx;xUSZ=SrUL4W~Ed6TA??yJI zJB=25@e@)Ma%73C^R4}l$7^V441%7?aPDF2!b$jM0rNL$d?{$+F)?=f%$ZTSsv0f} zgc3jz7@ONeBc>-0VL{IxJqFRlOP(SV;T*&LGW3Z!Vlg88*$n=UWW%oRQOAoL^7H4} z_+7ROAS?!LG}9TvDHDk30~>}8hK5_`K6O1c5-s(8+T*#D!$c3ey2K3Lh0EKdmaT(! z9X;9&5#45X{VSSb!ejwP(T;TIhB43Co&XZ53Xfa}&}34UUmdnzcARXiF4fu3S{UZk zsatn-WTY-n&yR}paDN@1)UO;cBw1QRdE`%V-39;ub=2^@o63r2wu~QHBP39#BhGi^ zZ&IT**>-1{r&d>7N$76f%N(d*K|0k=p3K|GLx=o+O-yUnMAt%5+h$+M7eH{t?Eg?P zmg!FT4o0s?lnZppP~pfQLVfNB9o9&C9M~HhFKD)H+mO6;=gyr;#28rG==ev3Pj8gO z$w^59e!6e_v_rn&NPm(!n@6|``XB&zhBp(m<<@c*IGa@s=e?K#M`?B!g)6?cQC~fK z$-UdOkT5{-Ye#p^U{gUKIqCBEu3cM;k!^K>lNOw2vY0=j9Q_M>I0-<@CVnnAl)ufW zCE=<^-@e!6S0VrDm~Fn)$-&{`^(m@ifTpG;Q9(us;74H-h8V>!-MCOsP*v4-p5~4(GCIi$00(_4j z?+M9LU%_PJ8fUYLLT;Ok2?`SfbY`uhmKOcKK-^4&6;{}8;zUMgAAeNtyLPQSfBI<$ z1C|z`SH7WB4r1A(S1<3VC_RMbU7oc4^hU+P{m9HH$)Li)2fq9DcO_l>zvI^OhvIN)|?cqbrczr%|YP}&-0Q% zWmpO!tjb6}ad71J#q5W!2FTPJbV}5C`Kfku&Js5C;I8lPCd_!X_4URj4iGm>29yoAd_z~!)>v!&?LI8|>=10>I`9VjWQYD`|mcjQdi*A-L_!mra zyx5+t`pl{$?dVBx0zUmo=OrcN-0%Y$zV3P9*Ar>UQn!TZ5*H@~&~ED+Uwi_w1Ul#Q z2FNrU{6$R9 zBz8qk!;4incVt>wLz5V59>*X|QuE1%n=PG7*>Gk_fi^C`^|_6+*=4jMD+-lzm+$3d z-7iTb-`3w*b?w__7waFl^C#%nvzh_Zttb!;si2kn!o#&rXy2i#Q&C8jlPU)u%cIyD zvPaGo79)rq&LF{$Um&32vOC;*+`V(>Ek90=Gk*&$15{2s`ma6TojpJDFE_V(M0+KP z3|mp|-M_y&G_=*;0ZZ42qFef1@arT!Q50UE45%w$W~-tgr1c{)klD^$1FS(!MUGJ> z_pCl?OtPu6@A{K6-x%d$=?;mvFJ&+(_)1da7m{V!#Y%o^4MNBp z8jjvy5i*cC;LA!9fRo3-eM{3e?GZ>JA1NLl9=F0wH1Q4;N2IO>27=DvS=oTHT;_}l z+4UMZxbLM)#?l-s@^{MX5oTuVjzw0oSVW_$BvEoozX&%%hLywTYbpS6bu`;iK=FSl z8McIl#jSZRSE*rTtX5#y(V`KdelTsU^BA_W;Iy32JPVQLAxs(uDUo0J(F!|&aC%RM zTm)Mj+_m`?-ikuv#Q>f-Y`~6dk9k|*(EY;WBZ>8LtwcFVZ)T)qAu|Vs<(H=-Z)^z@|a%^Af7t53VX zX`x%H?2C$8&rWI~|7Fy2M8&pxbl!dV_;G$bIRuBLFWGj4DEmdqL+MX@x%aR7MkA(( z!^`F~?2lN2$S_kPpd8{=e<%>n+upr<%Y$5(G8OZncIxX*$v3M`1beBa#QmnMtZW|X z11?Q5|MHiV7?FlhPASyi^7PlOtMjXf?rGaa3cBGs>durMJq!)kh@SZ2Lz}kh63^{o z$rr5jSgR7yWiz1b8yQ>5-rCmxg-OqzfhN7JS0m)n>DW>4;vA0&nLlipEJ_>J^=~tR z5P1(+{@o%Zr&-MYEDM{fA-JGNePSO_o!V5V1VL9_9d&EtQKLq6rK?8QJkU&MXRp5+ z(OKTUd5cwP#>)!ppx5x;whhx4hxY_=SS*!VwQ7mU;e*`F8WDS(Brq&qymr&3M*aZ- z_m4RbMMQA=(IKNlj00r#-pj}s2J!7YWr`P-hgRRd6LNNf+l$5w{w~6)SDOC`9fUbT zAks@3oT{reH~Y(+^~NMn)a!w~jbnN<>gq>NRQ< zNhk>EVYe*n6qRDM_(EDhy<#xVt_Ox%ELVx8R$a_4A(S7 zD5JFl*O7C(rU5yP;&|L?@t8EnF$|S0Z$$1+l_e$GvLWj6$ zYPyIDq}m`_mSe{)KQf1Tf4a&dk{la9?bDooY6{{-E04}c8okyVXyHo5*BC1~se#BV z26J?ayD7?P8I+@V(Jw5e6jm{o^G~LA2sG7jJNp1XX6UNv zS*XTxaZTebI?tG~j(X;1Fn#+?5wFxxup8TcHnBJ^WXRnxlM(b5DAxakjCI%DA)hFGf}~P)1=?qZR&Dxr!f#=-xqbU~z)KVHr{(b+AV7(>ck=8CR9FkXm=Lo> zKdP8TSTgo~+s`*I2!ujtATeCR6p?Wi?{2py>$*|KCjiXq#MRGxj|mTYbj}zW#I`Pt z(~pRZdWhuug%v;4QC1nwzVK%wiP8KM zSis~zmHfpP^>1>#rTG_>f6HT%ik@YsUcH)t@}-b~`53M@wS4tWmo9{QFF#fPm}dFZ zsJfhRAhIf6^&EJ6K}3ckkU*;tve#+~d8uCT`jn~Y(b_S`M6xCcGLQ?$(-)IkApCVB zeG6x=Y#A95k+~Vvf{Y$y7fNR{(m~{qwUF^cmUMvOa+vmS11a=~T9FcfS&O@WB(W+H4!>wtkq`;oBw6eleNg_$_f$o!tp_e|l84&Y-n|)3? z_?awf3N{8t?wO+3ks=mq{rD$+%VN(B{@2)jRp2wVJl#a8q7*_hl~Yc|EWiWTQKfJt zGO*ff)TmMCbuajRs=XRX*^TRPevFXQiA~j_b=dy*S$Mx4L-~muqMoZ*niFz2#yXYc ze0Y|(PbbBpS5o#uvHO81rdh-0Y+Os%lpB;6%W`%t4oPdO+x+LxpFH7>BEi#;P*f);)(VWr z$r*8yh)A`L%dQ8(o{ycEb4m~!IQiPO+8k{ug#2T)U|(2S-ijA;g;%~WHa5WDzX6Ks zIx>hfp*3Cpyytn?Q6mv;&OPfJWzs=MqM7C~xmBxHfH>VwZNdWxeefENw9CoK)fDMK zyo^p)uqXruDi`+je}KOk?FuSb#3%||iaa{bY}bZ#gH776dtx58qVWERDxJj36L*b= zk~M2>8yOxMSqtM{$xTE~OWJ-96i-Q#!U#H#s&{NUX+o8fN6Sg6=dw4%R|Ta9wT`} z{Z&`)T8q0DS>sx83eL05AZ>#=GtKk`$k)`|EY{A1s~JyD>d6x(=pndngHTfOB6PVR zP8s%Y^bS)it0wFM#f$901sW4rLk)mJr>mM>$?UnHXw&cP7A4Znu5pD04`hmux6Xyx6O*YHthRJ?IH?I2s1t8~pfxs4aZr>BUI8cTW`pA@K1^j?7_C ztPjqa-?Zgss|mDFJ@SL%MYVnM8bgzhl@Gm8RxIR>m((|aSaTSaAu@~1`A%t z68vwu56j&?{CNT2oGMPiNWVmQckI|PsXbj2?o$CrI<;jMIZM8}qV<@nB!!ee{OHk5 zJe!w%_kz(@dY{UW$$A5kD(xAuIcD|vSGwZiby?Xi!Ue7g8J2#yY zuLeaI*H?|8Ga=2$YVRKu zFFcF)9CKjrFn2PlaLMzr_Vt542}VFqUGiNzK;|I2iHu0J5fO`e4)6W%nbZ7W&5Pbb2m z7i~A!IBS^+TfKh$`XR0TZZ5wa+_!3T3YlXMnGt)%f}bCb@-Gi?XlXEIwfQo*_|n1hfJCqu&SaBHU^Y; zE4zm??S4R=yawGOaQNZm(q)yQR1OVEs9t{hWbkcu z)PO91!`IV*zWY;Ly17!C^yt%PEiweJ(+mAlruKyBl;DX?bTeYk?{4%i1NS2RQwAN6 zd8EwEGTFRoQ*+0=K)vYHF4LIHI?!A3aI&LJ;G=PFvI#_xYeL_tSL;m15Qz|OFn?)E z@=AjX^Amb+NVi!_h#5rH#gW0DAB6Ro0QGG27EyoVJPY#SOtj7~F81T88kfARE(%2v zeX$f#v1u(d@s2+n6GPA(YN!9rfm3Dh!2@+djEvlbVVPzd zr*~muLcZ?AUtyx;MP-Gbv^pvxLFTODZ_hl+m`+cgoHV2q0zLvHDqj4!=sKiO0X|Oi z|5UCqYD19&^*A+7v(K8Hn=)mGK-6scw>(PsdH9R^8tZIde7otoA`WYV|FLXosrgW?|yeR+6sC`hCCtH7$fx|1g#*wZ~6KAIAtDiFDTU3 zDO*mR@(7%bU(sQh9qba7|TJ2Vt4J2vwD~_Oh>U>W1vx$zpqf3*C!<7TF|kr{+QRk zAx;r8}FhU&!fF!^^_LqUok`xZ)aKw3)`; zTYO|r{r|ZJ@(H^U5#OW&fZB?Rla=?E;agJ0Hy=KjNj-D++&N3OzPXP2eMFbt(wV=m z&HJb}NSQ$cRUzn|y4rm}D?Sj2bM}^bfaamVY;_d2>1KG3kDyN{vB)><*;7lIHe-gF z3F=xTFcFqti;6lL7#KKfGH|#Ma6(n>KFR%HUSc{VdPt=Y+0!6`Y9~~R9`4B7I%w}F zT*aR}siUMHG;i{RBRQfduN39T;Hk%VD);DEFe9?;=cEWacdkFRL%lk6+V4MoV+!4; zA3uChRUV|L9|SVLhq5Y)bgDP}2J&soGm@Azc6WDoLx{pV#%e($pk=SMOu@F`|4m6~ z+oHt?y0OgzzjCV&L9*WDo_KJlJN8x85V+d+CS?dks!Ai+W?GG`AFxVd9Pnz*SIYIihk>{OXEV)w!;h{WERdi<@t%Eora$n$AI$pUumd$Zw#q+ zB0N7eF+q-h5dhN#Tx-M+Z6g*d-Iz~pPv`5)( z-w_!ZncwtLbS5RBwrfX&7`^5j@8h|g<1zEbDQ%CNG5JGxft5V%n|&$lpXy$iWm>*c zTW?A>-)!&GN!xf=`ja>WKn?$R{1+-G{|O(RjWz)*i6qX)&(DPtO9;CDc^ovTe#7Uz z?oY(a6~?;*=6nYTm?BOSDiK7?ZcjRzK)f+0q&&`k(~@j zR3#c3V#Q0QJdtWd{bI(By9rL{QbzH(#Y|^d+9dqS5r);QtSId+O(V@rZR39dZ#F+x z@=UR;aC}>8vyIZ!ro?zt{Ldp$@qlAn-rw)YslNnR#rIX<2=gq{@NY1)PmCYSc~r7k}Htldek= z1}$Q9CU)!3u5?ErA?P=JQ=7VwfU-f@`gDX0rPcbF#Dvd4{em0-Y>Sa(R-Dr{(qu`g zpPv7_G1NkEm*%bxO+4NXSQ2Kq>QE1`)WQBYE~lplQwnW+{u$_hkkT0!-_Ep}9U!5r z8`qd93P!Rm<|1|LgM0V(QNjivw2XT2+UDxNf^QM?(-)Jt=qkaXq54)8`8h-D)vX&f zP8h04cJ<9*8VGk0WEjo`_Ry#_2#UG|J0~C|XRQVrp&`W8yP}+xInnJv9{gZ6 zZ)8M*SN}VL*eT+wLH9tjgAdBHnx%LS?eec^ob}<^>;y5lkNoGrX5%$jL|IG(7zGUK zNm3p1735|r=au3`Tdra8gqB&RqxT&th>j`0rs3iWLlb4e`7XIHT0N_FjC&Ag!X#M> zaMv8M6F)Cz#K9C4RAeAn4TfJ`#x6ixoy2`?yr|ae&p#(E*$_unN`i@y%{KQEjwK8R zm}oF3xQtVB#QvAK!!w0ryLvEP^9bWNJ{8x#pHLeL?&LX?n1lg|TEmc($fb z{266L4%4)MBkg1g8NvS$`)yyk5H0$DBvfwjpO<6(Dy{2NGU=vnq(5yA=6E<8W`+8sX_Y zn);>P0V4e>g|mtR^TId?AILCHNRhsC+9lEQCsVj66gU1;N)`xAc$q(jcv%Nn(V=VC zBLkjUYVi)lLX|Kf=nUXyNOAqr8RA030ZfW15RR4}RmfU)sVoNY0Hz$bkg3o#*osjj zT-!^QClsaM*|Ys*_8t2}no0sEZqubo=1D_fB-8xm6JbR)ELu$Dp`fYTmJR^i9EO?W ze5RQQkR{zXWVoZA=?)msrufSXrjt&VyZ{U!?b%;nCLNoi!oA6SfpFUOr;Domcu{?m zvWu(swiq!n%V+;J>%9xvd{<;V21gu{x!Q0Q(8Wzs-^+ zbGoIRg2TePKeT1t67TNwai4gea1+IihU0O~H8sbAv@Lp>q!P0Dnt#ioid442yLOGD zq}El^DKG4~E7xh$#tk1{3%*=UIfr58F;7S_qd8A^qCs$-3Lv<{z0oSHI!LO9AH`aF zhh_Fpj-Zc%16(NhyEN*IvE+A3I@p-DHf{D1sLj+Bx6C6gf0UGrV<)Sr(Gb-{X~pWg z9n#Cs@zM%&)4A6gClvo{pI5`TZ#6*nQ++SY`%LD}N*?xh6PhI5}5t zAI9ssaLwB6{=$`{ZE~F`l@)b1034-@waky>eM z*K63YWA*CQ84S3C?8+!De^{D-XST`VOGNn7q0eJ zSOYC|ySGn8Wgp&*mYWa23xWa-qb3;g7%g|#-7QR;jV-C)EbA{{xaXOmlhfwR8AIEN z$3Kq(iM%6c_v+SdQ*R@qjZaG^sk=Hhac%ps^v%Hc%+#flYkKzbV!}=hFXUmk=zp5FZ95u(tdJU3yVTY;Iqp`4)tkSS7(k0&w#FCQwX|vpP(>FBJ*-W~?j3L$ z(}pQ*VMRKfm`^OAGl*1`vk{R*a;le~PHy1b+s|TY zV2dD8?QcycO4~~Ep(GtNez4jI9CAFC+JLnSs6K#HzJN;C~;;5?pk!})N$z57aB_c@wUddVcRlh{9S#WyzloAMsXA;$l#! zRO{RK^wiT@+A^&V-e%aGGK2N;N9!)#^wHDzwL@kAuEIY-NJ77C zCW{aphw9F-ulZt7I;c9O{jHjr85sr%7)^#xFkwjT!ZtWCG~tReF@whX)b$B~yp} zZ3E=CWw}#Y<}ajg%$fTq5Bj{|I!L(m3(B{4ejPe4viR}@!ieR3^XbapNTkeA zr4ymcz)Qt8iz^FqC;1-_U5C4WMm;sL(`ML>7wSpj%1VbI)(ITGHzn4a*F1Re z=q-8I@SB`my5-PjV)Vq%F5_gVpvoYPpshkkPCc%HR$lCt<)kGcWhB=*{p7BJ)az&v zd?MPtz$;u07W49p7m3%Gzx`3`(ts>eSGR|e4V5Xpo|H?K1RBANyMHhyQMvP_ zD;AN~f^us4L+J_inx#6G#0~H)te9LH|KuncV;%P8wzJKDo^L$XJv+ewruW|A@g1Pk z&Zd8=_ui?Cq3@e=<1V8i`PprvQ49IX9|Sie|Dpx3Je&14&aCoAwkCCGlYDCL+4u+6LlGoR*j*eL(lvic14h}5CizxBxKU`8#_HC>P zG{LJ^!*;&gp188yUN<$_Z+NpYfivmYpzo&+ap({FBZ%NcxXXN7J}nCjIc)o9El#8r zlp`s3DraN2gm(1kLB|!l4mVvnDGZE*(0{hHPD$d@B2p8>Pt8|$sjP6Sh9=5#*3xh) z4%9xA&a8*rEkEOt*BmOy>fLeHp2!x-Ru!f9jC;!P;lt_e2pe~(N6TAx?hJ>qQWVV< z`6|jw*m7ASAawU(BPF@|W z%hCHQ-+XFJUauCt#HPLNP@7bITLjEDn)`e=f2M0iS~3P?1a4F_5cv+UMvIBdj@?7j zIFkG#IetCs=m41M&2&KAeH6)CsRV%x?CFArhTe!C)B?#$}g+`tR|;&RuU# z7&mSZM9RSf2S9YKtb*1yXgLHfAcBPL9_PBAzJ9d&vRI~jbpD#3uljS!Z{RWQ*$4={ zrh7FNFEmY~$+r((ziyWMA~A8CF{RJBrQdWN&dghl?8oOTb{_vvV{aap^WL?8f0H4E zijc7ZC3CWoDJhg_P{xd9DB8xh3=xV3A|x_I0}aMa$WS4bj8TTnwGEZ2Z6&*4K z@B8=s?&tMf|6JGW>U5sp;qzIawT^Wh$GSzO793>Kx9?7cHQ5qv&U&;mGZ`A2&ok%K z``ohKy}gH1Js3dyUf>K?;fC14cS3L<}7t-kWIp9ZN@c+glQ@>x$%37m9>}ouG zTi2C5|A8Q?vA}KH{{T@NhWf**`K6!q+AjADs+?qVDEL-b2|5z!xj9%`kFgt-w_u`a z#3piBkgwW5;Nk8^da^p`*PO)r(nP7FkW+=ws3I<^Gn@Iszgr3d`})Oc3bR%$^RfJ3DsO8k zW=RGbec$>Ak}_gMHaXPBojWyI5~(L6hqj@hrIRu?yzSuUHrA3ANJ!$3Vw?5+&tXov zr`v^m0C;Gsr?(f^YhAA)rV&MaMjFQr!^Q9MT&6i+Dm55*eln-2S9z(4jmVW6hBz$&Eq}3>*}~7 zUD{$Qm@p;gc7vo4ZgMsmrrB-Ne_Xe1ECtRT>HJST?Tn6~~4X1Rrqyyc4lNv!k&JX$9_{N--1O{>Q;Z^n+UqawcUn=s0l5gIMTEe3%g z6_RVq5eKd7Jgk0Y%)C~8ef=y9!Pr1YQNxXu(-@KxM+>yvRWtzGX{X z>0GatX{q6^E>MZ+A02oLbvUFEaj$^^%EH@Uy3tFdkM1g+ z4_Tf{I@a=i&x!-rrKTk`38j|6Sw$*L8Hx@Kuqboth}3PR@9$@q_O0T-S`8ak7qgHK z|L$oC$>G3Rn3*fi+>meE=gdSKbTUryDbbYp;Fe}(J-iDW5e6<1@1HWj<6|!rCj&Sm z;!lp>jzlqHe)kVxA|zk?-~Sci^XHbHyZ_$OBP+u1P`bm|V&lUhA7@SbxIQT>_3tl} z8s_|1dh(Fu1hs_EDAHb%%UbjWkrk#pe=dKOXCyXGv?JTzv1OscM_|dzi768_X+vg0 zUHRv+1JW&W2Qe4{^uE$Y{l75H_1_l!$)pXU&16`CJmZMu^^lNYP2yfalb$&xm8#bSf%f&Qj7kSw4TvdAtq;d@|z}6@O4AvCER?v2+9Q42igx2HFI} z=*ZG9f1)F61QkSe_xO)O=rRD1q<gAJ*=u!!2)E?%4bK)6lrQg}!c6RMb_h*YSxB){n!L zU-&%S3sZ>eM@2<#V^9F5Ex$=9^}sR%sVd*EjARXYtA)mkAq=}ickuv2 z!)lODm;}GE{f5v``J4aA51Z*D21@tz+!H!A@;dXkjdXTK{=SkEEYi1v-1rnCfB%y` z*I_2FyR^kSY@w|n2Sz-a{Xf+k)3QbtrmCHt@ck`Yf++&dxerTno4H%26|4Qzyll~f zj-C~4N9>E+Rh%7<a${DbuC}g1L04 zXfy$ejOf{@NGMRc{B4>|jSRg#KNv2j&}AuN#oTx~=02&P7yVzQBeg5T)y1k&Y8e<) zLbKUs?x_Pb5lj!Rt`9&5{)8HY8C*<_Xkx%PUrF}IQ5!_o*yR3~{~J+o+e5$j1QG(7 z*CCcT!-w0P*B2lDk;%SJ5498q+5N-xkSdi`~Xd(siGpSL~*< zINNpi5(;;m=vRX=k!Y+%s5i*Lp#iZ&6!9;TXPP0|O6Q0jiRE8{}GG zY++%ltaJi&R=iuYc5N|$hgJIZZQW!du$qM-R(utpR$ZqjSX+vu(xi@ZfIWZBq zQEd;nf8!s&fIl@9_Q>Te6zH3jn;aVff0GX6ai|3cy}~LamX3PecQmE#h7R3>2rGGL zN4Tj%85n)YO*3gj z`bQmbIB4jv1*?N*{>B?OF^J|q)>|41d0B*>gYA~ySs^VpoOK@_ckgS>wV+4?ceok=z4ujve(XG57N&To6b20T(X&&-8UBjDSQN$bDTZ!L! zJuR*XaT@^GUERNL-@ZXX^pLiZ!FQZJzVO{6M0C|8L!XxA67}@y*uf1S z>C^N;7|eTs&4$0ovU9iKaoJFjJ`-pR+yJ_?8Vc1{`{Nr(B}SV(L&GAkWz(3B`v_eLp}1ndd`On^HN;FC6KL_SC)MxZEAzBl*YNBMs_zf*<2V^d@8Jo@LD`PJ#7^e;e9Np-(u3fed5*r?QIulZ%>$?HO{rzt?<|L zmZNR5R{R%i`UQ+Rf6qYmYL+lg+O|3qbN2={RU!ps+@V7wpoYs=f?Kw~_2)cNgZUSp z&^a(n-=LT5)i-`^;!ZkUSIcls$S5pq#tH|Mtf9>G@~Y!_qF1mj1OZNrSpI&+PZ~^*w5spgFM-lq8NPooupiZ3&Xb5CpPZN-h^K5}UsZ?ax zL~QRL+?X$ZK*M(4g{maAM$ae9RwDtybE5@lVaJFYu(Pq8(c$b7t%6dy;{0R=$=iWR zq|{KZEs)b~`LAy?=u{rf58TYqv&36vpW9IWTGNPpu_}k>EMv=4T9_^^RJT14vTua<$)cz=mH&3TASw*`Mx zr$`l-2XW-^9};*0dv2E)Z~BQM@E}_??A*CN?bkIYPxgeza=`O8-*N3yIN(8z_ph3J zE=DicKzaW7(J}D;Ug!+L!NkZcV(HH8&y0kC(pl^wacqO^H_f`6=blkFgJK(DhoI;`QbD4GTq>9vQKH)FX%Z8LY6G zIFcLHY}L0Z90Z#sOHPmak?(=QA}OFlMKg!E228434O>Y=;lSG5>#~tRMD&%8B4>hR zmv;3JD-HWy7P=&v8?QXa{#cL79{J?~olAdltcvlM5*0Btzsd0kn||ZA?%e72qPX;K z?&HU4RyRtBSZ&Q-4Wniz^^+8O84WXGsS??bKTen1cbZxry2B@t4yyU3Xa}3`r_FxO zm_B_CAed#m^Axa22E0L!KRn(1l!e@H$@kNzx!>g}$Bx}j+Vw}Y&!HuN737>AXmG1%;|h>Yw5fp* zY3`_J#1;f%pM>Z#*)taFwk=y^+bfnLH?jOMes%T)3~@kbn6s0<{M=R7p7{?2|-2g>WTEzWYP0TT2^4Lqx-*hH@%(hFtXxX!VkwCX@_Q4 z($N!t*)oV-JSo=8t*5d7y>JTpP4v%F_nZmP0De{FP!dqh8s+CnDn! zKZ$QCk()_;2|5eL(|zlPJ09$jStqEx8JKn~^WilRo@bbd-K|LHU}Z36HfiD!_`y0a z&yZdK8P(&_oc&xl3u{ebLJWIu;rHEKax;FQUwQ9-X|wlomXbBD6)7{;Pnqte?Q1{? zi}JS8kd)f4YzBfb;ZjrIZM;%hdF2LuOT{v|_q|I`nv)j(Mg?x@42j0Rga({9@Ui`lNg{=k=MxrE)R6W0>n=^je%D_Y5 zkjSRyERy!!CM3ih_M{v|6fcz#M>K&>8{`=~pK=~qIm)VEjW|kF zl^eGPB5`A!_i5G#RQ`OoLh%>Ij>tl_s(~)91v10i1C>gAL0Np~W(7Unpx!V=RUA3Q zI11`45>_odl@vwdDCf?&^q#x`ahy>yXdQILp;|b(Y!oY48eP$g=-3n%FE)+&+fUQw z^|?ddlSUt}4B63jN;NudPhY=wD_u3u@ACqii913*rnvlcdt9bA^T}b|ZwHcF_MRV? znJT-1G*$eOqr72P4iREN#SzEwyXKub)gzM?5vbC)^dw~m(;-y|E;4DyUw0pYdnyXG z1K#HtHtqAAk(>Xnh78{>SvpqVY{cm?TR%|QiHa5l*I2gwAS5v%lg+cL?qujW>oiX-JE#G4!{&%VSN}wTTUl> zK#xTXANK`T?=kE)&0h@)v2v2dEi)tGZwqCb!dJ)|aD3)&ANIAjK_TJKCw5jLPPvxH9;bazVQn^+au*FtqM{FWVt%E55_hem zV@P|mhD_QsAi5btc<77{USFIFX_zo72tDTL&2vy(J1kodHhYQe(fkcHZ~S8K)vHzo zxOHx#KtNl2FMUP2C`qVW8qQCZv4JyxK6d<)O~G!>t}}nh*sv7fkLXd0k2@9gKa}%9 z+v-eO3UQeosX_d{v$dX*rGNd8Lp~sQ+r>fP3+2{K3>tH!jpRJ`SM5C zZrr%rvF-zs!K2K{^ga_`-F^Jl?j1YYD_TPQvZzxqx8qma4yR4NhW=pBWTME=?G#i` z9`uo8#~Oks77e?Q{eHl}8KHE7+xkxcP|h!D|#%~9P75VuB3ChW@iFe_4^=WSL$efm^^ z9hm4o^BRdCb(HVRU5k!DjH5S|l$*Wfvd6f?U-PK+OrsC?N_Cq!_0615by{z@a_w56 zU3}8}pIWWQ#6322fi2zK5 z-`KN7+~4|hcHdU%TG5&tmb7=RI!YV5t^^YjPd_p^nef=I->p&iQ}S(>h~q594jPx$ z_-Uclk9&CH^^9W1s;nZ#-Xn=2))a6e#vc5#b5ALiwi<-0T@TAvB^dTv8=VlsdSB(x z|66s^#Z1Z1Ve^eC9ctYcvuJq&&e?ms%(=<=`=^CJgGp>j*F7$5V5au+n9{Cu9`{8C zS6hZ$J$~ngYwem6qT0@Mhng$7`yTAri{MQ}fR#ix!!BJM_+sle-MFW{lg~T245v($ z3#E%U>#e_?wRMltFp!3Py{v!asd3U^VCIXw3t>(&ac^`fioG`BhN+O1*&-SVSnQZd~FlcImn5hh7FBAW!J#dMq?#{MB#ck59wBijgiS)lgBPd zxO29Fp;>K8?#&jf?vSt;OgZl`PTNY1J8%o%kngn44)4}U-3?=!1@VhIjVt1Gx7+Va z^=#m||Hu(7p`eM?KJ|1jCcw80ZnKaEyEsjXI~G<;0Dz9gXVxC))6qa zI`~vS$Yg2F+Fc6U-ZCH*F_Kb&BJ`EXEpcHG5tqo_<7#l|)*yKW;bFtKo7E7~o^*MD zvJ;E7w8LA`RymJ|c7E?+oi??45@>DFF7iq_u73iV!NR@B=7|gAps|4Ho%`*FN7pg$ z8U2IDNKTk@X-&Tw$_xg#oncx*OTN{o%fx7m$ zt;_ACpMZQqRBgH6aOB?3Uwf~O)~r!?xnXTlgMqAOV|gzwhI`2V#=YACoC~~Llzcet zf_VDVt)}778d2m*k`u;$5}IKRX^N(vY;53Pf1RiwT`#;`4|hd*7z{ztr|l*#jARSu z!%R#g>_nRgP9nxWXxF>Un`+jM5@^sx?z|ciN`#0qxfiTM+SqWT#=W8Q9?Ci+xg30K zxSx9y2GFpzaCv_8C~xneTAazv3m&x({uoaPnY*B_exu<3Z~+z!VpAa-vU^y2{9eZl zUc7i>0$ur5+k>pz-MIR?qDk zk^_9n_ah6KxOV{}*Ry|@2YH=ERviOY%jz-Oj1mD=N}{`#=iGqkp;KW%^y8}E(=jUM zeX&(zR^Tu+g}hWg9_wNXreCk~7R#D}MitgN$KZX702)qukxY=_5MX|8T$qhZtc<_I zu~lg`d{_l|XAf5sFxiQ^Au(3VlkjQQm6s#5bQ)SB zs+67YBqNOGS~SpWLFlYG825V)Px3#1dW3Yhf8_g-pDWb7B^Is1ZJ*6po3z<3{sP)@ zLgRV4L4Pqx0q$sHY;2^j|1|Lp^OM#3exJTMDk`bW*Sg)nc;{zqdew+~yPa$7g(Ll* ze(?1t#;aM}IhN-zT_=0hl#>j$ROI~^B8%XLhCOTn52FDm!4Ni3T8xg~E{?CKP+RX- z_@8Blrv0|A1CKQx;52P+U@J2hx2>CV{5zqV;5^$#J};K-(kk;k3yOoLd@$-z>)OHV zZVPsSbT`p`W3bcVn_Pn?le~j9w?#zg3d32-H9Q-!Hde)#`EzYYn7PQqb`wW_44&Yy zF`(62&K{RAWY5@X(9#+~6l*IFxth$aCt+D5jxC5fSLyVON ztXLTz-xf4x4XwVREg8)b!a>7|-Fbab&0rQ^xQvYj>=*Mj`td_suH_@Cu&gN0P?inj zy+&N%83xgZkV$gXT5Z9!Rbju9`){E@5+7gG#yXyrWo9NA8Rbeh^x%YhTlqGHPK+Ao z?i$t4CBi|F*FapBA<0%6iALJm1-`K5h5!Vm)*PVMhE*~+fj}-Jx|xE|-~dzQNN8)zWW`s7DarZW%tcB>-a7>X1519hMSZ9C#M6TuVSA1oaV%}>Qq!P1aWRl` zU_k&mkIWBS##{}7JRp$p44)Icwpv)#=Jso4=q|~b%R@Yi`c_?o z^M?1FwB8TX{F>tc6>#|Q;e4l{-K02JkEiF?Sb_Obrfp7B0g@D9<&&@U)2sTn0#HPS zD!uJI9kZHL*>dV@wyydc@V%NsAnEY?Z>#8&sUEM@N9(E^!JR#jg=5gY`^ZugkLuz} zP*zrVyL~&Bk?~Zy5tnuRqaj~Q66sGdXf2mV(@6Dbblqpn$ktxI#B}13VOarksZQOf zrJ9%4{VTPNv7Wl>&MwU*rUX}yIv_vTF=mLL+2Ia{i(w!|~P$!i_Gx>cV~sQU{%EqL=r1G^C;1_MyO ze7D(&Fv~-*Ck;cTkfpucbfju}0H&6ay=sSlu6h(kkyr4Q&0H0o+elZp#&-LxRnhC} zsNO*~7qM;Rk_3AYAJy>59>#|5ydsunH-hmCjR6rz*H;6kh$4nCrb|ru{YM!=4U0Q2 z%&O);#4^THu<>3I!4TuFLwune${*C0E>$B%bkwW~SIw&5oZD%+=`b!+Z0=B94{aHk zV5Pdye*1`via#O5c4vSlK#zbZq}!?;G04S0wJ2H@KYOO8FjgdqHRmYWENI2l5Q7O* ztVefP{8KzVFRzL=&;Rgc?EB5#RO{qp)9v;(0slzJwRr}>hZr5&@yi!fzZ`KM-5O{$ zse(Fx50sfOv=729>No|mwG9nTSFc@LOOkh0I1X&{7n%F-)3KB4^-Lokt7k+k(Gc(B z04*NH%-{cTNqnmjWlTsnQ8Gvf_2=otCUzE8EIh+uo-CI?jl&LOjxD!`-~k5O_5P4upt=qvZYtsl5r@6M(pkz zOs7nq=`Fc4r}c}FZ3zGdP#^|&6kKbG;ff_~1AcUmqlrw;x}Tk$JtXN=+z{3QO=Y!- z4C-Ymx;B$HmQ)ThCDJ0r->vgnyLi)reZEKMFu5J3%DLx8B`qu#YA6V=7kRGMa$RY! zVGvh;AhlOKVx!|T^Qs9M`6R`?c~kO+-YA5eg06_FMC7j3+( zJ#9IVbkowSSH9#>6y|3|sEXPW8UjWG?4!(8`?W4wZLay?JwRt#z9e zv}pwJjUT>Tex-W$7h)4FXabB||L=l;^y!W_p1iwra7U(XP|}(O5+_5@*)EcY zzg!P9h?_C6(3XrC{QVAHMtBiOms~z#u zV6$q&B#@~ULW@hknhhKe7e4l-b(=s)0fQ1<=Jy_9R=aBTe&8AG;c#K5L)#Mz0(VEP zE_=7Ry=p;x+(wEnh8LX|v>H(NSJX3zmsX&YH~B?*8C4N+<>1iPJ1n+w3p7 zLWW6GyZ4G{`)ki)flw0a5EvvbKyPFk(rb4XKWv_wOxO9^9 z+S>Y72L@Joc*Ny*)7(VEO1_e`Vh=B`m+$*M`Qi3<+zjJ(41F}$qh_uk<%c`5iJ+TQ z@7;0WfUjU&PnquMqnWgl4(1xzYk)su*TI|3Bt=I)XzbG>#_PPikXycG2TyjLc~d{p zy=k1(I+T&X+*>R{Y)^sqi;l%-owFn&uqNmJ>c72_Y}7aaqggVHsI+O#M7jj*osKE? z#;zk6B6420f^oaG>bH=QD^t9^JIQa61O^2StxI~j#iCltJ&>LE0Hb>V(Ks}dMzz?- z1~sg9WX_ZRN(M!rDf_$hlKh(>jSVl}q3fIX&DE^8>g6Y7UAcT&JbP~w4e(YtP((QXZW2L>0YR_(>d|!um1qrSU7n_FxMWRv3BeLi`vO}5pSZd-@oBL#@X0_2Q z;!8g4i3B^GVBiII>R&)V;$Rquc|9t;pHL?Vy$a1@;Pd*rzIur zeHvXBV^yY^p(HW+G-m#MGZJQ#fu^_aa2Jy~$D2&_mCa;9y&e>l6u4b)g=fVnoc&~s z9zcilkiGL8HEt}1_rA{~Mmr{t>crzIsV+BjE0pCTg%Sya**JB(m4qa_lXKJ3hk$FS0h)3+QW z=OVxb$zjN@HGwK*mKt2HanF%RHUUBppfW0A@_;0Skl~aFyBbgP8nhCxOfm${|D(93 zBWK1(S%;LYX}77>Wp)9#&e+nX0Cz*EG1CBlA*a=l%Kk?6>^0`(8n~ujVfkY~y-ktAB|~w}WR*!wK$^_E>cI+6QeIDWhG= z@DU>#*9o+u%M=W_a_|8S3bOp_N;!S!h?z+LJ7dpLLzxGPH-AB6UEN@M(jgKp?unsZ zT_rvw9j|o=OomslUbSAh@c8@ka&34z@nL1JUmx%}-z7kcie8J9_4x~PpEZu}C!JoH znEP%i*;4y{M3si|?`|;K=G%D5%qaO8!ksWoO<|SGFAEbZ`gaf(P zd{Ef3s?>iERPV6@elUiFbuqKNcD#j>Q041PXDILB_@2U~z|<^0Y}S-1doLybTS;5m z5l`tlZw3{VLGEJW*1IQ@c;TlnwbdnV8B5RqX`W5WG*845P)P$gk!BU3zpl?1`ND=b z?kBl+P%>y*>YCwqDZQ?kCd8sAW) zB64aorg-C(vGv0}i~BIXYN3_iU2&F(Or0OLWIT6w+-v`}39}2XxGh<_H1a_fxtekW zw9TwF3w{U#5Q4pF31%}2t1CVd57Sq)27FxV)!1w{%~6@6h{A+4HEw}K;i1NKt%UZl z7f2R@L8nh&$piAZqmQKp!;=4^N3^80H!oXSud)0}lsE6T?Y_DUY;8W zq4NVjMMHi4J(&$O`56|l;3C+v$yX65-C=XI{j6L0xVvSeGmHGcPxqKMT>bQl%CtMf zf}B77;P7KQ$Dwa4H|K1TWF^LHZ(5=Y|IhRX!0PIV`RHv6k`?tvI-#_f{E;PE!9#g; z=oF7^ORu~9QF=2n)cDvN_z!diJcC;|{{QZAcFjLHzDY)G%2#sh4aguBg`sMr4o|Gd z@KHJpMwHMQv4-L=nGtI>@gSBdia#0)wkkw&1OD$S;;E$!efZF+HU)(N%4hDigHL(S z@b*PEXE>zV;vaJn#5R=kUr}V-HHTi&u0@Yml5ik-ktqTa9>uW_@xL5tyuetx56T{& zGew}e(pZiq>jmW*!dZguXJ6{vCcX=eCq&ofF#w~7YVpp&lucOeDGG$bYGnQ*2M4pxf{-g(9MDxYh0JTMcyLFIo_L;9 zybcE*sJe_nXIuKyOc9zs5stxs?^&{~5X-4#Xwy;%FHxH}6&wjn&#*G+ZIY6Y` zf(dhMxEa4hEG&dkq7>_XY{_3TSU?6v+VAeGN26TU4Y1gYRgbbC5d;WH*5E0_`Z4WT z9G33gySIlx8nI%&17nH&LHML^yYH)#K|7q7055&d<`2zIQ|*6chC1?cCxe$7QIJCQ`Y&$ox(h7OHJ{k+XF1;(kYm1N>a^v)}93*QYWG(XUDQ z_*y*};^u z$%clWn(xByJz}C(NkOK!9OZ{!*i-E$|3?EOYr#8k1cS;v!=Hc_~o|iiQE^9quBdQ8QD{~Vf=0$E7^bP zn`NiznuLH#rYA&%F)>G=KZ<9cxIpGS|NiZcA8vLyP3drO-o5f|p*PgP9DJcz zNa4Ph>S$}1(84eRu~Lh7PTXAlpyo(}6xh9kjL2;dmehs%Ld$!H?8L`5~qGdq0e zs>4(gJ-`B}6npdC!T2HV#6JGp#g(Q$C-3Uf6Bh?A>b0+#s#GsoXW#Djx8A0GiVh~v z*1ar76T-C;l{WWp{s5_59+i)>A*7&^ng<4yQ_75k>;8Mnm{&-na4uc#5ij>P3zg+o zGMp9*3d0*_?>3Ehblj5~`X{1AfFu2Ygj?U`}WZmK+Pzt$~SEJ zSRveyTMH#8^E1uAJv1AXRukq3fFX0#lijyQc0(aeTG#fMggyr9eyIF=_iY;U=9SAy z-;pDR@elQljrTwF)4ax`)~8uU|8N*7rH<Zc)KgBuI@3D*Nggkw!N}M`DH@vrXE7>N zjiDg%X4Nuijnq?QAhX@p^*_=H&g~%T<%qsgpT_Dt!yw1F;2k)A>v`eAdbF}BAP>v8G@NA#7<$TUnK0ZXS3j$Q;Tf2 z+lA}!VsZT-WQgoq$)KeobD-H(wKyaSOdqg2Ybi3YL=1i_`0ps!`7(on3l{@m@_}TR z5u{}@E@;>E2Yj<+hI_dWF;MBsfL&U$>b@>#cjK@Dqg~{bOg)@Fz}u`d9Cy-z4AOY1 zqNL2}(18K*pKZwPrl$+a!3IFh+CF>{I&zt3OJ3J?;VVZ-h$+rD#z(UX)?o07tEml< zZqqXdP>>w}0FsYTU_nX)YmFtK1pFY{pFAQrvpguXQa`Wo= z!%5^Wh9)K&hy-gX2%q(s{an-EdBOGQtp{1cq7IiP?9>n^A_XNVVCEWJ4s~MR6#h*K zDuzgOWW`niQdyMia#6a%U&uhWMvLGpvwMyrii8tYP5JfXNu~H3${VCeO7h8KjGqC_ zUa0GXz@m=uMGSC?*nZ=}g_sLBF5i@)bubnZ^Swq`?^B&wwldWMBfj%ouFS#n>UYAv z-5~z`QIS+J^ZW7R$Al@7&IBGyto!XZ8+P1+Y8ygi_GLom395hTBa)~wowS884_UVy z`Ki`fw2akd2E*vR>trw-UD6YOJ_>lX{CZuN}{mODyxjR&_BY*#$(AXt+9fQ>xDVBY27|~e;(I;3IawS20;f)&u4Wn7 z{eLn+f7(r2IQtdVT1`aXeLr074z9APk<|U0fR&BKB9-jTrEH#vnN-;A2c0G{{c+M# z%!k=~?T`f|F1Z}e@5!noXGU^{107wnvviH%e+th9d#q!fNM2Dmw;k1(5xmSPkve7SZRub3E@4ce(-)<_?cd z83MmhW=5Md+SYfm8T9`i*^R99c>;?0-8#%7j%cQ*SDVzBA>_mR42t>Xo!#f%S)+M6 zhU$s#uNEmvv!}M!16}n0Curc+?=9*j$xZ@}9Xke%Xsw2(W+QGwmv^p%;)6;b%TGgA zYIVg41V>t;QgZKa)dz)yX7fKFwkg(}7@6e89Rsuo2}5(9&sSqUo^KE-L@4`3rfjfm zSiV7{?&kyGWd7fndl1qLK_4%Po@DCM>C^Xd{B4|>7Zb>fY(iQcgLXXsm&27);BwD! zx0TOAH}CP|CueaC_$!7TK0dnRPt2y(uPrD=R53`DV+9+4y8vJc+^}JTqAwIgwrA3( z1sypbtFVZ%@t;>j5i#qsrFXU1k#jF6Afd?bN^nrlD{&(Fo&N9pG+{yqQ`D9~bOJJV zD;PXl8VI;JU90%(Y2Jq|SDtg;9(FlFS;5M>n3c7!@NR+#w!!tmwo~CiN9q+w%L%ND zO7~i$=n%#iuZE#qg^v1rU0Z}2flkI$4oJ7XYc*(e2L*l1ko3lsNMKX+CgfWOfBP_89 zGJPQxkg5%yL%{-mF0UN$ShKzgJZ?rxl+C#=3JP)POlg@+fiF@C8t$VyE$YzDtcNQ9 zDuyK1YwlD3{BA*}ZP@)JbG}rLgjc;-wK@UHegEn<&xq_VLgUF0=XJ%dg6go*`fDO;t~Wbh1boq%su z`Rk`#@DbGo+g`nUw+RV}_&tbSZ(?!N_0ad_q#|hhQvy-PXf~FRWvDI?i2$usxtlCP z@>Fw>$BfD0{X3kOCQOiKX7f2`S8`oN&5mFQu&IN1*;68-&le8AC=xR&NE)CxnhO23B%J&t$d9xmvaWdyIqV~V@ z=V>}GTxd>~whjjF-}j7fRjc~l?zls07`&(7GPLC-{ev*Q&9-X-)ox}bIYE<=@A~-m z%)6-=Ylwi6_D5T;&B@VGf&EN1Eu3)}8fJCq1=EDH#M)ssO*n=x#Dz_D6oLSUF7ygg z`<$7ow`FG8Y25J)ZeMCMyxK;T_NwX5b&9|PFAV`dT-OyF5>hbj? zc5}|(eU(}Pn84&&U~?T~1GD~BZ>+kQZ-YA*0X$(x8=F7xV-ghs458I5c6vTMOT*ZU zs#j(tBPJ!+Wcf>z@7b z_6(=4nO)Uyw?X0uC6gfhm_nX*GSUcP=y)wd zBcu4R*e3KtE&_v=Q#`BQ9oz_hKS+3v7cZ)_NwZ*n@WBOS76_DU!sw-14mJ%|;SYl| zDNn=>20^F{K;k;{$&0j`HxH$DiN4g|Nw?}z=SZQ3z7qeugSHNDwnIDu+GUOdytM{2 zH}pDHZ6ZC4Ea5AuiKc>jHZCl-At2j5CfG`K-S~&K>+c724KXd{&LyIETv$v)-t-WP zTk4p8fU$c0RAG5=4&F|}Tct!A{%_GEM9LZPH0PZAw3S%7t`(GJ_H8213*uh!_8Gee zy0~n~pOVms*IBx4PtFenIfzk9ij3VLBFkZX^t8ugH*vhGn zsKp5T4K%@Qm9>1%9&s0i5RHNJ(#L0s{r;#m?&^CWU&7f7%Ul2NJLWhL2wOZdzNMym zCG9RyrVzI;LOeykeZqMI-XW8VGJ|#6{8#~5h_?LH#5Z6ytAz5^pmpbgriQn(T$j*7 zv>ysQDuOk1!?I0DCB^2Sg(Y*n$&_Ri;9kd9{l??JL5BmT1XAaoGTy`&!V+G-Ves6Z zF}MB_9+z=n+yK!8CJ7H7i|K;+;9@-@)snQ76w9BTD&buU6Xx-PN3eZV<5N=I>eH%% zhAfpTSOjHH8zE$!dueFqQ$pvW(t>!3Gdokdd!4Y&hE1o!!-I#xLT;Qz4tmN+Ufqth+Q?Qj+DMB!*@Ao ztOPCDLko~JuSVMU(hdUI^)U>uYL|Na!%49Ut}3*)=F)>ad2@94xK-)BJ|$G5w<(XV ztf(cP(~I8j>>s1O-CR{znN5W*CKVWswq)0(scxOeo}aYL?#AYXx|M*C=OINzh6j07 zuiB?aK>#Fq@O_*5^0-%*fUaLxwN_X)p@0l!UF$hrs|xKoJ+P31CX!!TKgCLeoT=2n z)ze|et=K!53}bR_mF*eiRljOw$kwDDgmuwxci|sKMuWMH?0EJ+{ik6+b`iKXLA_H&Ly0B0k2oHv8Se=hSAg*=!L= zhKu7eiGc6aKJ8zWM~;4f<@tOn$|8cRpdq_QYH#mfbvap#(*YK}1Tucb+sNj8G*&XH zXFW>D$DQ_%Xeo`mO*>X<7gSfBP4*kD_GUmygf#fdtaZQ)-G3PIh;kjwfFD_=E9V_wjQ4Aw z*6}4co_YFWeZxnaYJW0jkp(R@?a{;a?;R5paSqd?HxZy!O%g+npKMZ$c1w$V!QPrb{{k~!G-HkaEiSCZwV3t53Pa=(67;^Hc5pC*YR5dMz zN12D44)$R z5buNpYS4+-zdSv!F3Ho9T~;64(2AXY-l0bo&7+y!q)Yu3qSVF0!f|t68pTv*t3n1r zqp9jC8X7i)=*3+J*R+M&$DocoImP=?OEt%FIs{K07RCmbeOGenBXBjE+D zM@Me}1MbzUmq-Qhpg*whjR1}C7A3&J?FA$3v#5xLt@tyT;hq z!A59icz#9*CL>9inYCT#r5*tZI-|@j*JP9&SWZD-cEn_KF(5hD<^|=vFTaia#pCIJ zgZ%-17j`mQzXY@i!1b;`;q;{(7092^~B>C$lGj# z_mnA4dpi=PB32k$x2dfPD>bEZR{X0_GS_53hyViW$RtP{S5B`RVqG&#wOTaYgwe+Q zG^a8@lxsNSR0lvL3aoB&U#DPlRYJTIqb6lC@nu?n-bUD~SFdy)!1W2EdncBzr!ei| z()WMZY3;GCYI&RjTe<)agNNIBGPFrWN8xeHL=*_n$2$FQ_)q@PK&`gFYAW524e7r8 zN>rVNXqK8uE2setMW1dG)d1BrWv%<5V)BKJ7lTOQJ(L-pZe z@4R!5F5-=Wqpa&zo%cpP8NCV_Zl-zEw-M6@GZ^MYpBgbW5O=|ittNkD{_3WXN(F4HKd9+V=4nol?~juXTq!CCdSPjxIMoPm& zelW$3l1CRokK*v!AcE?1pDKk(z{&oOCft+-Ogum1sI z1tF@;8AirZ42IaX$1dNjCM{a5qvuY0p7L6s?n1NmH5u}mE&WKGIiF;qP8EkU2(t`B zA>sw}XLpG;97>OwhZ7T5x^*4`1W(sSO+mR!W17ajB~=tPDwwn;LtJoQKDW&)r5Rb3 z&=MQ8s;;!?zf9b8S3F=y|DStojWIZ zCVPWk{r)EJ=(vr+B8$?uYhphWlbLt!T6);4!fdC>7$hoB-@fgiIN{)^V%o)=zoN5# ze>o>70|J=PU3z*?Z?`bLx=a(CnVgg)LxSo1s3~9z>bsd+O%Ynw5?HkXtpHv_5k>5h zyRjd>eV8G&Gj|xcg#}TZ#c;~Q^~_B%?8hyVXW*)PA;1h zKip$s)#0-T)?YP+{ASWjaT-*b42FB1Ih9`Asg=a}DSrN8_U+UaVD7=E)V^&$ zG`#1ZrhK#FkLl`w+=!fQs=Z`pDJ@Y(!Z^CQt>adQmy)41m)0Ug{c1|%PEp&QJ$Uq} zUu;wS%}A_Xy?&hu--1WfEpZYfAwbp!EU&QSB|I)KC@8>}1vYn+!iDc%-u)SI*<(!F zvfkMKJB}LlM~Uwvm%S9ude4V@%>MmuPd}Om5ushmur@l>^3@bNO)_^*rreQ2vO-zF zcvCAP*j6lUY-(WlCUSFp$m~0$ysQgPqA%dh+KB8;`4}L_jlhrD!4e zO8?+`$H5S_uqub~s-^%|N)M5w%mD8Nnq~~$5it(hmAS3pwNX^K;2qD*3APrB$=kUD zO(Vp!{lc|N>Afv1Vu-J7OB#L1!?KuaiM4fbX{i@AuDX(Y0Sy zbW98rx&$67ZYAtiCJcMnlhii?Y9 zdV2>#Pl5(`^U0G2U}a9dwL4V>3y-I;8)0Do`=A?}m2&u) zMdiX3^|XSmc|6BL)a+;9`}CpD&w~dJO!w;yfG?CB{!??E93P+tYAW6(nP-M-S+M)M zs!r4YpC9S-Mn_xw+EF?nTOuQGENV9RU~=-Tw2}Hz-BqdGi+g|(99M>BhV8~39M$KE zt?cjB*jJrpN@&{cJ<$MPHKE{r*i|#HQbo&=YbsWO>43TasdoJTQ|(k`jBMur6h!~^ ck)P^0yKi{D+}}}6;Xk%EBdiZuOv|KmHp<2zPst$28zd$_Li{7vT_a{Q<|9W4tjK@fC@HB@v7 zf})KeDEX+@;X8g|4+im#0DEQS{9`XgY-W_r)V!*v@~4ab(f>U&kU z^Ujn%YT>Szy>ZEF>XOCxsx{Y5LhKED_B|LYzODJPPRmnuVsrHf8w28H@1WYFd3R8Y}1bLx+dGV>HdZrdI}U*o1e$_&BZ%DZ{IuCk;Zh8vaIAv*hE^|H;Q;! z#r|lny9NAf?P(U}rhV1=W7c}RTxl}MbBQ>APoA(JH<(=~Elm};A*S-{kMB1+t5#07 zjrMQ8zVBS_aJ%|v+?RD$N7Pk_Rq~$)mFdw0!ATreIi&B^{jK+ssrKR@h3T$723@}R zZ|8*1HSXan8H+i<#nK?IwNKspmsk_?&ZZVEZSkhJ^ilNvJNMVW4QW6A_S&`A$JFLp@UFH){<&&CCrYbv^vYXXaRH*8i zt-~d5CxrQn)-w;CdV{arL~O!E>!lOK@X}7L9oG1wCg$J18h(xU-@eMcUXOg+zg}Hf zY8mAA+Rt{-o3Sxoc;xCSt=g;Ct__Zlzgb&T6H`fZ|KO!{8Tz3iTlXfPEO9pF442T; z(V-VIuL!nnzVBw~Dq`buC$DOW_Qs7Hrd#l$mexj|WB1>#oeBJGn}$RC=g<1*;}qTW z?_b3!eVh=GlG?t0)6Rjbr^vI-=FQB^6tQjEsgbHHw2^$rg|9bXpVrXUuKW1ZR>#!T zbVO`;c=*+;S6kw$y=J&`O`jzfzI|%jJn;SdjhGn5n7BA4zF5ATyv$765|{pUgq-g( zGYt*RJ|Uq%eZFmf4tmdN7*`b(=xX@QehInxXY~E9Pt|@&{5Qx8YajILmB!n_kWw2X|^+XPY93m3L` zdMy8Plk=J;2-n#!hrKRdv|RnOqM@PjyuhZBGfHC%GjnioFtx^R2CW1Uik=dehLbLp zYeQ5hFI~E{d+**26Z|;Bk`k$Po7uy&jPfXn`|>`tM~)mxxO;b~ukw=Vm2lCB&nK)C zx^L_}aMi5bbMVu%^IO6!mf6prKVO@seYfSQ?XkNYks;`nVGI+h`#{-HSyI$1P4A$kT&QkpRU^>a^!!AyE_$aNNvN&O3=yuWoYv8c|rK zS+iyhGcz-_Q7SJlFP*dFuj#>r1Lt}Cx0eJ%PKeE*cxCj5iPO@mB@ z@_x|j(T8`Wrl$wR@*5>5CsQ7Y6Ug|y73y1Kew zD?j@w9`qgJVvG~E*kopAmT>zvO=Ymf!ncq6H|~_)va&RBr*^|8Vy)Iv&u%+d=mzNi(j0_8^oVJNNeo$=xeoH$$ zYCXNSGb3Y*KSo|PHPt^jbgiA;_+eQY%gXPc>gUd#tGvi7B&6oyA>lnYT0`e=Z~Av} z48OL1Ghf7XUEjuKhmDQ}o|D~{So4gU7^boQVMjhU%x(NU=aJJvA@cP_5J(zMQZmPc=zntW3qpcV%kcxIy+lH zo_Yr=^ip@e_4=JVccRR>e)}LAk+=FHV8is>+;tW18Z1j4L&MIrMMr1f7qzv6gM$=% z_wN0*xX8Qq-J3U>*(OD_PtUy5wVw_xEtP(oD7zio+qle~H#{POe#efFRvv6DETQ&o zX*Dljs_>hucNaNs$0wb#vbu_U9JN`klc#hILtAj_k$7${E(!?=3Bdwil+=wo#2&pq zq|~Sa!` zDlwZpse=a(e)#aA@WYZSH@%jYmWW*oXU;1Ny&pp(BSCA{Z#sp=nIP@P?e6YAt+4t- z;mOmd*Q%=(s#gD8(z-3Swl-*U(9@?+HH}IG0s>xW=qm?qtU>uY=`LNqiB0BtQ`1q$ z?)$m9xrW0*sIb=WHi-!4YQ3mAt%4 zH76>(=N+Cls-B!!@@U#T#IIK`&a-##`s(G`Fp-GvELO-bCPscC7SzkPffadb^r!sw{otJ7ivCkj+}4~mNFlsaGm*FQQO zef@ytgr2$iCV+_FKd07sz0cR=i~amQMZGBQU1OuNzCNRKZ<)b}X~CVxVVRkHFYD?C z-^B9IJ1fT)=%;Twf9{;?*SELTMjktzEx+R&M1mF;ayM81na@Kp^?&+wKT7<-*ch*S z!QuaBnjt8#lxYnNbo{R8-IL zcVA!M7h?Fv)tnqbEQxEMKADnBIV~*>T_gBOIL|ou?%h;8JUnFkOc1peK{GU|d7Mw4 zr%PW2jiaL@)%x{AHP_Y~=Ub^(di1t=g>)1feH7ft)loW~LCVzi|Qjv*? ziE-ynEx?&HtdVFHZZ2Z(y*dXyy^e_qi=atiFwuh6W{<_}4hV8b?xI-T%a`J%bgZnb zl!{nOO5IEI6Ep;FAg#T#vvYgCwK|`mpnv-f50AtP>7c&7K3yQwwfMb!ihU-;hJlU*k5IzUi77_1G7#)^-Pk8i^@wQqfN zn9Bd?J?V#rCo)ZfPMkP#+Rjb`*h_QqwwMhq1t$jwM{G&YJx}9!EI3NV^_$thY<edqhPgDk_S~zy1bWR;T1RtvN6*s;G>Px%vH@ z#SR^Ol#21f7KXBZC=%`I$C6C;*5Pt)pm@YvQ&?J>@b=xi*L8IPFJ8Q`oB3SF$jG>x zD&)_~Z@r5b575>)%!COT-?pd>I*0*GoT|igp)!Ed#gz_T9T(Ch`gjN!Zt~T3T+h zAM|ejQg)oG4Lz1Gb*iT%l4yyy@a0|RJf13GkfSUmB~?&ZxcixDZei8Hz^T+znd6>! zyEh$3C@^wczdOy1Aw*@&1@|tTLxCN|P(xEw2?h9JR@MgMNl}s0!h+{iADy3{AAl1< zU_S-mJl7~DHuthLS{N8?`v>ab@BN-h0qSpQ_7{`R!_l%*vFVO;Hd z@UoB3`)B8EmnSS%UyLOA-C&dTJk^nDKoGbKFB=+$a!UFf++`OR7d4I^&3!8M1Q-zD zKYYJ!6VS;f)TMWsVM1nQ`&OK+tSE^W=ih$&b~g5nZmf)efWXUR3M*8bH%FSV-H`DZ ze>7K;+0$`a_Oy%SrnGDW$uE>g)JbhRV5d<3`udFKO<{Uf7hP7V+YVW$hML z)}BYpyx#TBf5R=7cUcb~a>WUrOp9UKzC8$i$jjTC``|$~5=q3yZZpg^l$kXVbj{*9r^80ka$`g#N4!?IILSOzym~`Do16SL&wBdrC?raZ)Ue z<`YFoQ7Fg|C4ogDQS}|W#0vON`r_>F<&~Aev9S{qnyQJ*=n^zWQaLTQ6xiH{P<~%p ziC(>Wl{5PFz|c^N`+V%3JE2$Btj{cLLj5MZ-iMVu^qB;f51UHLw8_w9lPAf-__zE| z?UQ0)AC-oTB`azXEU7ad)nFRH<|@aJ-|Q|ipLmnRJ-{JR6dUn;Go26 z7r)8Y9vf8FOF6rFc&z#=F22~Wr2V?NS^e^5x$Y8|Joi26rF$~R9R-9(T<{?+U0n^Y zqxa_9HnXP=^YQULv8oGI>tAD_YGbnpD<hHv9hYo= z&#n@u&Yleih67A0YpUT8vZxBrw{Ecd{4#`Zc)zf4Ugz}n&A81J39SKK* zNV+^rW0-Ax<>t*TXM2k2JUu;0CMVNZafid>Y=0FS_IVxF-*s_77P-s6jx$TIey$5E z^_*l$)4HuYBEx8OKaxYiP;>R`U6+=elTv4U%eLue=xapYxKTep(M4Xh;JVLh6Wn|D ztOZWYlQ8W^FCyBjA~F+-RNamk#ukW6NEl>nqT9G}U~-aY?LwQk8+;LP`pg+Mm+BSCoD)w2<>cf>uWgop zaO)O><+JC{6z6NIw!^Iw2eEwf_O1RiAqWi`R{05mbgVoTHyGI2k6v3x$4#6*eOd)-#Gcz)YC)UW zlF>1@60KcbdvQ!CFNrex6`vpFz*TA{M9 zL|})yikx#NE3ddXBRe}g)I{te($&xz{e2MQhveZ z%h#_;yBXXbiq;#Yh36ZsNev28zgFTMLcL+T&=H_NienHHA^tkbf6NdzHeY`^JtngPiPO_<3XNy82xY;;d)H;0b0IE@`KXaQHbPrKM z_o=>vb5s4*olo_mG{{zkFOoKdh=MqUOFY7|W>)a6Xw5OtHx8%S%H#U?+i4l(^^M0i z4wL70)lzH2jFWkNp*|R!mbSKzp5B^)I_krl+2s^Lte&|tle8v*5B!^Cn89^c_#=Jb zz(0;m%M8^38pz1Wig5b_Mb1CGFJ0OtDjIbpBHvIK<@Un|V}g`aHlJ-a=4XLORkbwE z9~);d@v7q7Fs+r9RZEGBg^*3X$zfnhqQc88P_$D91aUp&jo5gj-?q6b+=q@H-4riw zowHj^jDb6f8avdKIlSl=T7FiMT>pM6t;Tl=qSrQD5fyBJiYwR!ATC5zU%2z<*MC)c z|FOi{BuQGPqOP7&QBh$~Y^1Au6>BMn_ZLdmE`I*7lbobPY+zw(x)ah<*!AmF0%m25 z_4W0^;o)cVC($OYx(n?^L`7>hD=fEsU0dbYB_u5^{ru%iDuqA4c9kfSl27LS&`?@n zA}jD1<5E|y8ypHZ%qzVgl6<%Lz@>$=8`Iy$8u6HH&uT}+$+OMNlf zQ$kTO`YQV7O~T`=G(=t{oH{gM-6=_Em%4g-ZVTT|FmB)8RW5|LNl0LRSzn)ASXkIM z42cHhatCm|c!HEcaZk%11xUgBY;kOU4^DYQeS>5>2(gdw2kFA!Ynq#n8Gpq$0J`e{ z25;WI8)lGYSc6@ueq$$n-2Vds-QhZyG|m@@9k+OrD&@}jks z;p^A0a<#Y_MLfE-b7O58Xz}g(Q&qo(C>{V9rq1C%t?%DIv~IXTV}I`1JthHTMZylK zLPZ5axmp;LAU7fIyX@6n>b8qb!S@~jy_Tq`=)CjK=U3KH`3G+1IQr+$AANK4qsNlu zQx8Y;&=WFlpRYgp1|s*mrsfJ%wd;jH`~8xLmRz&)>xC#2TM12V?QN|Plpf<#^-WAP zRaE{hvnwj@`S8a`U;ieEgvVHG0K1%*B09yLG@OID&yss=d{^ix2S>*vILD&6=H}+T zpq66d;*YR6Kz&c2-c9iUXfm_HOjX3}*|}8Rr7EA_)P&FCaJ-6&zMh`4&(hpOQhgJ= z@N3$Vil?+d@a@ zkd2Ma<=rCn#{BErB$Fg~6cjjsXk0x#bLVgW59;&cbPmL02bU}mV@P%^v?aV zvaCO+`WtYgW1U$cHd`V{wG$ks~^gbrI)w&+un?eOPhHewe8T+nYZGCf^@`_i$Bgl zl(G~(i~X)aQKhf4gSzn|m&{rj3m0a%ZOzsw~8DckbD`g^CC)k|vP zd7|uv>knoNUc69B9X7f3?AZZg007a$*Bm$t0w3}G(o|&-q&%v%YajajUMPy2?5|cJ z2B5mJ^a@#r=S#^Y@HwYfE%Sxu=Zl_scP9We`+87N*HY7PW4x&6H)E}P(mJV5UxtS} zSneO65gN;yimAFI54bcsF){Szb@Yd)wvnv`pk~lj)~emu83Nb|`kI0d(`;7Wc5R^x zo%PKdT7bDy-xZmrB!#@f+>z#_HU2k`8I)v&?mc#2d`XBOhtegTz?Un>q2QYx^XHvZ z{{w)~4`m+wk90F`va_*8OmyX0<66OkIX#apu-;#0y|~8V!-t^GJJNNfdyUL?^gIqd zagwp*G{9S^gkvW`$S;1`nr)m<36bhUu@ftlNYb_fYyQ8`7QF8jctgZ<*fwx`$bPFB3Tmo^ks!AS`0Zm>8 z6yK=(_t_~p3G&xS5)rdtk8=3pkFl}waVUdz4GqyZZfpus;hz2Zb1!!?sxS%jiAPyk zM}&lgP`Fik%REwS8spvraU1lJ+tkod4G<_51n0Q3v(Qf`+wgotZwWP(M@!O|aZ1l& zP>oLtJfeZ7t!`+@1QgWrs7sFQ+FQ47b^rDu|HR_sjEqCT=b)UH4h|+GV!9cOsCC=! zU!)Y4*%?x2mAXj}Ru(SCD9nTK@bKg4!A*&>U5nWUv6GUIN=unLIyxY7uV2+Y9iGoK zj?zu8I_#Cq!ipQklm4X8PsiH%W$Nc-kI}A0Xz__6<=Q@s2O}&DyRt;A@|jVjnEptL zi8*w7vRa)z`&OL-1zk*ZJO1~7wR`m?z~bhcMAlR!MIU#I_^VeAI(_FryYIOWCH+3YxC*psPbOx_;#f1yso(to>8Ct&bl+KF-U5 z+tdJK<&?dBNWg~epQrp*Wvf;edeo|o3=G!7SNqW2O;X}tjTV2dLLoVp`tgEER^kdh ztkCs-tH1m6t?FpeE=e*+O-t+0DRb9k#HDp6@7+iv67i~`A^rVuM{oL4obbMVoF`A7BwZ2! z17Ms4k+;e5@$sz%5WV(bDSCrJjd860TCbfXpQyr3Pr-?H5&Ls1@v)~T%Rn9mNwU1p zQVSN<^+J4TD-`0`*6xDDmG>a;TL`po>!*z+ydHme*j5ESj=on}d_8;)T=vCuIv9k> zCG)cpk~!a9ubR+nDg6Gn|1T+(u@&8WwC$L}wm^FNmFZBBu4a)@v1ke*p(1BxG z^UTWCh*w=*KR5R@0Sz8OrE_X!*VEM%XVL1&_#rj(tIIvnv1~azC+F@?t-DW;-H{V^ zNY>6`)#_Q6bb)D0Nl7UJc2QbhzF|yNRaFGM`+g5vHWw%7z-Bkuufz5|CXMYGdX98@ z(3BMu?%d%UPRA~U@}3~$k=a_%)YO!)-*yv0{dCB#TdM!^8sgWFq}A*gdGx1*goIOA zKi4Nq#;B0oC3bx;0<(*zLHu&T+OgAi9yzL1^jtVU|d_^yz2N*Z=Kn6n!;y8kesu zyKMHOCN4Ji5ML~9TQ!BEhewf!$EPe@0g4J{g%fSiac%<7>gnlOTFu96BOS1rLtf=C zgK0lDE%xQTgO`e%cxUiQpU#{ecdKefO z3?iREm}{9O;9a?u;A5a=O-~KmzKM;ERa(L#DqNy!?`-h1o=-WNsNl1tpKbpT zT+h5?$KWx)rLFL-LV+$jdam&ND{vMVRC(}SKBIh@)TFTwPl1CdnMAT5ylzpLr~6h} z*1mOjMEpZ;jdlqgV%jg7cAsx{p@FO(7!Vn4*uumVh#HiP(ns3BaC3!iJ=PgN%U9PikG{)D`ZwC}PsR5fxj%3YkLA`2iH z3tGE@sl6;y#(QoblaOgJNjwWK@Rn)EzFniH!_iC9;ef=7! zeOHoIDu zD#b=JuJ95)({%5Ii>%>2$Hc@$#E62xrPg?fp6^5#n?a(5Q(oRY=SOmHcr*xt z93|lo6O&rlcHy)K4>-BG-@JK~{I@mrY}&sJc?~idf(@5~-k^)}(z*njlv*)o&M5J~ z`9QTu_MFyg+*-*p4$|)<$e&J~14JKh&)7=w02UfIx6EJu9O+mImctyURJ8D2w259g z96M}nW%UZa7?xRvI1P|jGpnhst}esa_;@SemC2+1nx{^2QgCkH9xtQNUucgve0F}M z*j|?O3DLCnc`SH6`-9IFdW7D$g@F32miW8O=eH*}H)-ZmJOI#39p>J(i$?L<1aM(r^k^{`{WOY-~3gaq{`I zo4X)CKcj=fesOjfWoqx6#>TC!hB+px#OUmBBi;8ltSEa_4^4aEjP#Oz-@B0hxgKR) zGH);5q~YXi;DI8qS+8vjo#52K0H5~jb(?ld`;#up&ubg_jdEW?KqAo= zQ>9Wyc6RoUAJ_#H#N7ORPhp~st?dw&!iUOBQYc3;_a)#*uw&1P-QI}Rz1?@d+Jqx? z@$9yecdS|JCr|cx$Db&1W&_kARgRqp&QTGrW37829jNcqbLuo~P#|I_)DvZl?ydQ= zGUaCt*9(ENmk5p_+hHCyo7D{PJUBHae6RmMoyTiyvObkx*o@X$i<0M z`d&+q*tj_Ok!Hhw?^foii8bpswv-h>Ly~-HF?v2EaGt8;23)^1%;R7?mA!Oe5 z+vMbX)TOS4N9`;P)iQT^h%lgj^eBaOz#b}%sLj^qf`<@nb-(~zmlh8t{pV-|qSPZxL*@IuFC zMrewl?p?5$tg^5u%lzFQGc0UYMg`gA?Y#qfyep{5zd%F6o~4%PGp#mCmk?0=*etCnYvT%LWsSL4W$ zT2$0&gNVwEs1BjB!N2Qj>I7+1-)G#x&nMF{MH_rx*|*df|;MNE}5@9|?rbcF}VY9b9dh+Re&@11OHZV2yK?k+@rFIXkn z`zJDQ+Q#Hz{P|fugtI4uy`Y+#IOM~j)zMIxB>qS?Yz@r6xb2^v*xu@qcX!o6*9u(+ zl^~?#b)^1YUi?vr{M(>MB&_8&{Cm>r-aBA+dg7eB`);J$mIkhEw)?ZZD31Gpyu|jn z4VyP_UzZ>yCYB7!drONa1)umHq?3jio0y1BN=oYf-QF?_$&<<-**UxS$*P6Omzf|% z0@bvGC9ex^im|%cs{Rg*ij1McxR{umSy}v*KbmCS2cA=y;H)Bc>`&|DKR_mmX1CJQ zzjv6_n#sJ56ew^SZ>9O%tXF;YpCx{hSQ9rPp)CITMbh6<^zimP3k6C=D3s{{_N~~5 z_UIr~{$-w%nxsMe?``kuzKbJlxE@^}q|?UZ-1H_YQX^LZsBRexq+$6-nF<+|`|9WX zc>H)Dd=KvZ`}c>2gwVHwXYf_9ci|Ih>F9EvHuaR5H9)5d3JQAS1Cwb9DdgZ_J5t8_ z@QI9R{i}UG(F-LDOZWzkjxW2Xv(wNkRjv0&a&Z+)ib0LIlvKQ~uC96Gp{#8+?#OfQ zj()vw*RE^q&>STeqZ@}~qN9~zfw;p4xb^z9U|HqY`^IQwV_-1u6P<#HZDpLl4JZ2C z`SU4{9zBw@w}luL6BTs`n%g^bs3zNbOWjgl&vQq=ehliM{pN`BUUrW+rO!P2ZZ-Hp zG6SLdR`mEsv2z#Q+6h=osp1*>nh1vT6O};rR12^L3~bku8lb=&fKi1qL}O#2dex48^nM0QtER!D_B=u zua+*&kEgcF&T2>ByO%9~bd0RNXWlZ$R$~i9PF1g(|GI?gfSq~Pa7T%IVl_?QoM-RO z%)+s_-P{sFsgO~xpdN7v3r9MB-*d9~Yz=@E1VlR>-v1Kf>oBM zJDIKGMgy<4U&1LCcJ@u1H*bbzN?KoIrvNqoL-dQa4RUdWij8TJH3+s&4@D{zj~Bzu zjileDX6GKa&B=Z6#ae{0l(?f#A;0jB#lQNYSYvZ@1Ns)3D%;2`LSVPnBkeh{u@7=i z0%HE?GcDLz?qjWMCpvSKq4s2PY!!UJ>5m-_=+1*}Ih7dVKtjC+0qAftg9(iR0|~W- z_H82QfnazfU4tD|2j|E9u6Y>TmpUvCSAP8Ze2!%j+$VT^Ez(73@vR%-@depS1+x?vvwnbcu54QsOQI7J2`0+ zkDoj_&btEq%*epdn(g88;mH*-h`te)0t_LqAm8xzc61onR~T|9BX&eHbO$zWRdK^h zjzwvk>}Rz!#fwgT*r8AkPK~xaBy&owVSfjG2kM^gMW_I;RCp>Fn%^%7F1lBid-d-@ zntNvygkgI*gVdZSIBJ$sfQYHDggmT#GqWCC1Y!(k3W!=)2~lo^D=`Kin!t4~z5v9S>? zoa>$lsStp^w3j!*?!R~7eA??DdJeiKCMK0^r&#z?kp52P%_3<8)L#=lL$nSqpfcze zIp+_efV_J9mXXr*>{$U=9T}azuZGW&X)ciHeSCZlh36apb?7Hkj%FsyM$+x`OOr-W zbI5I0@9sz_nZPWmsH~hYO)n~v@ZWA7UtA~p{@APS zkb)XSaCf+ksrH3{H5ur!WaABuh)4w!K903ZL%d5;u&__uv15lg0OC@E!ki_D4IhMuWzuOSw1A`xn!-axxc1QMt5ZQWhvwABoM)MrKrvbr}${+c}F~I$p zd-t?JnYqxmC>7xf>ffPwsowKoZfaH%cn z51Fn?MZnfFQTSBZn`XlGH%|hlje!~{<=B#sxm(lsC z6z#h+;^cYSd(%5#MVB=&TIV%7^Z3i7;r-+DmQ^yU*5Mz_YNZy{#q=MB7be~|-5=Q*9b3q!C> zRgoW5TFjWe?1cJK=su>KDtQX~8bmHnDuIC>QMNGRxT2zBN{`*+x8|Pc&v(H1U?Jh= zIp;jvHGv49ax{;&Lx;6ehmXTMxs3B#@OSj-{;kTxr8qy;Zy{|N^goiv1~P}Bs_KqC zI-)YSym;RG_hgAZ27Q$7{3DBeaV;6&gTIMFyo>7>@c_EkK0#JyW(~p)OAu%L^{W~X z;)^e}wAj#mYun(*v_P6OSdxOl8vDl3t?omNm^W}O1t(Z~s!jB*Ths&{i?{~w3bY1~ zbq&Z(ZzW6s=ykm0ASGHN0jV%rf+Yo_+ zw!b7)Ro?wjNSz)Dwzt11A^@;_$Vbw^oAt zl_QsNPD^y5Y^`1nb74(O%NB$YYt=b?sDRxFMI=@LF)_su0txf%hbI(*Jqa+Zq@GZ=k0($2$Pv9~@!!$ii1z#YjCvlMsL?GLZw+G=*nC?n zZMKXtnp(kY`a#Wb@!5}*wzjs*3q3ARii_*}SN~j)yR?w4-PqdK$Bq_GIc+6Vxb$mj z=|x@LT3GoxzFKxeZf_3u@A&!EsrRT3Ir@c-%gGc*&&Wu1TWcNS->GYakW!`g4ZZ&q zV1q8V9CScQxUX#AnP?!C@;8eHRM)<~wLxVM#VN(EN(5xuw41;zB}nPR&h-FRJ}?Z! z>hg#JCh$m=87ZUz2%k=OR>4P<5ww&o96(lj8VmZ@uV00)MIS~01nks0se=i+e?+hB8YQe}@AW zl4*^zPEL+Ko>(h@+0XkCW3$!XG5dtK;kqPydiaWteeb|+ye%w-x|yMdfI_4Qo`3qZ z6Pr-UL_>ob-r(+KCnu)}6r^3eyfm_&-$*7O&`Y#Cf`4cwg@~7 zx%mCQ+qxk9cVwD&ib?n2)Yr=8qnZCL9?eb?R@>10lh~%LpQaF;Bj?@tVxuxkY8fvY zE$2Dx$awnwE17l$0>WTK&%imTNxy(H2?DvAU-MlSu)RYu5+KF$&Af`+Mf0}A7u0AG z5s~NMoUyIViLybfV4&2SHs#JI{`%$hC^dD^@6U*z$#R07T~aVLMk>f*xI6AW)dw!> z4kuWBD@vhbyJ^1AVPt_J6`w~j3;3T7Oqtp^kx zMO7f9!Dy&T4a~RjGOov>_X`|0%|!wR2To(XfE9i)|dmRLeuyJR6eW`o^IJj6!L6!O2M2VQ$2IsGhFOYbIHDDLu)TZ*D>Vo-|kw z=G1P;{~B0xN5M~C`<`?ZQsoBS92j$9t=ET61}(Hyz5k^L9-TGa~ODxL z7PpjCNnNKOmWM`at6Dt2 zprF(HmA9{7XIvPUa+)V8th%!vJw3W$fLmx!nUA=X!n=&2IOhpL9lsodVnH2ArxRUH z9_-dGr$h|2Qujn@=(B$@Gb59B*s-T| zW>dj`jh!;Av*_~t@4Qyho(-MdAHw-=1{%^jTR6*m$C=~ZyJP3aOC`F?(kAkX-W2b7 zlO{M(meXXN?Nl^&+Xt#IITWg`tsUl+0^f@4yr?DU7$Z$=*8>7bn~Lo#zdX!{0Trty9*N3kso|Kd{+~iV*gPE~yG9_d2y$V~2+Q}~Wl_Ep45|xjI zHfALY7sKsCirMd80I{a>$27wGacg0|GolDbT2K?D5a*CL^t4%i7vVlVa42==qQc6Y zUh0f}y4LO4?g;H?eyhHeidY`+Od`RWC?0?^=h$(Ke^uA>_|)xWrZ?Zk;?b*X(`M+= zd*>f954nWzcjYDXGS8ncrox6Kj^FXqVZ#(WH8u5fw70?U--RA+-?oiZR0(oKYIryR zcctrlP+Z!0+JWl6lgU1hqdBxY-5g8ii=~V2m~;uob`@t%bn5<{(>R4$rOP%S>I-wF zT#&Q&T^!!N4EcRt@;>GvkcWJR`QJmSZWe8=t>W_XXWiY!Q9t4YP9(?NPe`Cfi6InS zT}61b?>y?9y!~HM2JdT)@VB`T#K)q^Ja09OG%`j`sP|rhI`|oSMMT^xERps*$IA~O zC4nF~rqQx=*FUN64zjWUo&HDS*wKb9t4uhv{b}YrV%n4$`h3fmE(SMXt#PfOMmm{y z<(M@K8g$VO&w#LL&U3|Tl2bm($=rieM%6!NFGAC^1*=yF#(~&AVS2yvN=+d$0)8tK z7MO{o0I0(leN9`Np4W8J|DH$~H?_rRJy76PJT3vIA$`RC;C2rLHHha>qhnel*<{Iq zW(=a7>M3^mP-q{mIZ=*eHU^rmVvLB1+(+Q*B9NWH=a1MwgQ!x|*~tVve+Ysh{M5BL z>A#&rbb$)wu*mcqIjs+#3VY=F`}g$L_2D{89XYQ5Bfh+ag{3=reiGOhf%Gk4{CKd3 zDlp_k?-}b!Wv+jhkS=-MJS1+`F#hd`^?bJT3hFaCig;Cp`wAey}kYX{RT4bj>%GjIC@`> z1~Lk4f}|9allBv~X?O+%l|RN8_eo19IQLg+lkRzliV`uJ5-HEkO;T5~?NB^G`zPDW z7+8S##o5zPjx&CqP(sZ|n33}M)b-C8WCBjnD5-Dk{ya=_CUsQk(DDlS#B+R&HS(B(R{y2dXt`zm#m3X|iO zOWeU`8LXM39m!G2g`bb~W~Gif+1qRMHstJylU%kF&WSS#n>&|daO7sN2CJ1L6@5r{ zLEgxh3OwTGOw|p6Td&SBA61Qtn1R~?BxEvh(t+(6= znIArc)80G*x7Q zLV{mm7W^fI2Ylj7r1r@)#C`?Xrebiz636g}j#oHb8>nJ$FbOH;=I$;aDU4u|6{5ND z1#TrIJieR`q&N{?f@iHzaAIKe{l_ODQz3>~9Xl>SZRuc2Ln?+IEau|$z!fn(SmYw5 zBBTvmFEmZfEW;dknH!8w?SuyE6kpMmoHvrWuL{ijJae^vACQ&ZK+w?Aw(jVI)=C!d zoI($e!t+i=9;zdvyLKs?lsF4wD(oDT;4u(3j50nk?GX*k_;Wp@Z|B#dqN0w)a_DZO z$YP7L&>={G$L6%`_or2OTRQ4vkOM1gKEwF(@RNBgdPGe1&zd6$ zJw4kfybEe85Wilo-=(GU?FX}$amC&|OoK^*;B$`g-YtN`4vtfFtdg7<7zXzt*exbl znV8l+_;S})&T%m~G*k&Abx0TZ8(H`mEdC^8+kUHm$at4YPHqvd*o6!YS);U-PW!<9gAHxLKOl%?$9-0;|8be@e0x*q+` zo#ANmW0P_w#>S@rhh=Kv!v~=ak$DMnIuvc^DpuDJW-*V~V;LMm_?Y07liNwOAn+un zFoEQY=HBdEfUp!G35xK-af{48OCNJ_&9kW9L?CLI@xBaAgnaxDy5}!k+kwxYufk;J z77=-(+o-OS_YR48YdlQEyQ_ZNqL6B3V`Ezr#IHQp-`aP?X)xRI0)%?Ywrv40?x94o zdHw9YFkg`4n3XKg04o(^RN z!R?yo&k2x@<5?Y~iF@>BKu{3r2oevnd%hc5B*FgkyFivXw2a~V{mGj)N~}zO z2VJaK8qdOGY(&T@Tl766uVcSn5AWKuNA)9rOT&NN4`>C`poxdFI;^0hwKx<>BU9Gr zHAGi=cB0#1><2hT9m6UNv{NdEREkq@qRRlLlU>WdA-;(*=gBcVQDq%rQ!#7TQ!MDe zI`P_AuRf9^5&!`64%MxjGkwo3?pvxU!l&yt9K7(|G^fZ-wd#m!_p^dYIQ0RTQyBa` zRowviE^_+S7P8U__mmamWhb-S7ndROUa4MPnKA~K0@Dyh$w=E;TR3it7$+1M$O|jy zSIaKXR;O0}shFLe#q{_!EKA;6up=bh9-p@kh5|dbQ}?`wM*#Rg_U98!)+XAMIny7_ z3hHo*-)EoLAI>VZi6tWKWmtXfix=dOAD*@IqpRDO z3e72SGL4$jjq=R3`@PNn!xJu&)_wW%Jxy6vg&t0YKYkQqKh5AumtOiQL?#Wu zA<4uYd3SyBuqs>UhR`Lo=@yY%{R8V~=PWZJzH&kzL3z{(+-CONENVlvs>(C!%EAbx z%a`Q{xu07($=nT~O)?nZ8<7haE?~HWU#h#xb&wKsU{~Qs?Hdwz{$%{ja}t{0OFVkx z2_F3bz02y$t0?0_yQl&#EXll*vvEba% zrLo0~5Xs!pze>E_?}PT}rWoWSK@VD`(YNx>(g($hgMfZ< zB=N#-K|$@2TQ?9*pdmyhBx2#cnf^iKQY_sE<8!y+;t)U_mM^FdT%3J0>y4N)uB|4@ zOYE30o=Q@e+r=M=eUG4IJcK-}-brwQy4SA{!yVz_H_YBQ&ya{B6$XVwtQrp^k%=i(yemo&h<1ktX!xo0Qxsx^TS*ZL#8{R-3fdyuOlRRT1n2x1Eq zpT(t#JP)BByHBP0v-k0svS4&>ahE>RGtKt}A@|YKN1=rC{lMc>s>B=_@LUhQG%cNa zteki>mf+x5kZtM^8hBPb4g5yFj!v1Zn{gVN`Zg2!P@%(6^uq(j1GWI?H@_! z=`Q8&PnDZop4)R~*uFX)K?TE%`8J1woUDSx`G+};`y(-<8IL9qR#{ouR5Xi6+@XE# zr{HwzE~Mw+NYX8_h79oe^Ji{?#1+V&zIHS*Z=cXgib+V=ha7qPvzBMMQ10SdT3SZ# z-!ROIg?q`6xBrrfuWuEyIoc3hGQY?I9K68=-2;L4qbn>?Mpj{7-oqH)z=M3gJd+oO zf`tctxd$SAsiCXedR~x&B|;7JUtDNQ-XH6?nRPbyGz~jdb2}87!1R2Rt>=WTTSB%% zkEWsM#sctpzqmq-ABv+A+-1AG{|ewDiIhJBI#aez@tU9~~nDzIJ^T2M_|A`DmMD2^4qM zF`4hVNGh$HtLwhb#+&1T;2xHEyxyCBxbfK(2@YmXLs)5}9yd34W;X55 zuiA+7Krb;qfUiq5y_YRx12cjdFEP;28|0zBJjAmrK(=i~gB=uAIo_QZ6e%hwAZx`5 z`(ze`>P4^(`nn?@2SSf5P#XGij~7Xn^Z)MC0`bb*eEAK#|-A_bLCAX1)KoJ0x46?#2(k?fUg80B!;*2W$HP@g;U+YKU|XPEdcp%|Nen z5ip+2L=o%?P5irdt-(>LVs<2~R%8!%@@(nl#e&w?8Y*Ns9~&D$G+&y$=X{YMYSwtN zkxcFX>Fdqoxm>&U|4W)_(4e_w*Dg|MPN-xkDH$t@XfQNrvNL3-k|Eknlm?O_LlRLb zG)MzGqR_N8NYbQ8qSEhu+WUU)`+0uP^Zny~z3v@8*XO#f^IYdz$2yKyTWBdAc`8B*AaVD;>0cismjJm9h)%Pu!tHC~0a zJxbKhdFip1mp>JUd;R(FVIQ9HHDp%v<)d9+RabW~H8oY->Md66b?)nbuHygW-x6~4 z{S1^?gJ#QM8h4<sC86eqXgL`y^4$<2=ycYqbYg$fysN(bn*86RjS`cs^nM#blo!rtn;-_Y$G|R z+W@Ieb21I%V|laYf$d9AFG_qDrl>M}__O+0LWN_vxu-xo*uQyp)%!f+4iIC!PP{&% zGFhqmD6yc|;}LB<%0tD!o;-7Aw|A`9Yfz(!?r$uEykl&V6oo4xYg5jE7v^&%C$q_= zGB2!9I~tZs8^s;`S(6frTkrwZ6-oGMU{_&+>aLea)xYxE*-zzl1bMMN+*7}MMO_X_jUVl>-B{W~K2DQH8u?#lJ zn3pgmyYW>&>|*x69sG>Sdm@6IU_-9ruhO%~dF)q?(Lu?+Z7Xftc$SCGxSXjAtnkRD7to#uvF{&tLBKCmbdVN6*N8Qz;!{Q5m8v+!U%f?qrQO4FYK#; zv`9bHSFwc6R|UjFuaP@;lcR6(;>Etxwzb9D&#%qkgy|jypWDE)$D8~F92RM9 zRm7L~EDUu>`04QG*|RHpT{TT++JmTTnDmKdTf|g79ATAMB9>zCv6J^*#}SSAfxJcW zJW_ngm&_b%QdP*Ryb1WeYHh^_PBO`GO1SK}WQmL~+e_Z!MWhO+L(2-V>DH^)O^u=K zpPbMOPR1=yr(|9Dp@Rogc8aB!TwGk-JJwx^=gALaw9Yu?m1i~$h|N^<7b{>OK`|E1 z+7ivr_i2)6w0we37Yhti6!msJ9yWRMVF&S{KKs#Tfk`UrnSM&`&EhPPp&I~fynOIy z%c5nP+W%Zy$0>YWVawW5#jcO+Tl>#^Vu8Pkl{K6kX-%PJVUA^tIqIuFa@q8Ib+K=C z3@_ax4yvtCe1fNmi*>db_^PBvqjIpF*an*X$7W7{d5dVRg2171gGleXynB+-o#(S= z&6>H*{RRyx)F@fP9^^ayePc~g9ECKgmjxxW%p9)yb#T5H+ljJ0^vtS~gr0Uj^;U|> zin*9A0J%Zp1pd~; zdn87{{H9Q4r`aTp{!a0}G`utwW=hPDxYg^CA)tdeW**N1-;tFK%eL~TL2Ko$D6>-5 z)VD4?So({4)@Spe5o`Ah+tx#(QFbd@(RWfA%$w*=n6QvhHZ0Bmn|nzs5p( zinGQ11vB%>_5|Mf`Atc%!IE(Eo`+cwHAcRDJy#*gIvAw)>|$1*5mdig2Up)AOEb!?kq^HHw$wQl1*r~`3v`?+l-`XeBH6yEWEa>+mG5(TemRJ zxH1ZHmQ_{dT(02+<448aV7!KgXl>YezaOV)+$FF*2zBq+`ViV5MELyg)4uViDdP7V zG<-_!s?T>x++kSJfp~5I_+~v;4@Nvh@dR| zlwn=!aYMd#E3nI(gk;zBWo2~55CEOi8%N?G^YQDK<-&JN&b$M;^yzcoPEy8;oXR_P z8JWvy4j|jA&11(o-xX(`kTG(&z5TxHGyQ?}&+nht&{_XVUX*fr*@vthCEz9YM$;Qk12cD*ae?Y^~>M4^1swM=eH4I zdKnU45_GBCmMeU=WVLFz{SbU<2p(s;*7u*RR8nPc{O(;;nZu)~X|fLZi zauSqr$R70QzJ0wbLtIkODU4JpJkX6u9Je?1>{*VSTP=aOsP0|Zj`l5wjeZ!sz&5@I zaybU-_1CRSt?iw7NO1d~WcwVR)k&v;6FzPAMIuPIZr$d$PZ;EI5uikVfL0H<>NKL_ zz7*O*QU`kONbvpsF{jHy*Vh@}p$S8Hm`VXNKSYbFy)E%#DlNMO@_d38a1CGk7&-S1 z-DEP&abG+wf99mo=Y-lX6KocM{n6EulAfCz^X=!0zj$=UVLFPclQ(n=*$bBqbZN2{Z7B=VWrX z3Jc3R*t9gi$j`|4Wdx54FRC_@P)9-&&rIswU_4lvzyBrJOqLV$wEg8jkOUG8<)BaA zYjoHL@pa7a&>hiOcHU_y`|Oih{II9860utFtjX`G8Z^mwxGzUIXCzm5J-d{7e>hm$ zhZXDrKdp$pBs3A6FyXpB7w0^X*>!a1>%TRfg7e9TZzC(9tgmtuOov}VSyR?l7z#-o zm^$|sP}>Aef|#&am;kW*E^MgYTWjO$s!Evj!{zh&t|`rPt!>~5;K?quu?yeWE#BPR zIE+Iwt*y|05XOX{G`qQJg?MAgwW`1EK5`@k7&V6m7c1mrUEOpZ6TH>-w8#WU7`}k? z@oVE*NT7ajFCij5i#s~!Ut9p0Bx^YdscckjU=Cq<3B16sv?MdiF9)7b%%UiDT(-N)+Zor|7>e$ z=r6&UtWiCBE;%__+KmZc>fORMC@^G{fFn1L_)c(a$OB%EftuXs3&~?gX#pg+f(!ru z?n*>M`K67fG|NV*h8atNhR4n9*h*PaR}3N|s!Pw;m*eUJ$aAC3*&gn?CiKwb#(bx3 z-D)b>?hq|48-0B|fvy)7r92o*>UW(R=FW!T9;~kqT5%nSh*Q7d0*a9P9q9kl?vzo2 zgrZdeG_n9Lwf)LmYyw|)YuFl4jRg8Sod~BTCRY7oNo9)@tVT4V#n{nCO{#{3kn#n- zW;#jeZ2-p@u=-k1h;AoW(d+r3k>vJPCns&Cd$UGzQc_aEQ+$GiY0I%9XW?{C6LaCk z4e{4=Tye1SpkL0a{{xx9U|0|IK(`z|Y@5;)%>i?32q!El6Ll@!^C*sn^_+Deaq-&SI^iT9zH+YUfIy_D_u~E;uQK> zlu<&8?Uwne?Ey8_U+K*ddfsiayo0zUROfze9@Gcwnj+$&&}4B6It&hSu=$){3Fk2)Z~Nwp7>S^j)BI`I=4Zk>M2NEf{L|#mL*s(C5Am;t-i>o>5Y3R|9ltWLi|$upnu&H{Ik>^S zd-puQzHW0f-_g|&$!ig*M1S2)y$_FHRqQ#EY@J239Y62U@BVN6+wq>FLd4HjyLQdh zY5XNpEXz46Z?1g$Jow>%0^vUOCG!MQM(;gl{eiuLb`Nh4)i<}XaGI>diPh=y&*sVJR{ymF59H799(JeitucPQ zAuaFXPwgda>$YJm#LJT-b<1G@#U3nc2o6eWY9>|H1B3$scYg*N_JvEAaxk>RW#S5_ z?pov=@_om)rxB%<trOebJ<1 zlP>0puOFq4AQKDbk6TGtRLjr_Maw~@EVVe;Gr|SzbeY)MYdSqi zJ4S5Y!-ERVSZ%!>ihl-n9dRXZye^g3Y28aL37)kCxh}$(MW@%!HZi%&<(vln9ItWL zGgb7FW({ayx%SrD;C!&5_3us1k)IuJ=jDm6svuLP_8teR;EZACL_E#}YPqn+GyH(+ zg$cWUG5RA4V|77IayshcPkEE7VfkvXor22RZL{>{@Acv+IG{m$y|PC1fDogp$%plc zmGayz{iv(e{Wyw*$2xv79$=#>$R-rG=k<)Gj#{G0FSORy?Q$0T48^UgJz_Ub-nND6>*FM4EX&1@nrS4A8p$}PzYRe{G7z>z!0`Bi151D$-L&5?CAMG4>ERi)FV z%&g5DL5H{KTmIe$`wk>b=joDJY@vOqyZ#Ay`x2Oq{9KqeUU^})%?nQhz*s<4Lt<09 z$!0>}>n9mwNXwIZ)y;d@i2U~^(drY3@iX3@*r|d5G|$enjTp6oTZ4#Rgty@hDoJl_ zw38tUE8!_fhobCTW$Nq5Oi*=Wo+?8RN-|tFFL)eDT3G=jNv(f_$)e5sHMk2m`S1g+IS{!K5J=t;jQy+#EQ0!Wo(DFTuvu zj6|R>ee&dw-!Rz7uMb{0NKgZ~G91=Q#gmb7@7CFd@igh*3gz#IgB6Fu!|xxg-|mnw zEHYEZ$6dw6G--TQvT|K_3IS3NAs#~)YVCg#UN#JOi32qS=__4ps}&=mSEDVy-Z7#s zzWUthj+?)KYR6{0kRCrQa$`nP;bTL87ac*-6LU+*xz*frhkF&gq%7--7hs)7`VM2J z43Nny^zI#37ap5eaMUJ=2sIH3Ll6$FRi|&_xWN@MG%<;I4$^1&<I|SjE8^v_7}`cxVOTGBtLx*i?P2jcI6Dsn%~TU3B4>|qvWi{rcy2Y zM_%*FE6-uG{44cL=w^sOc`G=8@;*kNEYhyVWJdV1km^{ys_l;_;+yerX~0Ze`=a&H z_&kjyxGLJ2_-6_JI;`0?jKwfHs=KIqX?F+=RFfj>rNJQ7bBkB32$qp;D=1-MO_|&= zC4L_SSo++o0BAUlEM1$W#pFp?I9wMvHk9HVeDp{^3*8IqfjlKTDQ#cNcWK{V)J}W$ z?-vbC0k;=geRC>#0j@!xqKzcZNMz;LInR^NP7q1$_is;s8VW1qIY-))_E9V)UN3xt ze+`;5;g5$Isl$^CYYXd-$0b0Gmz8oXyM%6xP+yVdUApdD8ZMuJ1|okKn?euY%(8CX zyNg${fzd$XrT8P~?nARttW)BHrdzo-72R_jg{*G`1qbKw<*BG>L3;I&dkkUh8r2*T zRG+2`2cYenbAbsnd^}n|-bb$2+BePZsonV1Pli)moD@VRqycSw1(vU@Oq*#i%l5Ri zn*t=CkXOlF*TQVc=aJ@r7oFnv(o9@}{723|GgX?wVK@5EoSf9op|lHn>=yt6fY!`+|qAK788R#!%p|zR{QGd~~ z!r>}Y;S~Hr%3Vu~W!VGj!`8l#YOS1`p`MONvPs_y#4*$92+vOSx!FSvXt+I%jEs;y zg}i%|K1)!xo<6l-(1FE00uK^p*JTo9v6b2gBmfV3%7K|gtPe_gmPz9*#fWnS}&G}KctaSFmcK|~JNT~}Y- zIsCk$LKapVJ||Y5BO^Eb2cfIaY8?KFzk(<8z#EZNblrK(zopl?p3$UlL}!BqrE$N7 zr56|(7+5{_s(Syvlk^pBl6#Yi2;E?6^E&@!N23aHM{c>BlT!eqf)Pek z!LO1zgY(oY`)av${@*xR1<8-a<0fygSz(qo!Be=gT+T%NFUvZn5;N*ipO$pG{)5}* zZ~fA2MvCl!B0%VjVh-4u+f5iZuFb~_z1$W&ZZ~2?qWP5LaqBHv-2K2Ke0Ge#Uy`yG zFjrgPA`tf=2~8>c-ibM0(wP=Uly~ji!a8AYNMZ@i8|%GJowggt6lXYW3w*|bRN3)f zRlGsbY^BI|8DCG(+*ZxdkNdU9`(+L99`3U}q!snr=r{MIjnp;UF^m=8O{7tn>}e&F zjLKfA$iEty=@&Z#ysyAxsLS6Rt#niQd#-D-DdA;A3#qQwUzF}F(W`h*IGLV)z1!JS zeVNK3VPkWgmnKMPto##WSZJMz>ffG}`6}Md&))`PQ5074vk-vc0mmi|bs$pYki6K& zqz}JXRkN>ZJn9PipMq;}%J%%}2WeA&eqTS9eI$kE%S2|YMWsDY?-^@VVr`j4I=J9; z{pk~x=d=;$YOZ=TR)APIWQ31jb*SL2sATaYi7IktJjDmcnl5s3(;+g14SH-aW!=&5 zZvUhHtWo#sZ2%nf?ddG{Dl$0c>BN;d9|984o zw_=D=?dE-lI7uA6DNjx&i}*JdI1Ma*`>YvAJ?v)E(#_Y37Spp25qlm z=$qRKJWF6^YHgg4g;5W2GgOUG5vO*zi^?#f{w_RCK#Eq9hlj^A{EqHAkG2EhO zC9D!GarpX2pihDog=Ovazy4YT&lA!lO1WML(klBF<5V+?`7D4;LB=tANp~%so0+$g z3pJ8qL5pj{=%W#yrxwSl{K^&L(dz)$B6o>o&dq zrH_tR8uK1iE1+x}Lfnr3vx26_OP;FMfoJ2O(@B6fK_Pv{7%~$ihC**NbTc|E^6ERE zyT?`@_!nhKx}=3q*;(5HA6&o^6?a;{D{4-nHjcs9wZ6BSB1!E&VRPjvJ5O*xdm7tdlI zEsh*VjC}$SreyHaG1ya`vRAHSN7Y5${aqfusgKbtEiI+-b2_DP#G6$OCsHrQ9dK%< zBZeDAmFvN$oSDZ#@Y8MNgcC4*kLxaRmI>?JJ&KLQn6J6x$}}wA9~q^(B5TBo44?hO zzA1+?RO@BNz{gHBt-+gBHutI@rxZD6Xu_BsAFk&8-Kkjb$3Up0b-jiQvW8ik!1fTh zFNj9*(C9pDK52ySsNFRG?;n2JB%0fS3ByeY1a}8KdJKfc6OahiRO=;Fbvoeqc6Hd?W=3VMD{fM|C^93fb%GLHKPut0Hf;~e-u9DZ5 zk4IFFVJ|6Yje_vVEGNYidm(qMsm$w1vKc5k)y2WWa0ssaO_JCJA;##v{SA*hgwy`1 zHduxMF!^*BK;$bN)(dtU3$B8sVG?9FmCpDMRu&+?BaEAgIM>RVPa|51N<}n%IaYm^puDgLm!4F}g!Q{&Z7ml%+r;~-FwNNdCALN9#cYc^UR9Ky3 z$@~IdpxTT{ZQ8bN^{i3g3q?O|&McN;31w`wk%2U-$ENc<+gAK!3EBZ@o1+020~qqE z__7a&EOR|IVFPnqo>k&)M&D#QqdcT!=s~Hy3&q0#p{Rg3zgz$u`ae(dK!vU7-wd!B ziYMf`NGqx3i^WZZQ6JczgDTfi`xlduYHE&+n29|NBBz_uz->*Bv7Zw@9MTmoc7 z<+|zE3Wb3Kg(hj>ix$Gf>YA~b-GR<}9eX=>!%TVho)kGIreik+Sc*cFO)j(j;K7G- z3j)Zso)aJl$V*J^l)1Fk$Fc*)+i7kK-2nyS?}JzDW*4xsKJM);SS^)V^`*9=hbGM2 zm;u)7!?&OCX<*E2UkCoONYLg*2<%(5YjM5};1>o_ZbIGzE2_FSRbPUKraCjpI_LK7 z4ltI))C(FXcHuSUv9tRLwLChOgI;;GdLgHcZ(tAh zSm99Gkc5nFWb^QsTacAzio% zjIV%gZ}(wy?&sHp(|#c{bU?iJvaw?+%Y&a<-T`0)xobJoXNE+bAn!$B65<~cmJ`d8jW#GFTu`U<33*tL!y z+wz@FS+p8_3eIrRc7M6n07A2{Uc#c`Yuph&v_d;i`>^bAO^>c!C0=pnmq#mBE^hgn zEB<>Z$+erpacP}wx5z1bmvv$;e&zOJunNc2-+yptKGB6&zTwLpGYKe; zMRL+d(2UeQL2)KxZM}ypA)Ih|50QPM4XC3(H%$&|&!os;OfsXvl~*opSy{=Vu?zhH zFjS?X&ZOR_a4fJTIdTp%ng>_JT0c}2GpiS==>Exb`SAvRCiybJJaw)3V&iVIo8W+Z zE|2QlyZ3ANa57af238=X%qY0xFCs(9oTzhH*xjF6;+hWMy7Y0)nh#GVk+s)$RVT2_ zyew;VG)H_e(M-hWe)|IRwoh0U<=UOp57-3V>9OkrvpI_ewZ!hudYH8^sqZ4s=6j_o z1c^O+iIHG|NH4B{xv7RFJb2sWQT~}bqlkajvY__<-sTO+coF) zz*r>he!B$qY>L=F=*$)6EPWo2f%PV4YLYOwC9@pgzvY{fQnsZ6K0IeewQV^4=VY8Z zpY!nv8d(=3gulibTxrf3>x?Ja-$Y-Y(cm}91O&k*>)?6ZOe_077ruEXK@$o8miQ|A(XNsk!^>q9GQX3bnQ+7Z2EZ z1sOy&^^D~f1T7~2{(6=ytGNrLF<25mIvrCO6lG9&aFLo!iDF9x2dCnd{V!zK`s#c# zshk`$=))C9BLEgLn;J#mSpMEcVTA{!KnoB~IE%w>EPdcq^B_ewIkUDSx$qeV6#nz8 zF2LsV(_MSQn|J+wc9==HNaLm@S+92y+}hGb>;{Y=2;vp%XAk=ar@reAPF*A>Kg|@E zYr@RsOmWQ}@OIIW3V8FE-@mv3yLZox*BGX(?C+9w0Cg^K`7fA-b6RO7SH61XSo`ue zRWTjdwk&#J7n_xRId5_a%S>A@acWyfTKW+U(e%U;MQ<@vwzV8%E1F?~>CFt^#n49}^p5)UFp;uW#B&_u zi;(vVxsa)DC@fDZ6FV79j%o zah@Rus3fkC97|$j41E%*yRj)vh#EkIY0zITSo4o_4eB?o9B$?xcngivOs5NcCWFHM zjM>GywV6Qb{Et`ejbq z<@SRJf_vRotkDW~_9W4kBr?FC=YyLs>#R7ceHp9nj_71WPDXB&8~X#klgP31(odM$ zTi84T(f{mNWyY8LkT5U6Ggzw!1Y6O~LsFwjzAMPTqAkjC1ldJN$U`Oibc92}k04@= zkanpb2I!rL{kpL7hmz@lT+_Up`(k-g69n&Shpd3wDy&{BHE!I;CZXrXD_7v z`!^UbNGTlnLTd{*MVNXkEAvONO#Vw-6K}E^juD?1Z}Rlco!OLS=!OaD#RO>?(Txs+ zSO|A~KRs|`((cy2LPG}5P4jik7z;e#a>;6ernd*W+LJ>rMOd%a+Uk(;=eWdbDrI5O zi>Au5dP8@%H+IwD&&%eM+K3K4Zp!i_h7V_Ecn?m2`S1KYDsLr%afRMAEegj?fvOC6 zK|S^=d6KfuU1*Wu10pq1Yx_yV%>|LU*~qRs0|E5k0vGBA1yNxB*T4N(L#K-l^MNJ=WMvFBxT0rumL_u8ThFsS2b>?} zQ94@Sn=nkA#~yN;Gb_njIE$Awy^MBB8dH){uKiYX2Qko9%vBZh%JIlT8CCL7Vi?mu zP0ocW{l@nID42#Ipk-d(q>`m{AVrNzEM_@Ov3z*J-C#lfd}07Z0zWdxV{8I}ISc(@ zi+-sAd_sWJg4sYV97QSl_2oWOO!zF0zcq1Bnt%ZMnizrrjJ!T(aMnk?CuxHj&&BC_ zU2qd=-$kSKdVphz$of9NE$afUMT8b%t4{v{zWkZ%)&H>e0Q?uOOSlc@wMLAbWzvT6 z&7={=wl`psf8qoc?Ob6aPIE!niRLf>i|BF1Kkm0>~vS~9P&meGhyM-|orOTizhz|d2`QVU{9%05q3Ex^dPf^PvP75zM zLp40SA+EE${He2VO=$202GZX&k!}G-dAivZ%hfk)xUm*#X5A%sGKth)&?j>5-e~O< zgCuLgVS@&jIM2I+{QK0ts*OiCEwr=x!}b97ZQa-%rF}{<_@;eUeP3zZxSo)tdQVz+ zqTqs%5_2ZXO!ag%U$oE(2&}yXW%5~M*Xl5@L9y(qtu{%*#ThX^x>rb7G7`-W1!lae zHaNtwOxJCEE#|1wi4W~`m-#>9I6R=0{a+o|1@Ep_;3p#Jg^eeRoOkn;zemu(0D0gZ z`Y?SMXnC%GnLqHr5&W^Cxi0%nQ7|ImZ3j|5poi*_>f$5dO^~G<&z@sp(`SrBJTBAaoFrtH|+brVDRr$d|LKdTrjr zft?w@VV+l5Jyuvyo;vkoH;juCmdF+kYlb8y>2XKyU^+MgG5>G)3Aun#53yY zyfKz^wL`=#C7xw+(M80{|9dW>RRP(gI|F`%1upDCO*GSv6_(4NRIS>D&glgx#SN-$ zF`g0hw6eo=T3EQ(ZlP%84t9}yLJn+H)Z7QPZ2{% z2%Oir(@+PBo*3O<8i3{{Apj}4rDbujM&Ht@q+xw*OQ%z->M+amCCQz#@{9NHN0N+` zOj6(Qcc(KA=rf{D=qr1%_$B@0MWKxus2at@P8lWA%v9$hWt;$aGroT9`t{wVJnjF> za>70KeP!iP>3V)X)8he9R0$rXo;3u>HoiPoowJ5CQC~3d`}AhIT%+dw)k|%@k~BnH zdtskf&z}#5ODis-ppfD7?Htw9EgIt+$|qyH;#f6p#OT#lX*UJR3wc8;e|utLqCj~A zZ&6XTZfO{69j(9>M|w$NcCSx1O*p60)0z1XAkQp?*6s*#3cJX?yz+JFGf8lkGS_O{ zxdO}OSt`kprobMv%xiMQ0BPLAmqBe$MO5~wwzeA;;WF93I7XoEbW_*^h!TX}R+w5q zO2Ioa^+6tQ(f-3uy`qjx!E}yz4h^8El!{H~vL*L9&m#&38py~^<%`CS(f;Ls^N*P8 zbYzELHHFp*hEY^DmBB4tSK`B=?+8B0Y{0qx;Mb+aY96l5Cs;a67#*r>azEpD+Ac1+8iT+C1 zcQ6?-ASGpOO8G&zta`=!uI@2fFDxhgyWfg(T!1(L@?o(4FL#c58IU$5Nx8z>z+1XP zL=>K&N2Y8ZNN5r1Abgm_F$F(i2}!;Mjj!opJwtptjY{H={*zisUm5+NxhyYK^=OU2 zKS&)UU$%ajRwP|I7%AK6)|NeV_YWMf`*WSPCN#z8RaNci$9(X%jK@d9y$fpcfHGf zbZa~>JG~lLQ&{EG=kBXY6?OG?A2%6qO~B=rI#ojUE@tskgC+7QHpnwq>oA+oJ%`Y>|(Hwjng z*MD7_K)EhS?2Ws{#aoF>*8+@w|NZw%n>2`FlEhZ(>yrsTg0!ili!k684F$-!+Dy!K z&_8)m@FDpoVZS5zw9zFSscsvw&^Ss_s zEJE4aW~plBWm2M|HK1N6XTH%dzn4X>S+r;Xxa%4*>NV-&#lD#CbnJfhcyu(=xc+)Q z;d8H_VI$Pk^wE%uoF^tz-P_YkjC*E^j+ns&?}Q2VrXHuxol_L#B(~}HH1f1#oNDX~ z59X{1bc%m*pz@|*>Y=-|a?4jMQN+@34trx7X3&ie4|)RmApPjwOixNac1(u!UI

wwPkP4 z{a!e>{zzbZ(1@6rm?~cLJqRQmK$oxIfLjRZ zXGn3GnG0u_&YnG#W!6_~L!4eSH{5C}!MkHM-Oypu%eQYwoS@!PkeCUYw)ko*K?Pv+ zbTJ-v!^e-ezO@m;2+)N^?;d+2B4$5&^ho$yL6cKbj^?=Sxa|-|ZHSF`V^{bnW&q1^ zrmgK^=`LadF}O*%S39(RL!I-QySvtd=c|Xk>JUsnSyDqOv|3H&Ij6B`=)E7b@jM(o z#~aB{C~L20E!_!UVHFos0n4VVq=jk4ZfkpcQ_}fZqIiPNn#7c{2bg8J5Q012TRc#A z(+t5a9zbk&Su=-6b-Sb_OeE>sk8(1R_9$TPn4a$)n^E<$rp8nP5e~sttR&$iJ)>^Y z&Q5(_$jk^as!KR_;X*jzQP`_WF%pv2>8(eP4k4wTsT!ubQwzwuhoMI+EGQ?4?zVzL z#FWjEZ1{%{9<(3yO57i*Q>&@C&-TE$8LKZ?XS#37k_X8|L5C~i+4xm!lAD~MnXFOy zJa?Qm9w4_%OZRh06^!tnZ!?%T?|?LyR>^QJtwV3#z7^J+(p(BNgkg)`KiV&j{L-!I zX=x|0>%ai#*Od7tIQU`>9`w5LyMd37&#_2M;q;&i-3M925jzHj$Mf(vFMSSPe2*{9 z3<#ws>^J`i1M}C1IP|ij;`rEI=DP2fl8P8tlYXO-vJQKDDx)lX)2LHSy7Bb(zQ@E! zBYf35+9w1?CYOyE^!)MtUFXklyp-u=SAV2sAQxi=>|<)7MDIiJKnAlznoDYY8w!_8 zvt~Ps((<%8*+uFkcFd~Ws-a|bk65w|3ytUIM`Cx4+%u!csJe6d)2GX#N`iYXA)~M! zkeHo4kmjjhSeVsW+okDYd-ryOzuCUQZ%frSX4dUFb7=SX(JPQdg0#tk<6Bx;9peG* zEMH+Y%x#5RJHb`L-&fe!z)oH4?EGM9Gn0v9>K#|Ox<(}?$}!SBXv7TBwZXs#`C;2x zv+{p)xp!_;p;S1pUNjDAq7}dPdHThXp-5!>pzw8-#-++NmKw`K+|>xxVx-c(Z8a0a zQzvW>O!U?Kq9tTwJVsH;&TH#k5tPx9LF&^XYX}GB)9r8QSTNmJW%kpmeUNA)`-@3E?(3kb9TVyCV8QnF!Lc64uye%tC1`O;r`@Ovmdjr`x5Q_Sn|T_xTs&wS;*b1d93 z&=|D-Tw!WtbaHxFfaVRId)Dp3&y_ATeeWJ>8XajG=1eUt%0&86}H>OJ*LscV(o)^ z3P%PHPRqpnVf$|Hro^Smb`0#Wq<$?vKev{Src^f?{DZEe9-x$RDZVy?*iKV(i+MRz4B-zz?X>g5(1iHkSYaK|m3~A=GTv*T)m!t3@qYrG z^M(%nWn>*z=i20ci^ZCt;O_1&oUZ}do`Y1v!J$&=ux+JSGn9}Zu)-vryCD(P6bEix zT%2M=Az}gH(k5I{SlfbsOY>&6S)+tqv#dbNVa)6V**nH50XphhqEp6kCF_wr?Q1X< zF7MwjAwd;7mnh3uewoN3%1K?8k7-B?fi0K+4+~uFjjDA3E zvfIewJ@#sCg7jOl_&3qi4ToZ-r(qs5s>CIS=ph>H;2KvrYtA45F|5malX>X(0i$m` zy8Sr&sEf06+?kWhv3{c}+D6WG>%oI?sr})BY=nKZXJw-BvbwvY=ZM!_9jtKT_N?js zet8;o@zg1k8FKC0D@maT52~EVxOB+^NYJlSSc!@~yidFUEv8T3_VK*^rcZ5TqNu_y zr)tmM<95-9=KA*05jx)c0|Nn)OfX~WI&g)va}?wUXztD%+zRn}IwH-ru{osYg);|} z3%2hpKA&URjcmQIb|MIskn3Xv3B?l3il9DxywCjX>GK>dOSvWr0#{Z=L}Al1~Pew z<}~PchiTWIJUPNrHPP2+g3^6vy^5dUD|1h%xySphRt=|hd_>Uw3hXT{^%;u}R{I+4 zG0C-^r^X_j!t|PmDD9;mRCo99-i=zfDB+Pmpy$$6t46MrSI4VhaBB$8KGKXphq<_e}eKVQR%M9#FBY$T4MJY~aoQOgwL-PC7$&_?2(U9XD7vlBPv=v6{(fM_ z5XqNAlz?MVdC@YaQ+{3^>`ptlb;CPNET%|lPA>2q*Qm8LBz@OLFS&DYBnHE$0E;dD znnD&KL>|H?g=sndpiscQqKlfIKkRZBtk`T|=v!AT8;4f`5QLr$1)ngwqn|`s^c_bQ z^dGrct@&vKD5@r{X7H7)H2d@sF??POW+RVQ<84O-L z!62e;^o?@un$M3iTVO?s80YT~m<1pPyV3SyvFMD+Fy_sk=VpkbXno^oCyP8csrDE6n}CN)n`wdr29Oq|NcF|CoI zXV&$Df~&EanF4Q`S>(gEM;`gUH!i_q!OP0Skdgjf+HBXx;*$oU!`byyOU&lY6IOqM z((giEDZDYsF?K5w$u=h>%uxk-qtmHY#jC;b6tY;8W$EH zs0z&vU+w0WY%aFNe=Br){xR&SbJXe6b1Hc+6rD3_!#wP=<$H1WtT4QP>}Kp!4~_cZ z*uM7aaK4!&k!(7zSW&^|L#bs%xg=6{VUH+@L4<;nSXo;S6&UezTS+voMYofF-WhaR zv`QS%2Xx%F+HTY?EiqdVb<>p_Hw9@iAV&z#ACA#xn(jABqtpH2vbW)imltq|Qym9ye&7uiBwIN1^h*uyy# zCo&QN0k5APV#|t<&!i72vheEc88hZ)bh2$?yJQ)&qFxen&@RXv-n;< ze?E=uc^r9Hhej+*rvfYulkT(Znn)iw)o0xqIC;{fgETtZOJcrmFJ|GWD<~wv!XjhU z2*Bk!k~cq7O>rNo$;=q@^t`gWcc=bc6bw63c;kjY5%{#ZrvM#HV7oEY=+s!B<=`lU zu-VAr3E^R}*WpeUbG7YNE1jH-2tZ6s81hm@P3;82rF)Ea7_OnQn|jcN7IrA`jrC;k zoPU)n_spQhPDj7h+LuP5%8(&`>?8;u!N|d8NHgs1kCMY%CCqYvG*>rwCjTkzX21`# z=C{*=ivv2Oc$`JUNHya8(B$biES5ZYd(z79PXctG03Q%>ApVLp*`-?m@7!+<@xCb-b#=*%{|8iTEKYr=RB`w+d z+sgc{f0`w^H$Uv%GNFzAy6nII z=088Run&0LKa-pkfaUpqhmiDs<(9r#?pM=JpYDvFvx0xp{Bq;<+!b}r1bo1fC#oSS zUuqTv<}!4%V#i{)-&;PoTwhxX`me12KQC63`ct;U_CF^qNgVYT-%OfmFh~Ei-r}wQ EA8=qbUH||9 literal 0 HcmV?d00001 diff --git a/gnu/llvm/llvm/docs/loop-terminology-rotated-loop.png b/gnu/llvm/llvm/docs/loop-terminology-rotated-loop.png new file mode 100644 index 0000000000000000000000000000000000000000..b048ff702684a7cfcb3fb191f14a0879e0f5409d GIT binary patch literal 61457 zcmeFZcR1Jo|2F*6o>m!Alu}kiMcE2vWRJ)Q$;c=xo09CPtQIn|%E~OeP^b`Pl_iiA+(IGZ`)c6mMN|PV1>RV6#ez__-YX|w2RK^`n9Xq$h{ctZXq0yoh( z_e9i%wrph~{qL_6lah3V*RiE-zyoR8Tes)lC@3hvZ{h`N-@lh~b}l6UY=}0uEI-8OJNTlSPZHB&!1{2DN(LjyY_B$wD~_jec#?hL48;Fdy)Od zx+uPyY?GR>=xBef7rIYPYVK^Jq?9djo!J(ttf27b%Zm#%bacKa?FZsC)3r``t%weM zd=j+(%$+!+H@7DyCo9~>OE!kcCN#TXz$feY$_T>F-k#sIc4yLu#)LC(T3YCcu&5}% z=xE00`mgDYjEt_@+rN3`IFe=6CP0*z-&lKXW>_l&okv%N*dK# zzwOK$sHmv=SCz%**S)?zE_?RurZsEUD7J-Q;17}`v*AmoVQ8rM!lsp#mBFu>tZM4& z+2)OG&kf61Vm%i)^R3!$etaUbmhfDj(RQD0GxHA#k-<<9UA>_a)w91kXc!s&-TsX2 z6A@u1vOE@@c8j_0OxMobKrGFCH5_bA*vM;G8f^dbqf|m;`Nxk+0dHz+w|K40AJWRu z3m7k3W%-(EsNEjw?=N}wtbfjPt@Nraqc=w^n>qS^{#;AoE$#&DIK=hdwcGCgA!S(= z6>86=$uoHNuA$^uty&Wk6MmEGZA7_k+460J64#2hwzkp5Xn+5d=dJ9w{ik^hOLyBA zPi_#j?F`m=d3oQFBh)(%DwbnVyZicXJrc65{Pc-x*REZJw^@wKhLJBXPA4lp2^Spr z@W@YDVtFS&KmWV>dTBK^+V%olDq?Qz^*A*H!$xATJ&*fxeKf`O>(>eIyu9Q1^V6lG z!osfMmh{1Fg>_w3oOtgK9w?@$)KA@sw22L`#;?!&|5r(fviZOhNb zYH6^{!#~;D>GE^Wc^x`0E*@9*7=QnFwAfU4*-oC^Wl|kn@yNC`01qge`CQ6p1EaY6 z38HIZX5@U~)qUPK`wEnv2;+g$JEt%WRlh$;P`%LFs;#ZNPV+}YLqn~l9wMEd zi`G6lF=B3PJUrVvJ3HsP{a97XJeLJ(EtB1Fg;|FTWqdY>h{N` zBu6%ciSsiB1x1Q#!fk{3m!HJb6=Nm5O21_vx9!w>5Oc)nW)oHCmoM~BM6Tb?bCjYg zbNbc(R6Emv*iw3Ir@;q4E@5FNK|w*r6IbIJ9nU>Hwz(tU+9xy9wy5_28=HU-LSo_^ z763u`Y^1tfQc_Z3sG<^^l+tEBW7mXc-FBc*^%l2SrgyGoGxT3K zOC0AeuFd#7ly$LUjj89QO9#Gv{~n=ggP78M2f>GegK;dYp=@>KO2yfFldkd`=8f^| ziLMUYvZ@ys3J8K((5l>@W?Ck6l_5+Fmb$mKG>+qM$Ar;?D zVm5Bvn1DD$c*_LQ8}-*lkb727Pp|$J3maQ}?OSA>oy!X|Yl*)8extYkG=npCVboa5MhlF^hObRtZnN2c7sQ0#EMWPf#?wd^ytPQK!cr{Ui^( z(A@ldMBx$!v8%hA0vpiT&F!}wvdyJyNRek7l89qwRSL4-T@ixtRf>dD@k$%Ts4ad~yd1 z3(JYCUEXS|tIK7pe%gi}bcpK~5AxrC{=9>zZQe8B%V6Mr|Nagl&T-_6`IqN9557oY zck3Lh{NWam#x5ZtVbxi@Yrkx8d2IwYx9J|Q)ny@Gy+Uu-nc;5iLD?t5j$EcNF zHKD9EAKI0 z;p5}uo3NjaEsYV=Fx@cNQNSlECPpR$1_Ngb3{_S^K}~b2`r$oH*mJ%BVex*|NEZ}4 zgMWMWy`#BgYHCy!NLTy{h^vJO%h=WYxn2=%Mn*&cs zck0(Jc>K!M#aU}Y5_8Q%ThslQ;bAIT52=GtiMqrH>xPWAbRY#banFUpM_xJnm5plv| zuNbwyV9d;I;+Ajw<4(SHhcOaGw1k&9nbiQWE>8ATZK9$&vpD;!5s`Y^E`fD?WlI9? z?(Sh>Vctti?)6VZ3YuqI?06VI7rWS7{V3goNR;QmAuWBmf_qe2gI7sO3A?oB!y}=? zd$u4fHWXen(JOIndHze+lKDfPnAg(eM$GTs`}cjy%O!)Eg(!(Qgk!7LBfBL$cY7?( z%J@<4xw^dIc+9$eCsLa8)cZsHfH%3w#fl@UpR+FpM@2;?o!-kPu$6pKyU&(+f9G7E zpC>QmnT@i60n6>}%(ovu-c4QsxPL=kbGkMaf@{i!0$$xb%k^i@oVn%a*Ndz*H`g0l zmnVLF&sM4&6d4Yi$k)IM8{C)Ux$OE_+=GcAq16dwS04MRJ~>=bV}2D-BKr6h`e%v{ zZsJZ_I?u8D1<6u^h3)R$yTq0Z_t4!Zn+63ADaS}Z60{CqHLH)l(VlmOTi*<|i+-!$ z6Mx0X2M+@1xV82kJh*|Alk=*hV-?mB4K+0ZSX*F)cOVmn(=XjyzP=S7K5PfldXr;X zM-TvpBxJGuGAF$bQ}^cCxkq95?%nJtuv@_4F94c=o*A3^*L;xx7GZx%bDkF4CwaO%oej$Yq(XO<6}rr!~uHEgmc^ zJbc{~rHu>>4AY}+JEWwfQUKEfMvA>w#SspDkVbl@`sYUvhLX7v%L6+ z`7p+VY4`5k1R?x{@^iBCSLQb!xah>h1V>#4rj&JGyyg3^U$u#M$m415-wg~5)<_OF zr|u632x!VNRiL;y@fD%H$n8&tzyEF#C&f;$RS%1XxEpGo!_A!Yi1;(Z#Z$H1{ek_d z$uYD<&%nUtT+!plH8K2$5cneT5DK22rI#*UdWRz75Rr%#ckk|9qeyEW%kQroo8o1* zJ`gYsMA@J<@F|uLacYg^<0nu0F*|haG4}wngCZg#h_Ji+&oJp%<4Far+Y^_@dwciq z5q1be6=avG{C0Xd_xiX2;_lr;vF>UJ#OxHrX3dKb2@wlpv}n8#@uu|F#E@P)wF zuU|jEP@sgZx)<|6Yin!EE=cr@jHEZe|L`FKFkP!no45qDcrP;Ya)YO??!#@2MYPoeKZ_@pVH)T01Ebi6P1z=AcAd0KT$=u@JoQ;w;(cqj zNmYBhuH4z1H*X@fWBJhT+LaoW#iv)Of`xprv9YmdXo!=z)SRN)ADEQ8u0TCmX^rH; za}N`RBn}-q6VMOrdZbQ}eqrE|Z6Y8mEh}rL&?<(ur?2k-kqE4PFDAxd>=);`Ao|1W zys>t7h0Dmu$Q9Up4_`$t!li$ddeG@c`CBY<3JPjjHmB@6d?7y^A!Jvs7!Vo7UZxOP zt>@>BRLJQ})y|ATsFbs_%aL+fU0Dt}IO>a9EPM*Nk^XfEAVd@XlrwrqzzCSFzv|YL zl!t1kD=8&QR~D}LOr@l7u&aJHKW4WycP+^Z319v@#o7%V+DKUW- zT$~jxLk>;IV%Y@+QL$btZE?kBpJLWX#(2!?_~ZoI^v+H8uJ<-5xF659e}9B9qP|^G zelib$)*=1ZPIQET!=TFi((g}6UaKojFU^#T+~;$0zM(|hk05QgFl}Mli8Yjnx+K2Q z{8DW==hUAcUUevi5&@HQTxTp3M$!j8ABtSh5cqUnJN#6v`&2;AH$d4J^*@STUJ}$m zq3`SKkLd~>J^J$PEq&=klsB~kNEd!m^8iv+$jau|V*>HEm}*sH|CCCAMHl6WGeu8|eZE$sU^%b^U*u#fgSXo(1aulL?yKx!9J2yAixPxO{a0T0f z@UHOL_y&bq7as@5*;M<{R{j!ZrVkaJoh)Q+n5LQDH8|*x>ZJHjr(0{0eX>A!@Auc& z`8^gKZr!>?k`shC{?7=g>#TypX=mpXK=SLsA2^J6?mb!mAyf>|}d zpXWxxTWZy$iK(fZFJ2r*ssgLB>4}orUB6NDV@xMbp5$B||53(@WCzsLFywGBZ@Ejb zv($qbVUzGih>I8scv=*tOKj?3l+g~x+T^D30N?o8-Q(y@^DV|uqRKp$6ZvM-H6g)*kgz@ zbK{@SGb3NGt*&?wvN>0d2kcursl&+UOp!$Cwe(0ioNXY>oJa1(flS^m)_I5&-X{UD$gI& zY_xu^o_t4O^@rE$@ebj7&SS@RA}CZZj+apph3@kLfLI#{=b@yih8Guve1w6pQM3BW zjU0Xz%Oq%(vebSLJXLdZvp~ywvOwT`FRs#%_g-V|MoNwR@&9{at7sGJ|4suTKBZ~r zLGb}kYBimtq@<^a(g^Jv>3Q}184TSUM@Kkbg#dqPFI=e zw(;y}8)$|N#6=Wx@?{gNOFt!KN0xzvHvA#NwHuc)yGafr6y8V8K8BzF18RrxMyv-@ zv@3+^_|1fb{lwsMnyRYq3;G?0l-8+C)FBtG1LftHa3*y4yS=3JCCj)m*+)dot8PcIFV!`5vBmGm-$S^5S78;i>UyfHzkYzk>87^ad!hJ4F;7L@J znTls`^>!j<;zM$Eem1sU?SgDD;|&CWT`!n{TgYtVW|C5bc)ocfdAEUa4L5iTMJVR!SEE%)%_cX<5i;UNcM7i^^PSHFLL65_lAI)O{MF*iH=ZgaCn z35f}~M%L^FzKf#SFY6Cjr5GcsbJNEsB4^*}+wZPqmK+30AZWoXBOS@36JO9-Ik$Tc z60LcjZa`ol*PmI9=9}xcBH?RcDVybf`|-n&c=zt^es(c2{g1H{da*%LHW}+SY}i7iYNkh4oW2F_MJA!~-38kcb{7|y4KqSkt$Ve!v}zX&ox9i14<>{j z5Eaz}tJt6S)!?(+_TjIYe5~#hQUM*mCu>+47BA`9cl+G;Pbo$%uBjfW*otbzwBqLa zp6>2_L?Q^wro1cKE@MSM-&Rye0cG~}y}$43C_dk}qn|Uz*9&)QLb>+fr2XZhFR@`^ zdlO_s?rqr4G?@2uc$jOv0yTn{`I|V?c-orQr`M(2flu2*l+HBXD?4osv zIVdnNkQPzU=k527jtf1#z1+ECbk|0{943*N;^Pz9t)^JfBp97)R#%q8brKPK1g?DH z0aiVn=b`>b9oYK0L5Z$zz7;2+oPp=ODLIFrZ3F!L{G?@NBMVo+VRDV|F7yvB|M?Lm za(!$QF*z|22DVvFO-(Je8_n z6zxow7%)5c7j9}xpE|V$+`M0TdAYn{L26CqgQI5T#gSc+o_hlh#cFT=pwyJ91zI{*Y9c#IG z!<$7K-;nf``L{xTQq@3REq{Ru#0VE(rvq5xbr-?CW@TqfUA>x>bb23K(;JfUU^zKI zKacHwMoWv{`{tPFzq2zJi4a;9@hPCCt0e}N4kmWsj9&~R>H;gt0B z?fC<2YWqnJH~tL$eMh!5N-W*~zRb4q5RIliSo9Mf3%UPDV)ga8sK+%vfVxQ=Kn+E+ zXOHz?(JAF#mclmjPIm(>q@{WGtfPrAl$YNkARxfAXM^TFs2bg<3!()~x7?;;wHdma za_^XJ=WdKdB&CnP#vOfQ|Fl$~2VLQHY0|*1gg0<&&-+8MxmS;&Dv~2fGJO8OiG%-H zLIZpK-%}X>|BL(|l5YQ(fmPhkW<0bP+l(DK;&y1LazNd;5;q3yxvZBjPXqP@>StJY z%<-hJ*!xL4RTF*Dvdj4WN2_Nlh&!5X8y8 zy?Z5(|DvY3`wCcuEyo)vDf*ji6t6x>yxca&cR!HZM@Nz*-d;Igx!-=|Op~&-^f0-z z-oqd%oR&E%Jv{(da>dBM~v%e_BuR(tO#|v;FfV^n?-+N_& z4X8l*JX%Lf)A;7b-+$Et&_q(xpL0lzGYvLZNjhI^M<_%rqIGNddRUqOpbl3f3^)jzz2`0 zs3;HhcK8J-{@#$p99_f1X+pNB^5_F^V`RL^w+TdU0CZk$T>OF0O)?%O{f$S`axpFg zy9OPE75t>6HB57Ia!9_6AbGUH9wq7NEM|V=bs$wP4IR;V15G@90LlE_r%weAP^0L{ zqUEu$V=a__8qHKd8wI~Ot~BM=t?SpXpM1v6=6dOEbv3D^ZQ8#5@XY2E1mz$wb=?rL zA}LQhrk$%C`}uPtlI7pKvjYU&g34z+Q2&5r`%`K`**@9)nx=Rt9P3jz*Zc-vxt_e) z-7Vz2simS~L1=`Lf`S}LeEwTT3bCopul>&p-=a+g|Bg?ZUg)LDn3$M5@7|r=wnum; zge2G<_$U5XA{_&%6PA~>HpO!Fx5TOs)@v6sGvN(ndj3TGs{Le-O!4oJBCREELJ<8a zh|S2sDO+Yl7IByEeaVzo{P}?q0&8F zT1CzxYdFX>Qj(IAsf$>e7=*JLA8TvniL(w4xjG#)Q&Y5rTC&m}IYq^A(2ZLNpE7{H zI*=IKhsVFa)&@i0hwFq74w?hnMiv&HAek+K8l`o>|0|x7n~klgsA%d}!4Iy*wcZf@ z^ubYWYgbZGxDU2%69Iz_^%JG!aI$(&wKXx>57ywwn@$8#HUWJQgX_G5StUA~o~G39 z|G_ScItIIptd}RiSav7JdRC&eHL}*9=zRlRPD4u@uWg2R9{ik4H99&#vSIc)C(ISl~$YrvNX=@usY**s`WijwZ z$Y$f^{dn;K7D;Ps>qQ9fvK`UKENBrbs*_V_v8y!KhPqeUKow?YW==4bd0k10IYbtq zJmLNFrG0=<#D$Q@W@Q16uQgY z;v%4qV8KC)u4b9B^X@eY6ZFpycuhVT|>Qoz`9 z@76};-v9#@Q4S{XZg_ZNc+x-S1LxilA+B%YxG+uX#vQY?h~USreAz~XL5u>~(2E^M zc!N5SO#U2kzATHEz{qU`C@u6@6eKv7d%4plxLzwIzd@lGJ`bq}Lf08sCeB&L{+)mu zo835>glx7EBxrbZdwawf7iz(?=gu8g*C$YI#M~QQTaG$aG4RU&qjy2k^3mUG`QTbx zc65{Y0>vGq6!qGVk58%_e}@NW4S||?9d;;L^vHK_I!sLbWm1G-nSnQ{H=!OYp3eIw z-x{cif}Hs%XMicFi7e9F1jQCoCq(ifxnJbG+;u%-#8(0C^e$v9kV8gL3%>DZ&xi-+U0m|bV%_k~0vU2=hoE}P0{1hwk!~FZ`sFkTOc;41Ia386`bupO2 ztgI{nN57)$<18pV6@K{u{YXnk{=xiX5UV0RP}G6kJfCM7A;1;v=eMysl$8prdmh|C z@E84JXMW-$XbRWfH06iKi}S%FC>+J#zGc0N1DOq7#kFUs2z?tTQF(^sz^0bP|1S#J7Q zhj!-JXxqyOKNj$Pl-Qe}xeXz?qSEy(=ycr*@~oLVUH`RU>C%(}d`hDWMfN`{>*}^1 zyw|TCMrQ@)3G?>c)F#7aDby&8Vy?%Ci=-m zIUE{Aip&?Xm==fAGaG;sNw*e4OBI%BBOdo#nHMXmIYKHRqmSrJv-$?d7cX9ru88Te z@64n<&A_Ff&SB)sc3xiIIm9aP=RTyV3^ps-uX`XrVpSm?vuxhHnf!HxD>%Jsh|j7> zA)t8n!Vh-ZkJ2|i{YrKRw4%*~=`iJQvetb6elsGX`S(|OoelTNM@gZf}Gz?C1>}^DuzhPGsjulxJPAxW~GNV8qk2cP?PoI%tV4=f^jXkQ#3?Yec;kE3UmKE zcd9XiotA-jwv&qGN%!sq8b zKV?U^bLkg~HJo;{Kihrp{(W+3!P-=TwT!}u%c%|N!5BIdb|xLfq&BsVQiMy=F#uf} z+D|ut{86*Pw0j^Mu$@d0qFY}%ax2A(hagQxrEj+%&78{J$L1d#{PxD$jnu5HR1oMP z_cM(b|E7dqui4{@Y4HOPya;IwrPghjbx5TE$u%A~=)dzi1-hD5d+vMl2d`g?yu$u` z>a;r7ONC{(A2updr>KiOOtW+6Esz5bXl;r#2i)$+lT0${mD=$8*RNl2``OOUXnx7o z^Zz;Sr(jwd1L=fh)nR`nmm#jx`S|IhCnv?#71UaOuHm|!^7yY1jGP!$b# ziB%2>-M5E<=A`3rc#{EW$^*xaX@HJo2jK{7r}c(wC>%z*N2!x zOHY4L_k|X?!~^^HCsa;GYHAk$Ou2+{x<4^-RVVA>jo@8JW$|x_Fj7yeU8wiqVd$A( z>{fe_`4h7AK}@>hr zAO|CosD9eko!pIuhlRNY?}m4vG_rEBxG<(LMca+04N|G@_nsOp__n2t6$ z-lV>RvkpQaJRu?yl$n_sy!)h@@bxhsNIR~FzG4Mwa(L1#A254=kDbmYxdEi_dT(f9 z?QvE}xoadL%aEMz!OZj%nlmv8Q$w&fMX-+!oQRZhUh!*FC)G`=QUt?ECkhMs4`ErKQEZQvG3g z_)Y+D!83ztLYLlA-&f`xXf;gABTYE-kY++659{Pex7~)`s-B6`z`!Vr$AZJT* zU<#2#ewxY1jfK8?YLelco#(<(@|HZ+K>$RRo+8iXS5hucPWeDPio`plt#i8C*U}cm z%sAn@&2re(KZ^{lp;KuyoXu1D`?_XYU~f^H;U{w9bt?^aE!ORhO*PeQ`-yN@J^Adj zF==fC_3#e1bts!yy+&DzaBo9w4MaMQha`H{!9f~wD2jStvef%FVuh^B;x@`}e=E~f z_r;e!LCl}LW$*OR=M=*-aq)%0{R#a@Hd+hkR^WqnHI-PI+YiYECLKRqayUY4Wv-Wu z8+!Ws6a;CLf?rgzozi{|GA;$dS31WAPTf|;AVGFJfbm+Qva&J^j)^Zb7kb3Zu$neA z3Ol4Ez2PVro-P-RDN9$<-2ExiS!|>^)#OgYc8xD90ySoqI-1G$6>kuV`AL&E{3&Y* zpc~RKoN0TE>o6yA-Jl)u$Mz#HrI!`4c`FQ>MH2|%l?HuKqtxWLxXs|?7EWaCIw>4><4H-7r!vF`2P7f zLp_USXk~Wd22Dp%37*VDKUOboIXGH{UoYt1s7zgae0)9An>Q;l zb(qwP7x&Wc*l~DI?dfqNiOA+SuF#);-7|fQv5Hkjdx9pRZmuPS9R>+xNS`UFfIw4H zMLDi;NWr(T4XQTRY?`G7ne9>TKNfSNH}sg%tn$fZBWq$zB00M7P{%>-ZiQ_cs7&PX zN&5}JvV(0e50P5n#*Kbz9bnm+wK5GtUYdQ1zt&ql*jXY1)Mq%V?19bkESG$aUKouw zZP_9)7hpg3ttjbBCgd1_Ut?ni8IF%SkRIa|B_`kQsN((E({mH3c`u4F^kZ;KzqOJG z)$I}6NWhj-fooiY^bb2AxpW6xv-cy#t7aOA`SgEoYRW=wBrPLjgkWF}hzv0(6mh8s zVZyvMYabHbM5o(0=i1|!=&9AOOEylvYtVfSvB+PUGsZn$EC$RR(E zQl0(8iSvYiLPCOpK5S1Vu9(yT^ZkbppVKX{ISjESW5S;kFQT6R8-A5k73P6LRX!mh zZ4~PfPGg-V7kZ|k_i99nxy@SnewmL;bN@t_XY*ay0s_0@0|A*Y8T#DF+zhbxQ|tvD zWCsD*v<>hzAT%`8u9ulO3CoC8NB+6tFE6c{GeHoWKSz0Y5` zQ0KL}XxKmAQx#-~MdGr${3i+AraUt`AMT;d*3JA5cv4sJ!!v!9j}U-0L{35BXlrS1 z?y+4^u8A;z|4ofU4s@N`*eK8Gg`Q{?{4U_EY4NGG7Y*7OeDgT`dL^?a#>U~xKul~f zZlT854+GV`D_=7L&bHk#v(IiW>V}<-Yxdb^5P}xyFgj-Q?L3+1z)-`zwvSZ!h%m&I zk?md=I+tgla47&-Ct+@@NZCOS>&6$RV0oWWL1wgR20o{@LIFiqh7pq==UR_x%DXNuTtf+WpVWj8h z&qIK7_fZ{?RwB{WrQh=N7|0K=$`q~9DzidT*#3EWc>wwEP&C)(t(?M|pfAt8_UOai zJ{WVktj+V<)uP~}Ny=FQsl}bEWRf;4rag%6kGt6GXWiY4JC`tsoQAT@$ISPlkY`g1 zTY@d-!u%16y(rM{!!DspdLZA|)!k1_JYeyov_x$M-r&K!@31&g>;*#DFi9>Ec%o)# zXMMLa)MAeu5Ej;j2^t`Q={V{|fS2(8NM3#2QKyCZc{z~!T*a|lG^1|mC%Qf<`*2M! zAbi!CHyp0}f-z{8T&9PV9#ewCj#a?A| zJzITTP1_95+}TZo{6WqeN<70%D+sW)BgfG0RFV_u`Alow4yQU4_rVPfDinK9-`>{v zs0^JK*Bl*jH`pZom6CU$^Z>AGxxmZLE(4k=35h_hz(#*^dO93mF#Z}98L8F1!xKoc zQ)n=7NzA!Fi3cv-hy_-U>AO-cYHIfi3kx~wNNJao+tqHq%ZF-P#;v8PIzIV%SYo!d z3z~XqCWc@#Nfd^peg+h1XQ{oDQzSNA#Fg(zMI^$_&d-m;q9g&=?*k{1mF1adhFiED z=ONB=)iL~$GN93%k9qAdbPpC*dXaA(xOliVa>Fx&wp@$P)3oWJ4oarrW#;IoqTH+- zNi~YS$T_od8)ICt5a1MP?5llagv&kS`HG%|1Zy~C0$`MI2jNzgk@-ALz0%;x#~;3m zCo>dJ#%vv7I5>mFX*b>}_Wt8XdW=)T&mX5WBeJw-MmW{nD?QODW@^aP@#B9w1ATIu zX0-}F36)B92MIP=`8m1@loM!&dW1j8(|kE{oJsv65e2$j6uYnfV1PlqC&=n0!o+~ zNl6tYn|8PL5kHc_c?H*660f1d1DMEOR;fme7XgN?K}T6tC*wDKFNt*u8=4%1r00YC z8`iE_qXKkR@=Au)!*gY6-fr9vJOKA+v|p%nG9v&FqI6P2)E1c@ZrO^Lti+}!%Y4c` z!h?Bq=nO;ov~Bl^tZ&ye%vy$)^xuW|)`s`)B0wYF2GH7z9uYY?xw*dk%6r++_)(2z z!&Q84K&>UyOpfW8xi<*SZnP>mqiJw^?XOYvx1uuS_~S&HSfcn0WfA=w_nm?&knKEa zOqP>f$9dA&VpBD?pP$=$I+bU>E3vp(R0j-H@$&57=E1g7kJp_AUxI_TS$r$ZCabFl z1xSYdTSh_g%(RO*PsDX9U#CigMNCfHJWaPTT@X(w8}{d8rE(F#Hu8~&Vv&C&AYYP@87!@E(lY!`tX#D z*Tc||kQWWYLF$_0MU^&U$1R(wp%x5wqxt+Yxt(ox!;R7EOt2BP0n&ssN?fLYm)R7&`R% zPft&)o$=&!rE6?m8>y&DH(msmz|=esE{Uh;+)1j|jJbO?ZR#l-s7=xXk4{BDT&9OK zTs?ZkOzefl(QS5=)M3(jSdP22e*96jM|(gx1{fbXjS{hfWZaOdPJoTLqT6se@!3~( zbZx$WFE{T6zcM1LH};!Sa=OYRlxJ_C!x54$RF59DOQ@$_+U-|z6Lbo{*NVI1Bf)b+ zN&;m6s#^uh?rp;)Yf$o@l}^U5+qIR2k>7dZVv<7L`}>C!^gUqdf^YQDZUZIT&B{A@^$^wRw9l7A>OrUhs7UdQLx27Fv z60+?)#>wk?g5M}J4lxI?gb{S2xc5zd>jF3*WqfjTgn2SuO$a zM=)M%A=?~tLVkEI9!7n+o*=_39D7C;@0v%9guNd9b{0p=u%K0I+|sZh`u7eTI1t@@ zSu(T$6i&N)?e`Wd)V(u!tK;UM#^)T@mL9D_`&9^gYKmd!dty!J_jJD}klkDl9_ApHR#Nk$=?-JpBx5L@R|Z4v^3}IW*8IzPxkCy*dx7Pyv)c)>{e~22)^6CA za*wg)04L{W$%@avS!8{+^8!WYSs@hRJ_pISq>VLqg}*+C{WhdekB+r}{^bSG%4kMW zoY~qR=ouD%-C@0Y^lve|ON4m*zq%?%4F0iyp7ZYvD_RUA1){R{e=~2=O{xCL!oqYE zg>1lz;-TCu)?)*-ZPV4=ph&yByV>(C-itSCF1vnwBt*r)XRwYy@vpttxOcG*ZPTb} zP$jeX0nzbfhfs;n5y)b6x)Peoimi2Ejn1LZk3gG8rchbd6>rdaof8*)(VKh&)lNK2 zcUAfNa|e0H-+uxJjktYqS?td@`+i+Bojtfa9>*JGFls+B1aWH~8#jdxR=V$o16HS{ zv%FS4k(7I16m$x3D4#t`wl`8^|A20O)#`+f@yTjtTaGvPHS<8RBp_B0@=C2+>x7*~ z{c&5)-{?@d3azq)O5Q#-_>W$9R1FeOFeCpOgps4K#-KOz=)cNsW&R$_Idq=OT@T!j zAoR_;Z_hayPdU<*IOG1e|jh@w!O}^BY2G zJ;Sup=?G{D7GDav6&j89Tpw*Ua(GbbS6&~@f7-S*Ha1qRpfLG4z4+dE5Pq_CAf>?< z!CsmJg&&F6Eqg}$g)Td|q`^rSJT=ll0F*<9#anHtKx%;&`(WD(+q~moxQM4crEgSp zGzaj!v8gG$*YZr1l#8Wh8XCI-wbCQts^R#Jsyzvv4z*XWlC-VdwVj$e<3*?*hQx9f z;iS2bfW`I3%AnL;=b6$IE(oPLW}jF}U@HHpIcyDkfq92-KU|exx!oYFhUdhe9-#9u z#@;iDFhw7Ne5aJmx7XL9O`UNkpd#iGXEQB-IrbWl2igx4kWcmnNw z7l4D>B`g_;?<#lJ0;HOH(Unpr{mO(RaY)Q63yUlVy59UqX4!$GN7a=cpV&ucci_4A z$bi#5f4MO9Gm>Qm?Oa8Tzb-LrMUj#afRaI;y{nJbX*I~ zr%;rtnbTDGiPHGw?CN6K>Xim3J-x?j zV}pYn;1OK=|8kzH)BFtp_|0yQ?Lj@b1Dc`_eFsds0_KZAu4w6c*34IDXklW*Y%+Gh z4Be&ZIO&6`5(Wd7X{l1Ox;QmLXtMSpetuP35wgh$iSOu1`n$CrpFpF&?K%#Br7A7! z3$4Y~?CU>NRridqmj6)Dq}eJj&9k?fey5Dj&1^rI#HE+tQf5>0Tk^==i9a}dKKp>B zbVy+Kl>>rS)D zI}d9>%A{Y~&(A+q^~A1DEe342w3o5{QL4}NvY>zgd>QT7*qAZugH!&aKZ{T!Gzp4} zi?4Ti^%mUS`mn_qFB`mB zK5_zO`y|SQAmod_k$GA+H<=EhuYcyoKU7wp>b(^xxROkdYSZP2(Whh}<}F*dZk+_b z&|h>;R`xb|*nu>tN0}t~h+B|~$pZ(DeUvZe1kHoSDDumBRHlFrRcJLjUMe$kUuefH zCfXl+ItUzZAaMSsqeqXbzIL+iMg!bzDEVbl;jvuQeR^vBBt*SHh|_^+RY5~5I~?)P zCf%Rwyp-ksr0v;J=sX!;EeP~cio(SQB5wd{$J_ovL7&YfxVaT{9rl-zCqK{)ALqDp z;3pc<;~@t1K;&eABDDjw8a)}Y01Q9OM1=#<=N;JLjhc(sZgAUw9M8e4 z!4(mG)a*|6Vm10-(LZ_gYk!}8@Ax<$adz`f!TuR#-3yss*A9*@TwU_CH%esnT2gh@ zV;)c6z1~Fv+bal^u|fy%v>rL7T%T%dX~}~6g2QHSb1)$evUAqsKOaxsbFeDB)_WVe z_Rh%2NK5{X)>ePuPxz!ZJylD+g%(;}7gQB8I7Eb+ZPCi*qmC0=sk(puOs4c_{&NTjY=11oz_W9PZD6}V$j&sym-ndq~ zu?Bn~9YEhkfT$p~RCJH=iTH2dny^TPV z=-QSg_Q)sCUxIB0uT%7<;YxLNHM{_v4+X8cu5;+BKRxBECi4122O}e6S3;;bS3|r= zo@L7^u=6N5(jy`k9OfTIf|cxVn92Wrx+AkpaHwwb!Uc7r zG^n&BR$(f8A0Hggh<@+$$dgf;g85c8!#;UIy6F_wKN4{m&P(|K5SKcOWoVXyox~qj zsXC@JI(f)-jLggo9S)DUB8Fe|x4SR*d-C0Pnru~hRXlQDvMS+HsPqF3$uLG^*vit z<|ej@(COl^0|$vr7caT%fbrglMrTcg!3YGhdd^85^5Bk;2fJbJC@R>G`oQMIwVrjs z!NCpa4@QSUynF;#w7AEsFAH-hEheY>6^L>m(Mfp4|0QQZr{t?TeF5s zT(LD(MT3hDhwkt!d!RL{fOng86?wjg3ngnq|N1g?{WR(rhL^bVhLv2cs|sRJEp>OX z`c|l#Zua&1c;}OG>pUDmQTK1x6y2hB<3lt*>Ar_cGlJ#!)YK_h-Hu$YXWX@)+imBT z^@``t*_Z5MX0F@ALU$izTm=qfc=qg>`HxaD$P7M+Qx>Ok~~hDw@#8iz&9BY(2wsqZM?EN#n+y&2GF>Uo6&lJJ$iov96@$N#9?-k=9JgXt4Q&1`fF1HU$j<&0DZzQNXMLJRDjR#goy+tf z4a9-1dqs56+wOU{Bix=fuSf!XtQ5-oyYM$4h>(Uu6|M-M`4pr$9A)zx? zRy^Q3E?QUwpf>73r$`kf;JDw>j{A-t-GPN$-IA_NLBJ4zSdmk&in%J$|Mw7K=a(Sl zd|QlRU|;~AvNuRleU$476_|0(!&A=7t8~S>wkWi{Jr)t{Db@l`mmo`xBjn*WZH80i zNf)TzoUubp003)0imJ5Tj(PSbi32;M5*xGIoj zHGz}^aFoS}=s+>h-&zd87uVMdvn(*9#aF`l&E5pP0`E*g;7O!`;*RHUrlRr#<3Ife zf*Z_t#M|}PHZ|-j>fhE6A8WYCPIzRROm@GCQAYo0YvHy1q&W_C6zOLy_og6~xSd;k zt7jollIttq=6fJkVkHVcq;K-*FoIBsY~x{r&5~6@<)^$1jD2 zQIlr_y?eK5JJYdpWK2-GHSSf6uydhSCOwR(C_t_rh3Wil_fbskg5u!GwQJW>NRDF`$hgTSAfR^4yg`y^D0IYvDE3^|O=CbSJ5*Obp2LTetg*7$$%D=ET)~HP zs)(XmpeJs@S|Qs8TzLx_F)JsB7EMs6lGFmAsPH?Do~Mw^wQ5s4z|L-A&H5wPxwD0sdZ-+->J)sKu zU39SosQ3uN4f)DA0>#o)Vrjx>n#sk@Ej^;-LDnCbZ?LTbu*(4prQsPTEqod*J9lb? zCEtX3?L46Vo_}7Pcnh^NO|=w9TW~(ru^f0VdsyN0YRrhj;}d686UCr2t_ze$<`W-M|1ffCsP#@#XJ z#vu{%sa#b}pskY)B1D@>P!yn)R?N$HlmyvL%Cy$T(lQWd|DCm-`4FF#n~Md%zcz|5 z6hXiuJc?VJl9&KY746`t7w3f$0?G<$PqDXtiKW=I92Xb2^h=Qf{Ki@U5{RE7M_~2g z(JQ0|0K18EkKl0M2+z`A-!csg%N>+Ha*kkg1F&)7E?G~SBS_yIdiE~Dtkep?bHk*u z`bt<7GRb}%QUk(H5}V{0scvN9%mvcviOl!@$A7(y!dE4I;VH(cIRhM_ImTv7o5L#7HUQVFatA;@ui!noMcCc|jT2R)! zD}Be$=i63;YL$XOM^0RR=1J5x4iadAKjmLwP^hbd>{tWNIvWOx$0FA$5qTL!oOsA{ zwo+q(+DZ3%If^v6XiooSJ^78_ZrZeuwC$5SiXcHg4kj}KPX(tnp9)XA^Y*EGN12tt zll=ZRK%U%0iW^<|=M)t$+SuH|z7a+HVEGK@^sG>H7Q+pgMuD{M{?m5C5h1U0xkH6x zr)7XKPIZLPwAJ?%MUt9MV!nMxO<&(73$99(7Va+?(>`1h^LzSqA3A~1X>s?;Jc>}5 ziEg77qamp2={LaVuxVcd+-jUUpSpW`)CMCIgL;pjm6MZ#`;#dD@+Duzx>(_3)Zu;7 z*}0^VS*B(mzf7D82ednDqRrkCOHB8RGt74laKVj!f6ah$A5NIpI}MHc^FwW8Le42E z$>MCeA1q!L8=%{%u`R=; zz*dFBNRYihWih~$N(W6K2+8pMz34TP$X8@*JJM?p@QQgy{tK;+)p7As_jxt0*J#W_ z;K*x_6(lh_QU;@hrzo)(%L>_!@J4msCv59-{yZa$R)#4nfxX9_?NewNw2@i4UOV3| z@wdCDZOwaAgBlR;>a}YXNJ8XPzBn}EJs^&Sr_JO72w+2ywgZ% zuxyb}_=v&Ca`}B32I<%3%ND)I-&t=fx^aU7f+4YYQQ;jdsh#cBh#NuC(b1=7$jMv? z+U!O{`jxPt$&(b|1uzXjMBdu83?(#V>T&A2t!~{W28(kz#!Jq_6K6$WX}r%{L3IRT zu;1Ch278?|600$8y!JkR<0mfSv1RU%vRZHJ*BL zB`gJmn{@;U$dPQMA(A#bVI7e)Ig~LI05_)JAAjaa$dJ7Noa)cIpfix20=jM3-W=ao zZS7tmW03VX-q+*GV$~!Q>Hzijl@At25!5Lz9U5{RZl)keEe*w11x#Bv(cOZEsxA^T zV}QxiAfZQHIGiC=Cf)x(XnXU39J{uS_bOwV8bl%#C7H@BQ<79dB}&G`BM})2kwQ^X zM41wrXb|!giVRUGQ>i2=NivkNLK*gN^}O%5zy0m^+xwrr{q;Vt++Fv&);iaD9>;MW zXI=Mu8^=^Fnky2ziEB<5+9<3^T=x#&qC{B$$;}-0fuUM``s|{FlN0p-2}fX>d5rbC zH;*R7W7ISw+OGS!%{qyHEh9gtTG0&s(a>Q2OHx2b)KNgcWZKF+stPHA_0tm*w%=mY z4y1wH@|7on4H z@!Q8;i0{qVdsS%xPFoxYW-k}kuW|QEOXowhm|wblc^7-Mi-lR)x3Qlh_eUA9PzL*LXB+>(;GYDW?vNUcYkdqW=yT)gU+i zU*RGnKTf$13l#@UZ;!yJI28n{?M#n81E1(MIk1 zla3RiMt>55IF}jZm-IXw$r$sC(`tXiXY6`; zjoMA0;tA=L`XpnmMvNFSdlAV+Cg}^}-8MD}v)WOupPyQO=zk(SMw9*v;hAx4b!WF8 zXBS)xB7)i3*$MrkuUeb=9fiW2<`5dLBEMc;+p&Ha1>q%+I^ARAz1kxl74AVB>qTcL z&vSxc?CR?3efaR~q?!&~!e`k2a-__nqY7D|_WF??+y5!u-?q@MPOX@9ihpHn?D21t z>i<~J|NrtML-vjK{@DN?j5>bMdR61|I4IsmOD#YZa(bm5J9aeH^3gLvH};Kgo^G>9 zsU8e4bz;xFu47J+VT7uC96yIzw+C@897v~1Z;#>`l2GH6F-`w3@tZiPLS6z{%-&ZhRd4J^l1eBeER)^N7m zcDfLQqN4V_A&GK&bVA0vdVvn&W}UUHjE$X#*N*Vmq1JIWmt4!Yg+!MDBPTxV*HL~& z(YdX64Jw~OEbkHioJ2I#q@t(TX4~fx)|%>8x}jLWwuK}W4X6Tz%K+UfJAAs?b$nmT z=?mVj6E{>yv}GiY)8NTQT=q9K^o=uhkPqy4^P4gekc|uq_ls>VHle*pijgPTFRxiW zOEvGn(Kgd>-n{ww`)9|)Q5w|r3p1ugYxSFT`cZMD3BG;Sk&|pXas%&-i|Z@(#9r&Q z6Ol>}3~HHK>YB=Pz)MtPai%pWy%yz0PO=XO$W9aJ32dJvkg8DObd)SyLT-zqXWoJc z%j-{`9GvK2ny_X|;wV7Bk^2WJTHVDU!!+kA0T<=ONlUleySv<+?O^(TO{eDpEC`kK zk{~)`R9xG`U{sD z-8OMu7Iv!Vu6o|IJY2nR%C21-dXo#X4R@`cdv(#p!oO2eGU+K?r>Gg~Fsh;meUB?$ z&P}VjP5iSK)I37Jiw%H`1X*c}tv9rm48~^3&IP(pJi5tGOv{V4>IIr1-8nXZuWR0( z*E?xlWwr{Jju1(c_Z}LxR$JJ9@?Xs)^5P_{r^zxVMGf4Uv3H=`+q@Ri?IhNHDC-`u zkg6Cjdv%hq=EP{I{vMcK9>~f(NxA)kpjx2Mi&ySBY*8NwPks>0?Ww0 zIH!vJ>n+m{lArlL#ItSHhPLK9ZY7DPUG#RBhtB^skLrhHHE8qnZ>G^MSUwU?Dr8Z1 zYPEiNPPuZ%=FMXOfV8#V-`v^ZHi!3X_~|Mz^m0qpeN!KdtfwoiCuW9Xd+UtnDJv(^ z_$c~I0vp3o%ne^z(z;i#-=>qarT|zhbas~4XudO3K`~T;WiBm;R}!c%avJfCh36)j zo2FrC)-Iuj(s$B`|`o*ndBIh8{2?Auiv`WTzIDAb^NORu2|DGJ2G8m zwD_u^zE<6ZqEK`$Q|E$dXbN*znz8Swcd`mjO-qxNuv1x0=Sb7*S`QW%vWw*B1Tdkg zg@rL)U4o_HGR{`-6g*3GVi5;gN)I~W-X@DlK*Ju<#|0e?+~`fj0Il}r;u1eysM@8A zu=D@dF=6x8?jQy<{cv`+5$aZO~qEX z+xSC#Jalfx;fs#9+xMNliar#U=kDV0Y#)|LdNC4L2~TV`vXjB#MfW+snEM%f{nn>X zpJs7Q`>e@IqOnHQuY)Jk54e%XTvCXXLHN?f+UN><8Ctl(142gk*9;dS+9<*h%P(s6 z0qaK^8;7*guC~!eGq?(<(+9Q-F_Z$`XoQR$7H!(>IdcT;+O%k<#{o76S7Aeciwh=Z z@mN|e0p9oX$+KVG>m=NOOufX9Xz>>usl8dJTeWDx)i8JftI3YuMGt?|@|5WDQx!sJ zgy|+Zj10O!(c=wV%l_(}z)rqdRHSOun#;nv>5O%T46&fK#27iC@T>rKYTmrL>pK%o z3DnDV%^KP3Z`J+%YE_iob?ewepK%U&L4hA@6Q?BbRC;CZ@_kD0bh$0OWDob^S`bfR zT?22zE!2-D6U#GmM~T)&$X2mh>HCHR{enQ?w}y;T)6{Gj#8NrOko+UV6E4D}*nVK; zk-!W*b@Y0Wf6F*)E$Jvx&a?*$Vci#ai!@I7CP!H6ymAv~1%f^HOI!pc@wy85er zj%X-&?dMm!;DPTc5PL!Eh{tXE$(dq80KdJN#67i>ubR`1Yv~bsjAijN#Oci&#KPu} z+*B{TMSA)eLioSHq@!80tC{{^CPr8a5!gR3zf3PI!dk=xI=&}DoKX4h;+x+<*}#D@ z4>`KJ8rQ~2NLTJ5owOpz+q_KQ@=Fbv^ah2jKtTZ7GcbS2dh%p!7fn<3-5t`n1;BzAfP&=Z3l-WCWv;~*Jk|00Y0}l__ z(fODXKjEujbVt3pm4j&X7ro)2hjbR5BlmzY7N<3r+bZ|sss)0)6nkWTdYVXcLN|`N z3HDF1uD9^I1STU~n%TCa;j9J-kh*QVc0iG?^b)1s)X>yq`zYy*9jm@z^XC?H*;>&L zD!P3IR9oVp7%D$A-sT4PcWdvPi+DXPcyX%*Z%OgN!oHwxpGd(_+1@|a<}SMurbFyX zO&nZ8^@PNjWKu>d^Zce>Qc|**Z&-Wx@Sa~ZwhPyOvBV?;y858rzAz>-5{qC<#zOmZUS*6v^>#ZYX3%|3>YTrJBow2~|i>B-Q|v450iWZu-)GH7|E z>rhDx9UQjeJUQm#*;$E4f;4++>V{o%ReGCJ_3(Jq#;>nQ)3>Ilj}=~OA%hmo7hfQp z&~g+z4bobs09~gN_&RSypExYQUfvi|9sL9#M3GJ>3LFQbGKTHRugLeIXMKj=tEBAm zb-w-Rkpgclcg;Fu<63R)>gbDtX`wwuxyfii_-l)`-GjP_tGp9H#3bia6m@!fFMhT# zHqP{)JUed+|L-9^2iYd=BpB6|d+e%##7IHY1e8pJuuKvDJ?ZU~-Seh!8D+8x4)80a z&=Vpo?})X0OnV0!iYulr!t_SBX}y3NZ0dvpJ^k2jY;13olyqY@#S2SS zO?5H51b^c9Mg^5!+*vqoo?0=-fCQwybRASFpmxYuMU{J0zKmViF8ie7zkbY!W4~_4 zS>6q*(xc*A4^Yvy@jiaM2WO^@jhKXF^%=6)!vR1YQ`LcO+qNYfw&~StprT>)a$5fL zhV}lDNpWJF$q(NhsHrIn?kIUvlSgp*4W4Xl<4(vuYq%@qbK8G?*m=B}lz@%IB}~81 zbS{eQq2L^_DlL#J{3t%Q6uYJX%$fETKn#jbAW0Y;2;zd;>lOaFaWhW6UOq>Z8=2EJ zd=%ESny_RBwpGt=KMcHtrQ z;1yeb|5!>vXBc6*kk`x(tMv;GRs=`oT1g#qG0r|kmpG!SzHo=}`3*n5Xd&+GAgK;t zp*m=&R^CJ$7iENKbxh8vZrmO~#QXbq>Tf5!Z*5{NWw;Rbj_#(JeN%LH5<2JRh%)4D zOSVxeZQdx2T1t8j8O=pcST{w*%1n@PkhL8YS|(jit?R9s*N*+M7V8IN@?1fOGB#!! z3-(4G$aGLUhfUlo|5O47ZnWjG;bbI|)RrJUhkI#8{uF?#FyO3L-Fb^B-13Q6pKuf` zN`gg(cpwlsaFvUa`^Qj%=TAx_+(lYQ!0}&(SQvXG0IXmoA3C~i;)^lW(KCoWqN$<8 zfpxa(`veu8;K4rVC2w0=WOjn%x*V|#*ACUKhPW3dt4i}=)uIs%wjMiMgsz*G*50!Q`(wJYaq9UR?OGjcGw z>|G;XH5sAa@Znjc-}?0WrB2k0lpQ?yWvscT<~%aY^Q&E5uTwJ1NSyP@PEN6$4F0_B z!LujukT)JYXm1{)M04>D?)TBcc}O#zITDL!A}VWosjk980wEj+fIra-*ca7;rJ&hF zLDHk6PqbZe%K1~w1fzGJ;qyc-0U%B!K)w!(HqniWQBVMxB2-Gw-FAs2@pR zJYrZL(S;*X2zMqCxNn=z-6Evg+^0LXZ=bk&N306WrsxkK7+Y~>5x*1h#Cr4{IAgNM zQmC^cth3AnM=p`9yBX%gR|z< zG>ug{zu4^9GdN^%ISCZ8eXssUfVwNVMupjNljg!o4)e8IYuYUIAbFYs9h>rVVGRw~ z&HD9AShTB(I?&$bAsH$2i*lXAcoQ}T_|v7Qpy;5Dz8P#9LJyCs%){IueGfDV&iEC} z)8~N~C0;b+AH-m!nKy?7*Y3iKE>h2tBUMF-_rQ^|2K2Kl?G|pOBgEzq4^x6-GM9Tm zx{m+aXM}j+b>YFmTQS4y2@Sr~Q!LuA&P)9@(jf|T1)?%&{*~(pr}q#eJEslMXif); zzzL8MT=A%rCxZGi7KRj06nT=Vsi`4(v@0F3k|Es}n7_ujgR(4ibd1Wa7w8p5mRNr( zCbU?hhC%;*=keb#hC2r9*A+%OKxV#8zDkxSS@|L zw4}v@-r10xzx`|BiQl=Yt1DUxIXV>N4Wtc_f45mBff$G}B@`8-pd`NT9zgC*t@fRn zBnk=&-h3Sjh8Lh|llkgHFLZ!}!MR~IX8u6j6{N<#9@E5e_#-kU2mE^Q31}_}jjymt za_uVeSc*+px2^C^g!vOfO#*0x`alsi1rOa!5>8)8Jj~@T6Z`*qaJ27pF(D$Qk(%iQ zFCmsoK$N7Ml?bXTAz2bV4w4Z2|Ml=#_)^Ae%xA`s5#YU&vNFD+fv{7}q@Zr2w$YdO zKCv;Yz#5v#T$Cc3yq+5zHlR*nPy)N##^w*{tQblsIi1#ZUa?{~Yb+xnahiL=eTKF5 zi`TDrP|%9N0)aQ9-yZ^t!{U&!U#bD~AN;LO`X#^=zPOK3gcyc~1R`4Ks#9v_&6}5m zxLtHaiIFbcaBVt@?HVf5_FL3n8Nf^JBte*QJstR%hP0EMkMDJOqF;3i6(@KpB*yB<5dcKKvIU3=8mxNeL!;t=)AZX} zIsuolapl(n+Xdw!3gTuapMSyMU+&)h`!b97Tw_jSWeay--V;M~|A)hV@kGEZ(eGCL+lM?1ACeL(Uoql&vta zD}}usQfIICEn=zrGP%`cBmk8`t_xBF zHAd*^2~T}VQ0`l*4(`Bdr4!H9;)AdS%O1{iFY2PI`rmHEG6Ss&f_HQy$|beRQEq=W zeMaX2;z}7pVxm@uo}%~j<0DsVuEhCq`JaDS!?a?Bqa&_0f8}Pi>_J6p=&9)Fp8flu zw(NY5pl5X#^KtWJKsIqeC2yWYRw4r&dSTPr3BCRUS7>c?)<##{HOro%HZ%YBFII0< z!m-l-M@}y=bQW*Dv7!33v!d5p$gY#`i!2!s zj0RIV0YRWd2jgfh6|n_yiQ0vm^a)Ze0hdTG_@|;1nE1Ax2Qza)m8F6XYzOw>_A4NE z!3HK_vqA@~_SmZqH(LS+o4fpVn9%3IhzE+;?o1OCy3@D?(uQ9R!vtmu;-(@A^N3~B zevqb}uzYOY^wv)({2UOz?hdZebfyc;h$!Xdlv2a<3JrU#WrXY*s4qx_Wh<0vW+L^C zB=r3g$o6I<2~<>3X+dGjEi&6X-4)hl-?FVVkb+qNZk=G5&nS}g>2L$@#>l5pPMKf*eS#~1OlDL*3- zy7*7BsG?4tKa=+9Alf-`v?t5wN*9$Ke*$pA4b^3}Mb|dZzLPSTHnS$?MbRo)09>aC zSJsijypRgcy>A&<8C#za_m@rDICc+@}2NLz#mZ>WmbT&@_xIm?W;n8D(K1rbW4{TcB%u zrY*F9B;ZTRqJOeaY9~H%gzF1KL90oh0NP&?=MCP6Ev=Q)X=wER81=LKtBu~~t4+Lt zjkd@rc_X(-s6~H=*`D!ReyWNYd(cat$pbE4SPecy_mm*xK30F^b|IDD3Konh#e!Gg z<6fmweu@_+mJ^in(Z*lrdtW;~LZi9x(?Un4Mqr-I0skzX1!&;MyFLVYRzpmf!~Y`? z4DVlM?3oMhldR|7);27y*iWAe$4m6ghSyKAc`2u2-$jLH; z_L>Ot$S za6llC-U=`#>hFdnR$IocqT98jsG{AOjv5%~yJyeCIgKMx9EtH)XX;q2LCoOL0SyZN zCg6@tj}=Nr$0}yvs(@5$*9M$JT1cXqBD{9WlE)A}&81vwveb#WYQ4fehxFX{ltk|w zH~?zSMNE!VFj~mXeu&Tw-3L*$m14#LAVpqvuDdgys$S# zO|ASAo`c-h2=Y^OBVbb4i^N$z-xdWo9C6YGqd``v=d{x{7wj8b`51p#LGVjJbc8Y zoSuTfw>op*alb;^=yCIy>V#}<+TtZk{JGK19;zU}U#%Osv}n|h@a)|zeahL-oFM2RBokU$mUX9><+VCYTm^^jU(FyZwi3?T%4AxIfw1M;?nq`={O zrh0z}nodF_CR_p&;S(9Q2x>E#>N8GUWgyfm8^s%2w_Z}jjGDsi=EAv+xR2P;l4S5oOj@ERf#HA!#i&|7R3 z8HpAo6iH{3r~d1L`!$xn0PdD9_~_)joYS%dL*j*PqXJHysId>8GYSxH)pMpQjF!B) z0+)qAtW=;Q_gwx9eyYECUt z$D!|p!Q7ktIAu{aamQ5_|0bYCH@51~{T6*w(bpQGLNGMbD{Gun^za$09LR5M+jV&V zClPahq#pVks4CBM^ytf*zy12Ftzmsq9MMay5eq7{t%SbnP*a}^mw;T=fDGMTSD#m%GkjRp|e%oB0NcpTnhqvMvDkbfNi z;jI<$o2MyYcCJ%Ylf>|EMFoYPoF!do@Pd<}YuB%Tm=ew*_ZLb7%&3H9mGYq%Uh&N( zt3>-@t6@-5YS6d)GRMUJ8Os)WY&(U&fH}DfGO0cL<20@7qwo@Ajzx??6oM#8!GxX_ z{v)pjj;qC%_UkIC9hu^5MgN9Bx_u$K#$1Pd=CssP3{Bz5*CcM@0maN+howvVu-Mwr zX17RsCvjimgZg#!AhiL`ze=3mr>})&1KHN5gfxaZC%kIXY>5Tj97(7!=_Y;K0F4z@ zD9*$r?jf72TrVkKa7*zciAniQD|#jap1FwFpTS3tG(7Me@UCirhQ@@=nD#Cr@3g++ zE7q#!8M#;+n-LcsAA2pUDC+G~A2i*!j`SBi&%jD;kin9SX$D$V{q?EPJ4?3!fDt7g z)p&V-wqsC_>t@!?{;dTVKTz^RWh+~^y6S;?67g3IQ;U0^@pGbusi^{+Rtc4%O=GJk z7hL9i25b>moJg~C5j)5IM0?}xa(cnF`G_(7Pzk2ohIG>9GDM5FY*}B*`GV{rg9qm~ zJWpP>--dWH3`+187v0*xX9Wc_B?U_IexJs*2@WqAKnK0)#cdBZ2M-zX4a7IU`@=hT z6sV|Wy+Mx-o1{}N%Yn=~EMFeB9Fy$&&C4_9eumDB@g5q(6}u6Nio)yV1NcN;rUQ(GZ}2tF#;NJMQe2^rB_{TORu zJKbMujdonIM~^{JL6lFAO!ooX-Qwqr>5DK1t`r)2%59f3o?5+oJ5~00iC`xG_l=lS zrxHSi@KD!lZE+e8A~$2k<1wc;krN%YSp}7#R!NiQzI`4b7a*RRWS!!Z;2`E6``l@m z!}KXra@-t_Y%4)yf8!bU8D@2BHk~0c>?8S+{@K;6<^gdjX)Yx}q|JSH6+G{l+NL{y@q(NhmzdhZ*_(^eRPW z4)T0WXzO9xEjN`R-O}yk@}w&BZ05xQgH2Ys{D{h7}oj!R#PdQZ(Jn%}u(V z)NEsqFhNUG1``NnBs4O1uN;+6q*uVV>@6u%ja?DEsXUsapM*5~GeD9*Z%7O%ZcT4c zc==#RPd2o2+2*f-HcPqX@}6D-HjGbMFT(WkgtCw!o+q#O|#a#LHL)f)WKfmpE`mfErAZPE_?tRJX04-DR+`G4V>2dz$ z!Qv~PjTh`^6CNl?ryaZIBWBmyoSi?f;-L3W-RdeAvTe*Q)^s&IDV3TR_sij<*I*RnE6<_(NXDl!9<%e!`@b zRIq8b^U$o%vQL+$LP4H=JhH6v{t!?4mIqkR5hl7+QPDq&S@m5+`;Ku_JvkZM*+34o zY})<(S37zaI;W^;{pm-yK-wP?DA{ke`3-49q2Y+Pvs`W*I=4x`C^iwwi$@6iUzUVld?#?OS3eT6!$8n?vzo{vEc+zv z7L5o0>Ot|Y{_%Or%Orn4fv6~YQ)f4|jij#8f)x-P9LdX+U9Eq8^!k&NQVJj|lI?jr z8m5u5`z9s9#SsJV*@jcr2i~S29n;j-vz5GCx-7fBF6^&)noaKIJXfmWOLUpzW!8F1C6_wMKeGbn#o z|NQ=WuGiMw3r8Iv(|HtKZp5{q^`(fOY19I(1zpAPx!n}Erv19^zyZ9H!;lyI6$)!b z>6I=NA%(M#{t%#|ka`$m7XbA8tFVU2CSvA#;BC*%n}r(@KpHB{spf6bT>Am{TuGT4 zoZ}qV;KV4&4c|ZEjZ(FG>fHB#u8-F+wCt#|zC^(|V!qYf)lbrrPq;0A9}pR-ayBPr zpsiwVeB$!d$V-OH6H;a_kFh_fdtu;!XN|7D+||zeaOy5qEKUb;FVx_77nq`qMQV z-AoRcD_&c?7)he+JYA=I8O%v=Tqj;Ms~|-d=wgdDom%I7{|^6*XX!3*re64E+fD8t zzbYzV${Jjdc9T@RWG`nvaPk1#P3*C)U4+31m1*~m(+%?Tmv(rVs^g9dpYWL*1?0sl zDXOZr7NH}HI^1^+YSXcX~C$F^OSU2Rw2jGIg18>U*tH}2ZHtxW0A8qXOzXBNDE_38!R zN$uh2kt1V0?H(6o#XnnwTe_&}$s$a?E67P?ETU-<5RLp?bl}#iPkj5;quOW zY^ywLAsd8e8QNr@4g-pN_vzyZ3zK2FJ4?r7r8NuJUb^{ks^RC`QwAQa0DgDw(N@(_ zQ`yl;ZI+w=*wc%2!G1|vF6)nj1a zzW&6MyT!#vc+Cm3mQI`2-tEn!tzuMnQab5+Yq$D$1ydYjuR%u1Rr>Dq9)p2V{r2AH zGye8(Xl!ir5c$8noSb6uqmq)jMYg_16DU3+frsVZ542A;t?+E z(o1OqnFdyVlHKrb?s{st-l67ig|A6Y#mkqmXm5t{io%CfW1tcYOku)dj%3qyO&_23 zV5;#SFKbBFA=~+%X?tw3jAMc2Zl>av)-`<)3FchI;wx`@TkSq&oke`X2V)$Y@VQu57@Kk6#Ug*eE$mHzM2V*sC|05i_26*18O-P zkHx3scxC_IN_~*jv17+*t1V2Vh$x}mdBE0U+7pW{f}}fG0hzucrAKTQS8&QkcNyWT zcd+R?Z7bTh6yJs6BxL^-e%t3fwQC*;0M1-y$=rG2x6Lg$2hO*b@mukc>bG8UQPmOavm_A_6C^~<2)PQq)$)l_{~G~XJ@Ca zduznl5yfnRaZORub}FdTpY1I-a<>XB^2&jLO^g71^2Ss5Ly57m_zkj#h^1l-MkuOy zUBN1*pguD%Zy!+S?$REbkz8DD>e5nERT{VM(RXyscyK6K*E)l_Hs&-MBtz;ZR)Xm< zKU??8GMcL_*#^sKOf={d4CH@;Tx&l~^u=MvXehpac*xHAS2k$$pR-|67)WSB!CLew zYCs>wwQmO>-VN7b3^vv~b?!9qavONJlp5IeCWj&q&h4EWHzxFoAR!cj?q#=1abk5i zOk-Z`)bVF6b(}yWoc9luIYA7Pw|#``*)o*e&a3L_vRA1OoE>Mg574dnH?r>|P&)px zFT!LBLQN@z8<>!lU-$3q z6ZV1zN!6Owt3{$`MaKf)--=ZIEvIIXeh^u%6=qRysmJYezJC202SmJ%0FholrK{)s zRai}{iEAyA*R~hv61nhhdcsepY~i3{OcY~Y2*R}V)9=`jbt^S>Hzc-b-h3~t*!(JO z&poz)GIhX0iDNW1GhTS&4%cPC{40kjW(Hn4An)bffH3DRqr-+>+LDzVw_EPA&zp8X z+*A`ff^&*WQSdIvDWYPN&^h%)C5J`rqm5@NNPqj&4`B$kwSW4!T!YdiebF!ds;VlA zluA4CVk{UJ4S&Km0-hkV^qDjMmYe4?FaYU@cUah*)V73l z7Rk3U74EvA*bE=CJ z;`FJZZaMHNGfu7+xi3B)IU9p|$RlP`Zo_?cmwJ#H8#;UDB=e%WVO-1lz;*U z)wf!@TYuJUAqqtkrBh%Tw|i#uP<@9gt3|5)Zg2zz!GW2n{EV$bvh0?0!eSL3Q{bqJ zc4nwH>r=fu^bXpUu;DJUmU_zqoCm9BsV3|e4N6o%9Y}j()U-qOXSt7bSZdLM9`*=5 zxx1nn`{>dBYmE8L!@qp}s@SDV-0&VP94+P^JvZd!Df-WZT8Jd#(0H$_Mdf-~c88($ zpLPB0xH>CdXx8LK2+enOQ*_*|pA|35-}dvRVrXjh@rG{+y&LkG zzfpDcU7hj3uCHl~^=9mYnN?+oYycd7fV-*q>x5T4;pq^eOaWVyB*6{C^!xwwxw=F6 z+#%PYLj{V3K3Z4+;GVl^=Pgyo-AU#F%I;ZhEz>>Ruo}mGlMH7C-f*w{_)8X-UwmjQ z0Z`oJk~cHDMbqjU7oWyZOt*V}cFO%Zvqe|&e@CXuiqW%Tl z)pQ>jY6KG|gt~wLHwp?;?p=slg>{SY+WpyB_Q!&uo&P)g{Mas!162D>rYl5K!udhYxqD ztA4s41(GQwN5^j6EQlV?IVWRcf?0ssc6NJVbxh{bHQC%-dc-NnS>8E&Dz7A+0bh%O z(W|Tc6noujpI{8zouaUcC(LYL73eMk>6i_A1vDU!JP97M_q={P=X@siu@qABzW@VB<&YR2p`@qLk`MM6GH5H`NWz!(!xC`%~5%xS3OXS8Jur zv$j@x`t+#~3%`MXTlek5JdAy#Nrv~ciZVS(9&mkoWd8^3(M)^46$IikN}g906%)yl zdV?9J-15Y3*`#J?+{0mMt_ueBs4O^kZv%(vuii<@^^{xtV`8*qPT-{J6f(%}oVNh! z%%@I`fk(4~gCU)B&W&tA7xlZ-Tx*wm@4wqxx{rTw|Me4wl2ds^DIs)5wU9>!bgO-o z^)k+&@`K_|UPNzwd4M z_VKKHjOZ3=nYmzAmD;@cH48>e^6F={@nWAL)0S8i{pjvKYYE4TPGAj2+9NP!HfF9} z7U38?3*@D}V3x%g5FMS?1PCg-m)kVMW6{M3pC8Hf>+7k3Ur2wAG=mqi?Sufq zezvf)CZ7c|k(Ks_hX;yXnV)p9GS%c@eDRa11!V!fOg0Uk)v-_Y>1<))#xk~&pr{S# zV~a?-N6NbpF5u^%pFh?LVHuNu=y9EpR5u8h5pF}`Ir=B{o_Hg>3B#w2fSSWwFpE&=`A&SsYTbJi|NmTj2>O@gIZ04Wz_KT;wp3)bgPUw)TPdDm5Qg(enfTq2b65SRrU0Ojtk%<^s z^iAPgg5jkYisqrdJ>V6(zbtZ6;V(`r!MnLZey(pGX`~nTWk4};Q*;Pt1*z{6!c&HU zQUhs`#X+u%hDJcI@&$hy4xTIJQ-X-f6(rQ>E?me0ANo}G=XYm%nwMLwN$m!dbCVSi zwgN+O;pPgsMZV-p&$+k_#W$l`b6`H`Cw+5s^9%|NR}u~GGttNmq020%txQ1d-@m{4 zX=bprgR|_urLks&WJt|HGT^g@9bP_M+4Jo)_esA1=TT4!up*^YH;GfC^j_y@1Nr=; zP0xHCrR@5-GeRP6Ps!|9B@#W+4T2$@8d3vF#+8(n~{OY1+P=4(04nY^?b{H5Wwq4Gf zw{OkD4cv6=9<3DJFvFZ4c}tdn=y4qAWKy~`uxnhKeb|MqB{HwwuhyhyHSka z(qZ&o6up=NCxe5TTUbQXU$YMoG4=B0Yl`Cy?%%m1zFMxp4~8SheUiGF4){7w`7QS} zOfA#@{BF$9QIy_X{&+QtlxqgqC$Tyh!%@pwFg5{!fia|8kI{#q#0)@CMcr#}_j-GW zagY3}K&xNX)Fck~c?tC6#ICd7*^>lfEbye-y3-Y&J&=QQ4$N6F z{$=*h+4mXx8yaf+aux4q(>W0#Lm-zG z-k3_L>D<(oa3sb3S^kHk;w!!B*6B=d-2VJs7d>aj5kCne&TcqJ z9c1X@UCcV(J1LWt57Tk5)#+HvA?ON1^QJT5jIK%(Dk!5XY5NX=Gl~T#S+Zj0n*Hot zck}7fPZ3X!Kv8}A$wkezF~6gt;sk1W`k; zLQ*vyd{FrSGnV>zLd(`-+nh%zSjP6nJakY9jhzP#Cfv`?jwCs-rdMxRHkim1Ne3^i zD2q86X9feG%Nhcw#so}?8R}x24_R_2H#ZpEei{65Ej|3(7xmP%Kfl=D%JIm-C#hM7 zDqt|i zb`I?SQ)WHe0aCWd_)hygxNEX`@kft#!v%c6YQK^%=0!Pwk8S7D>g1Wh+SQvoj7}I# zu;0P7gmyH(?=;q&0QxTc1@2U?`N<{elpl*4k}Z`*mf_0#ad^&E)1B%7m#N!G>Vy~) zH=c#OrPx`CYG|c<_rHv*4(cp1_jjb*yN$Ax!P;2EnN{ z5gb$_&d*!LZf$n)-&%k;n*hK$2PmbzIhA(Twv2_c^<7io>Mr4nV27|RJ`qXYrt**6 zyyYK-_7gaW%dc?bSq~JcZrz@~L}FV`6x4H?7fScv0S|R#GT6VhA+*`&%&Zwoqh8|8 z^0&^XGHzc24$&L(_-D-){;lt_JFVJxi%nTcddwRcgD2hc&AyIb>gx-2RJq zy3)=?k}@N{(T}`%7a4E{L=tx`>FfL|H5Gu0)osVF{|Rp~aoV(?2R*(BFQH4Pe$z7H zd{#>mR={YKy?G8z4GkH(hGiAOR9eBH=xy+_h#T|l@gw(zGrfzBtJ)Q4*55Lt)}R%6 zDl?lD1ztj%dz|}m2U2v13qPpAeq%0@#FoE%j)t<}-DRv$il0On8*^`JO34V4?En5N z(6vntzb_y#kzJb+dgCQ9bZc8XJTqcD{UP=6Jx}_({B&4&cw(Jy>O1F^Y^HT9FMbOB z60o_$CI?P%;l_d_*U_O_w3TRd+bO`u_k)E?;{h`eqO{%by8pX^P~ zjIE=>iz(iNTV(l`*_0!6DDBV6e^(rGTg5%{<+C#**|xTq%WR*yv`xFR`Nuw-xeS?d zrT?z`hR83Yo^<@{&1Y*)2tp@g=?;(_UHe13`+mHOI5^j1!A0x1jw@RPo5xU==;-Rk z-#V1@UVgOIkCampHP`b$tGH*Cy7D8XrKR>~?PRZWlWQEz@im(b_}GGsM?sOQL(Kb& zAHX%Re$1wNi|^Qpx8Z_rCKWw<<_NnZjL(Hg{NB+~$~XZ%8YPoUe&0eu&gYTTC>-7( zxhD)f*lX0NF5p0hqziS$Uh|^lF|?JHFsVIbJ9brCWX)pdhTWwn(gq(74PEldT^M|D zb3w$3&L{MCvo0Iib|XHJ5;~Bkb7a1QVvA~bQvZEw%qZzSAF$i zJ)5WF|NLx5CV|Y&NH_E)$N=J##6lM&8X9E2hBrQ~00YU);(gC3|HzFPx@gca#3&VD zo|3foYy9UfSDi+u-<9t$#I{&&v9MQX;Pu?^pTsmp8oRr)6FWED3UdNY$*Ad%7%z8u zIHX%SAhO|x4VMc2S6kfeSal@8(5+1m%SYc3ug-iq@gSN2xx21tI-uYdy#5?!zGT_- zSxMj~MSo^<2T>i0shyIJYQOKKw~{viq?7uHU+jI9?j3&*+C2X6ciAFAL$=dax=z#) zBNhWa*mgesJYdNwH8Zo~)0QfE7k|&%Vd-fpd1K+%b>@>WqdB9~Q>xj1Kaz}J=#Z2-Ly)K}SaBsjA%k>z=$lrDeTQM& zaVhf9-n|QL<`t9g8fpfs)(P8vGsnDwX{#bR!IC!^>2eA5hCZ@(A;@+vn;WV!BYe5;HiA+c<>kM)aXk|EA37BK`KUO$BbesV z$9vmh3&_#dPrA-2*LWJxy_HJAuS14!KZG8*yBGzk-n(4PFVipD9&)B_?cy1CU1t&_ z=bFV%ZI@{1>dK=A0wTQ*RAHX7lHXL=K@3cBHnV1EWT{*B;=vIg@=l+cy4vN`!!)i` z0dj*-oOC;k2tp_$$nY~-b#xKqu^5V#^6XLDCGXZwb?z@lqi|J2zJ2>nSKrFDZf%GWZJ|Nk+f~%bteWkV$f+^? zpUpTJ@X6tjfApB0(GC{X%(czFe_xA;t2Wjn+2pWuq(II*5Tn>XCFhKzuIYU+XILR~ zg{;FKodo_!UXs&E6mOZCnO1;Gt)-b~=ZBLCMO^qmG38q)|8TK=5yHZC(=PqZJVu9K zBrwZDXtioxNe!WL%&YEQXz{%xc){e^J$d+Wy3VTn*kCLt`EvwI6rVB!qr4>L8w!e3kB^&Yr_CtJ_k-ihRiBrXBp>M9z3?+~H2Z^MK4WVs z5swU?UJ-r!_unlbA2*Zdh=0Spw>|B-SM$VhbRI{L~MeB{NV*xQOHfxA~@ED$6*~21}nj$3_Ey_DGEzHd|X?ql<5|WGfg2Vgw zPgFNpcY?U;v|<%ij8QmnXr93DJL3Sm2~hei~0$#Zj{P^2m8Snuz`1QpCv(-kFdYGc~pxQErKcY=`Nc) zpdQpW7ZG&8=qr)H-bWM?K-HK&xvc*T>(Nh(i}Q#*1%+ZhrsX(hA|^ijK)1rVdsx`U zSp6nMMwF1eFj;Kafxbu2jUd*#SiI&`k{@)JIU&HZaF>+coQ&q)wD2Y-{etL_H6)3B zxM=?Eeq+rD`jwpmn5svk*(8iOomZ)%BA|`ekRnA}%4bwa zHZv6GOpmk4qj`_?c^btOlf<_S#rxiwrn?lEXR~_wYid&ODFx!g>Ehvj*un(KRiuDs z<__#ba_1oLT5$9E^KjDce)(V7sg_g*!%8<)-8(!{D3ME5k<3J`9o!=cN8Lw6>br%7 zvs}glzbxZwP%CqOtxFF_$2x?j2*0THqS7Z;t)!rc3W6&3B`D?$Zbz@Xmu}8 z>dk3Ocg#OkgPwe7_8g8a?baHAj0n%Wzy(+=|AhzHq3>p8lkq2RYjD*!v>?@_?CSgt zgO4@w&<^oyC*%J+YUD_#ZsTbx5EYk63BZ=hfy1~G&`M>h126)V+CRnYpkxUqSuk)> zNPZc!$>NaNIlDoKgp@4Q(%Dr%bmr)DvM_}Q6+XAKI{g!As3S*SP)2mXOty053YlPR z+?-dw@KL%?1G$W+)QdXc}R3Ui`@`)c=CJ(qpu>K7F4nD=7i7@8oT0(BT4g zfGb;i@u!d&#=`w?gzJh=hkla6UfS}@fVeL+V#LM4U9|P74tTDcWT!$XDeNs*m34;> z*Z*x_XHz}L#f(8|=*QNl8EU3HOF^es(E z@N5{0V9DW&#-iDoHeHn6yKC*x4;H=3+{?5U!5*0S_E>dDKdaPO_)m;jbxbdLpyMh{ zh)ZQNGR!1!W$8MwkxxP#gr`LX$e8GB!NzRyr%&f#eMvjDBiEO1oP20%URl{Si@(&C ztU8%dQTkr(*%AF&SAf{X{0;sh zbtQk}ZAcr10|VP~`?YJ=iZlcbe0tjppYSC4NC?3un~$Eod;5Hx^OxX&CDtmz65v4K z_FxL%8yYkR4VqrPSJ1fHgT>z(3L66@C0RZkrNCyqmHwfC^@9a(+f7qxbaN@KLQHg_ z9bfju!r}Ss$IzvA_oOAyPi4n%Nt)kArE*y8*?{h=Chh5<6Q-J3@^M7@poes;;S7jV?PeM-Uj~^Tw#9nD0En_|C(JB3%~wW~kX* z^5`2tpt})T_Z&4UwP?vh9O>y|pa_k!ShP`j4AY!=X~J0mot5L42CQL3s|MiQDu9)F7JDtIEnHc^fEArX#i&k}={|G}O^P zMlrT%)oKO_X7PEzpI0A0PKQHy#eBiMk)<7pCbg79`?&2Mjl%&>Z}u;4!blRk86bAP z4K+12Q>`zmp7lLna{TCpK$euhrM@XiVIvYowj->2G^eYoc5`BFDjT2hr#x+Q{La40^=w{Cj+2~3 zKtTC}cG{DsM-lh=>QPW2k5HV(K~d%7Oroa0sJU5;bpX}f>~5uTp#og-=_{z z&royW7y|)PK}+x?$}wggtSx%_^hQR8EZ^n^m(S#wX)e*%d6fsuK!<`RWFa9 zSy?hCZ_`{n&KY~MAV@L&htPIx3!~aZ2Hfu_lPOoN3#Z;uHaULy|AnI6nyat(SL+X# ztEXoDy7*$}O`gC1{#8N!gdim01@JpQ)oSH`2nJE_$KX%my{+F&RA%-EL7du)7Mh>e zgaaA#EWS4!(ARe@Te9kWe5u#Wi!zy6Spn+VU3Y$TSUPhSoB^I<%YAn4tUyYJF24oG zbNfG7Q0#yNOC1F&B5HJN@OLZBR=F6%R+Q~{_+Wx2=|IW7!X44psi4tozj|h1EOsqZA9;$cl0Y*FLN_UdEtg0EzQgR zz!wX-Q3~#7O8}x}*OlYt-ciiamaW$bzT%(`3qhuubdz^pzoUXvbl6D5wb#fr zG{oWLJ8vi?5Laz4>D7l1XKbs5QtTP~p=)JTRo8XhXc{}`iJmzzhdHy`(Bk+1`SBl4 zRWrtV*(2sIkf_8VbIYfxq4@8m9iCtH3_~7d1bW-to6Ff`P3l~iaD-+!f!vQJx8=NQ zcrX`gUb;spMEqnamK%K?LV^@G1m~tAe$%qo?d*S}RKaNTgDP44by=GMRFN-h610kO z#(>Mr11`IJ^X9}i({*lI85|7{-=!YRfj>-LNH2j&$1YvW%wzUpR3apf&Ao+o2rNVG zeU~rxIxC=vM35zaswH|^fwH7H_@m_icxUFwZwK7RW7>S@*|Rw{Be581 z^UUi%Fq;Gw0ernhI;g?7k~Kv1EGXC3dw|-zB=0G<$+B8RsHu$C>|G6x8V#GUch8;< z>f^T@1#p_i(rN*xmNy?piKD5j>hWH%({hdAW_NRPcHx&~%pKg^n<10)U)G~7)}io6 zBJG>jc52bgRp)k~LFz5B!wmw@(>nQ%>CB)0&|qUE=?Ix*&7?__f+;!#IZhQ?kd48H zk0(5?^0Dz`kF)LV*>=i^ah&s0(X+}LQjm$DQ~rbXL9V1#$1DyPoqOC*kKjuL8G-jm zETD(c5Aw#L@2+79K^eS{_%n9n7vm@)>yGTh@RRj@q-1*CQmXiNzT@z){WaZj?8NzP zbcGax-Mi{t3kSS*Jt0b_J<> z2(rF?Y*((A|E-#vl~29eJ%1=T%db@&cAxV!yzHfH<%gYCOy_Dxp`j$v z1V7m6TI~(NTq5QgEfps@?lfWO$syOsgQmULu_+^};hPi+)rYS*Njv}+L7CmUf}gKOlg}?Me##% z1YsLms-W-+e#qcav7gG_2o7@j6}tZvf-b)c3m~;~Ms^}|f(2WiXd7W^iHgxz`41nQ zpM7w^oRbI6RlRx@8+shaY@G!to9t&Z5gu1>U+Gcj1)C$>8WFBUYFBd`D_{7?d{wJb ztaD@yg*%7NklK__|1ga97bhEw_MV7RBI7}4uiBYnnb+>n_blr8>myf^(MAf@ltQMQ znm{NEZAD_`$rB0pGv8b@e)+BZ%e!k?AF4<|eWT%2jB#>@|nW*=7{ zJ=b+dQ}JSyF%VJ)(E0sf@}iE@h7!6Jj?ub!_0tu7+aohU?3cJ^{D!rd!L7|ob{|`O zq6YrJisQ_G_85N*Ep1 zecw2*)o&OS{N3}?m4>rPjb_Hq7q<+Yecp#2Pzw^S2p9*YZ+~CQE9_WbVK)9Xh%Wmr`IR_YfYkV>CN)He0lWZ!CkmY6!1$y z$Rs~%V>TgX6{GJuPy=L8{(r)md%60EafSCiI{AbF~WOdZ!Sd*uWU`RctxND+j z@Cj0>j6VS2$P~94YwCMk`5k%ImsCZ5qClM9412a{_3a{6a^||2_y680)LtSBLs0t? zR7X&1pA0Of{U7a}c~sA9+xCCvZHSE`5j!%~MoESwv!qaI5RoK9Dnp_uW!s4~Y$-(= zR7isgp_I^8TN9OJ2qj8o2$i{>&y{^o&-2f_-t|8Jy=&cTxwrg&eTVBhuk$?4<2cSm z*{p0w-%(2j=bmqc{W45V?fk69%5!frX&#Pvu$YPyjnI?zeKnc!aI=M zNy}i?c*-O!rbOd!PVm(w2maaQyR&L|#+JB;-ABn@&0os32v=73-&7l(c6{ohVDe{| ze{calNQoX8=TgVcombQKx5>Hr^IVJWWGS z8~wdbDq%ujg#)5bL_2d1Cj?4T29tT8{qS!sL#P++B|x0R%tyE46_|3CF(L*~8e^xG zfxHUIw)+!{j1VSLJ=SvIIN&x{q;A6aVDsEuSrQ0o`*BJx#;K9af}afpDf}OWG7*4K zXaz`RM2CX=Z*d6}cqkGT zL^lm2Ty90?iQFr#?PD5T?;CwDGx~Z4X6o`C&~my)R6G)%L~^cqeUztBWGO#m`AWK- z)id5kK+ocI=*m{$?8hAR{!0zILA~JPrA+dq+wqgzj=H-#R-yc*6<3XIaPY$qOkohl z_xcTMx6$@keJSJbwjoGzpRliV{=HUc%Y>+QH8mgtQV;BNLxO&|bmIbYpwv62(=;`6 z*9`Qq=nhYF{wy%i6|4KCfu*6CNYi^(d^5oH(u514ZNcu18>GltZRUUIgs&5Rg+qFR zn%$A0_ir*KN-pA{P%qt$6UtB^%5c}_0hrm0{!<1iC!+-oUx!SLww`BvO7uo$wpQNg z1Uw>S`_PDY9<|eUj2wTnYaBEI;WF(0+nJoIsw%0o^{B3dmnHkUG%OJ?&i%KJXw{qL z>ggT{cW9eS3uDBT#!tJRq&sUo)f6OYHa&H}rDz`dMf{_AST9C={j+(vXZO_4ZeCNH z-==@?ZP-y{bs{qDwDhRUTg`&a$L5d)mp-vw_?kxj&n@?w3vz+vCD$sHEg!Dz4zr{8 z#Yu?6uwB})V$u)kq=uW3X}{daw{^42#E!7FZB>pX(td(D(>m?qRXQMI9(?Nbn;AKDiX@#}Cj-!}laK$&Ap4Z1 zvB_N7d&!7NHG=T!Q#>$d7Hh(2*KR`ojh~moPf*wBcgARe^mrw+BveEIvp zIdf<^i_tp0CGQ&=R7Ra5$K3(6nOw7u-aHaMSoRF)Yxte*A{?PO?;`m$rp?LT4-od&)7j|QT#GBz=Rn>E{s zZoq_lA4$}62ddjBdUpv83etvUbVGkVx4q1&%+sdZ7I-5*=WeL2_;=;wmtgpZD#=06 z&W2`Lbcdv61ZZM;g@fW0#YWdACL*`VEtW4Ad6RC+^z2b_S2yNQ+51<6maSfE$#7-m zgXre;B=EwP$*J{>3qIG{r`BF%Ee1DVWmy-w`8>GIVyOdn_d$ai_2i$r%$n#uyacMm zg)vbLDu)2fOO^#GC{-o-9#1;Ib@tv~yS)#H6^e zkvqEcw3#aqO1nS^@u-PcKJ$(P)f#$KZ^WObjo7~E(qb@LPKU>jF2pb1ea#!!Fc@_X zbq}4`5$RoJPStJvZymyH)yJ?oxZJLJa3+1A1ug~tZ$Gc7n1SD)!K42WNs1RXXAU4u+4|{x zOkv6&3r@m8HL3fqI?t?Wg_UpLLt9+$-)S*DPVLnv!gZ~I%#tPx=v3zMExJbUzHByY zvY6exg!UQwY8`r>yz~qA9^ndk;wtgeCLpMBFzS7+6Y2l0l^8wyW}Js3={ck z#S6dD5Fu4>e0%Bq{gdH^q&dACioWH2Q_c?phUdHBs?IcWQ@f+$_u^60 zTgE)WuxTJ~Fy-jaQqE(fZ~nm>WhwQQ zD7-7pzTcu7Z4q+tf!hJ4MMK8cJ8as}tVSmiFi7cFHHZ^9Vja>y`=6T6Vvxng-F|sE zc7OoKxsGc5__1uKLazRgUfhb-|Iv#pdiDu!BgR60ZY`g?(D<0k15ybdR_= z<>yH!GE>w8Zy%VXWMRBViVxKAB0ZGW|JpR7DKSD<ByAh7}{h(QsVF^i+-As;j=mXoDio8Bgm3WAC`Nd-rv- zbCX5#$MZ3u_5YGefy| zy8)F!45&@cvNZNa@K18`OHf`r>GFx^P-4SWT#~r_&gIteChxeLrNhPM6;od&4HUL* z0~NK6QqZ*y!=DcAi1buxlTJcf$8>?YL`&h0$t3T7q*S6cwzA%#)jIxJC7rPaHe3f2 zH0j8T29vW%>Q=#(INZA5OVxG7RhI!Xu18M+h!E_>FZGE{Eqf-38yYNbD4HaHc>b~e zSYmNb>_v{Fc_V|yvrP5Osvx5%_Am9H{nxiu0$~|H=1OG`+9hALv%4p3~Q>PTEo|b)FJVFl$bu(eV_f&7CaSR70JjmXl+pm`1T1O(G!kSBs zG1qs$stF6PtqIPx7=DXdk{z4m_PyRhR0+cE|FYqek2zd(My+^gUdxkLcY<8nfl>6h zNB#28UaZMa;)!n=f3yc>1zfkwkhmZ`{rW@7t1KR>EayWP`b&~drsYGJ7W?B>En$VL zc9sZZEP!@D5;@3!y012i$JFe`@APgb9FGoC0ZAmZ3f|G^|65utn!{EeRBQv-P8}tp zqlWlI`p0{ubt}7s8R6ThtQ2Trkq-A`Rnl$F#fC)nR5lL$h)X2y9MaF|mJZbxx?y8G z)?D_4U(L>SL^#={weNT3N5bIkE>{pHa71uJet2Uj7L_o>0pfzf`QJ!YMFXHLzzf4-eFWwO}x zv&2^P_U_^G?q>hX@JW`LQ3dJaxLD~n^f&Xd+USlj4;iDGiSTIA{Rad6HXX3^uH~@b zOY+!GB8-jzng$s8)eZhc09L>m3_}s92AzSf1vvyGj_!G9F*HU&4AX%*12;ir8^T+^ zbwR2KBXGgV;!pA{n%;nvV!jA~P-mc5r`}eDMgQRu4;@elzk$}G?mLnV=>zq`Vi}4G6%3%W zq@~@jR>t}O5<)Fs*?PlmV+m!pnDubYz1?3J!qhj&Dm#c5x&SFO?gTc!fB^{3UDFrf z95GS|eRvOFONPSFTH&1>dzx(H|sGKJwVOvOD@=6BAS1qI5n!zd$Bdj z-%&!i-per#RO=n5gbJkPUM4d5|5#$N0J+B8BwSAURna^mb{02h>i^gOo(`S^WBq!rx zol>NV4dRgMYR$_sR`E_4x=AtfYUp-Z@1s4~rK%YzkY|XSoh0Bw&oGYeBeqP5kU+i9 zsE;=kJJLi6Fig0;S1Z3X$2tx7z%p zPjE>uIP$CyiUmF(8n_2+Zww$CLVjQpMG=BJqkPTE%hM$?tBn@Ru5$_^;v%=L#Z=7Zm#m8Rd%TP_Eyw-+g-3*0@K5W_rMF84_XWg*$!Y8lcXR|q z%(BVN2S$eJb8b22$nP+E5PtY@6f7e_6oqMSxwpF0s!cTH&tlQJttNDb$%AkdHT(Df z^w_y36m5OVDET{1P9>uye$22f(H`O&4H#LUoHMutyrvY%qD>WD0Na@wk|%4}gvT_U z&y}i5^0tV(5Xv%}l2bn2x^-)WOut+nj5TqdWtWOA2tRkeNv%=Tp$T;rKL?vFLnV^* z{vPr(_I~;h-WnfbpQf|V64}uP4eWAD5AnPgaC1^OC|R%p2txb~+7p3)N!+k@l8V4l zuOxDM7_d&D*3c=|9hVW!ykmPnq6A6*wv0SNuu;W~?_H3iVzU)y$_UAWFDrz)RG z6nqivrh0m(7c_eEg?ssw0jgp_Lk?18uE#PYQb}!JxQ8DV5eH`z1A-JO(PCm^{t{Ps zpEo`uY6Ap0v65)$8&XOVBg4dPCr#t>=g|NgH?8@;m49^E%3TZ5m0uKJ+03K7^Kzxj zySa1c&5MnUoVDbXo`JRX$+pjp5uYnVKL9aW&tJ5fkCL=SXjsH`h;aUbwY2(+tZB|I&azg{({^V_c4!&t@Q zlu7VyCy^YxOrP~7qXUyP_GxeSkoQr-FC8ZA`BK$Y!|>m`Q<>$-I@#s;rrfNjXI9;O zN&4@WvaIYwilk>}=5{yv@+=d7p9J3uRddTOt43$31cZeZ_MajNf@{5)MB~V|H@kx& zUoAiW(|TDKnNF)lduGiv>mrHh$C8jpu4VJ~B@%ZZgZo^LWMEWM2mYAI!{HBG?;E@q z$$eQ5dHzUJ?KYJ^R$2Z35B@Jc9G3*~$SVo~RbwCq%lY+}mJWU-98%E%npNG0AMi4J z;HJj)S`o?myfgPPWX`RIE-v4O`?x+oq-`@TEI4?+rDxez*?pEv<=gXJZZiG)#R59A zY|fNv_Vk?1j2XN{8uU~m4khp7)!sKmfC6G-_SU&`&q4FeJWbn{!J{u(Lt6CTP60Nn z*rVv~xU>&z!?vE9q7Fl2bS^7Se{gkm4Gao84QSA7WCyukrs9h1Sem0JPP|xH(@T&L zdM0X%)pXG$+*&nksbPnuKEqX6c=wc)m1X4QV(I1OY1~FQ!Kd(Sv5i$$BWM)WKsfeM(a0QqS3&+)?$;GFLW;tcWf#*o%eIl6=Mw#rTz{_6o2|H`U;1MP96pO;_- z=_H0GXKqf;=|hI?qz)>J-@DN~H}C^z{*rq|(QH+sqYoG{qg;$rN`pvgmVvk1{b@8K z>zVkq4RUDXDK9L1a)u2XRw@!Jy^a$!+kT{!GUnh>X3GrfsXgpeJGsHStJ#63pAn*q z2jb=BWs?K{MOsG2dZtoD<&WPL$Rn1Ln-KG`W#FdtL)^uIw!84XVyznVVfFB9AxVmz zxuj5R-5g;KGi%AeFr%xwva&A6#l6lQ1(y9KB$4)O# zc%sI>{nTe5RgsCdyJy>aE|VL-X8-4C*@!c%rNnbwhJ+dVPLf9FI}!hPvFc8YII`MT z7>kcb7>GH^93!T4=KM~U7w_A_NlLtx_0qH-N=Q@^0OmF_$=)QVU3zEno+o$-0v6YZ z5TytaNrLzYM*%Ob`UE1Z-2D82ycdS+*RM~onq>DdnwUMwaQw9=ZNIJvBb?euE7bpq zq@po&czX9~*PP=oOC%l0a|V1f-m)dR)IjnmLd4$Xqm-3PI`qgbM=4^pO78N3?6LXq6ute_u$-I zc-JLVzZRL99j{f3`l1yLigIKaLDRbmC8*w-tI{``| zgjJ}T4bcdsPRAaZDp^>5NTc`1j{ud*eE+kl)p7z3%e{502v|lj^vdctn8GFc>1PKXJ61PwF#}A<_=NU`oCqYi?AI6lvqF{>-4)@~eQh-l zRv77#zArr)uWJaX@_d`d@KEInY)lfirsHWKVDW-Jt}Wz)=V6 zAw>9JBH-Ss*vcCVL`I1}%1cZPj3KN}8$WK9Y1@4sg-aKA;eyeQ@-3c^s_^`*ZiW*a zD~|~5yqIC5Bkm04pkM+89yxOC>*KCHdKjTYoK_O9hP=a-YCWwcY?tQvA*16A zI!nw4dDuRk&C2ezO=r$bBk?GrlalVZ*sg|DwX^w^bCE-Npe^B;*8_W6mmr02aGZTw z?Fhe`PS?bqI2K4v`=A_Vwu!#}ow==dpFiA~s9ttuh{m@0kleQJt?6=XnAolbxLW(A zh8{g?mY7O~-b5A|e0!rH9f{dRiBsAciBl(H0M3$2*agFNSXo!19iT$Ty>>`7Ckf+! zSm^j~d$aJQn4iUQG_Aj^gbnXrjd7ngVUq~z{*snLimzLJ!liPpsjh?tgRcMcFycr6qeBQ8)-PVy_Q|*AMNGUjqz7H$ac3(wI>83HA_uh^gSK; zA*10&_b-p0wwzKB3sBAav@b zhv}$M(%z)iE9#)>yn~uDcF@!F>-;{SM4h>WC|Fu8tLc=KDnDdMBAeq@?KT_0+v*l} z`HSbz=lcWe+1htlDARV^qOe&8Uxu`|z!irTB_*X|fMW9AvuF;3#axq9z>=eJO`!^6 z=n6g^`<>IzoihZ@#b0#dN8!^`_xQ>sL>{r^-b;lSjGs*Z{`HqKzb6cKZ8Tu!_KouC zm{*8G&;J4>jcM=x>|0lS@*t+At9)zWTvB=~>VR(>QJ+uyG^xXVzpRRuW+_D^=B_x6iHYNU#z;6R4&W42ND@ z)|SuwKT6*t26K9rYOdeecKAAqiSAA8Ft!H=(wUM$bV-Hb42tSVlA~Rd6^?Zi`*Vi8 zU`exxQXnD6qitGoFBNJ0J>Jw^e7&c&e5!hw<`{>U(ZEro)8%=yl8B!6ncug6{`xhK z?MM1`HQpiX#*IdtN^Jnuqyl;_Jn$oj`EZfyoL5s`CmWRT9|v$~HRB7yJ(rvq9Vrge zyjO_dVI%7EkV_5fqAB&8G#D*;d$!J2I`h<=J&%&e@t;j&(*Jo}OjL?BI8^ zwCz&9lWmAo_Ok=I0c%d*Iv+tvDaEVOSK*VqSnKl~8c{}wvWZ)z^jW3Ym25IH=xrfY zV7S5rgq<2KiplJBBJCIEcV2)E$Br3IkqKe;E@_5-eN9J2@xDF{VIoEmBkm%om+K+e za8sY29o&hm1^wa#hjO*sno*R)^Znrut8<=E6uSap29Rtw(E?ItyDoaN!66dLxyK_1*~Df&4P|%9}J@ zw#*mcuh_sQz_5kKCktB6JpoNXC>S+;x&@}|vG9^7FicnYS)~EODC$6c7J&g4!%6;m z?u)IZJ3qWcGM^|+i`f6*3S|kGp2V`YY_9*-X(tV*v0u#EiQA8Pb~=1_vG^gkAM&;3 z^KG{}vc6JgH=P1;vY~4wj%7sAroV z&|4rH6{VIqCIO?zPOWME{l`3{4#@+!I;??2?Ib}+%}>p zU?toIbjd$`>vs>2T67|pU**he z?7l6{ugs_y<>!$X3cXnr>pYu<{kRa9y;X(G?fa&bv#+PT&HV9HZ*|92r%!*1r&o%? zEiviFfJVI?9ny8)w1BL#_DLBx_wUzF4n%IBq7`jc`j$I zX-f+e@O-gPebH~W|GUDeZ!d?ohHSd3T638UWo%89g%Q(u6mD(S2pt^S-^VXx5vAsG z8miUJeHUvgcxEZ+(0B|Kiw_YYM!`!FZKqZFPAxAK)H(Zb3#}?0E@CG|vSR4hpmsaP z4gErI@9srL*2tNTzLk7$Sbav1E^AC^)i(~h;tzsN2U zaxc)ig+3cgqaq`1K5x4=MTCxudmbBaam2mco{yG7Q3nEbP-doE%5=77_5B~2lwZwp zX2ZZ+QM{F|&^$|kcq0~vncLZY=;ctjwzm@z5UtG z0Y_=0ins$A+92fvtgm4@>PKon(BNVTou-4K#J)la56vfQt^+uBL4KFJT|`AcBlNh% zqM@O?TvoT`WD^32V!DX0O#??JiUCt143JA7Q>wa+)rQuJYT{2Uv}VT^mT$--*f?qH z!zfHcsl5E3*XK1E-0dX-{@q(1c~fXXjL{n^!WWMxND&Ni7oVk|D)y35ZUiVZ9r(7U zW?eOlMjzcr!Uv1XiZ5@h%Po8UEvTIiXZv5nT{}mN5Kmu!B+J3(!MT%)8_4#9wk?7_ zwRg>y$%Cp3PK(57dds_B&`xqIH($JqF6Xa`RIfV{v>!+ z+so0|q%bLDO6Vd73#d1WIxJ%>c@lRVVLN?zcYw8c63?4NMkC1Oj8s$%o^<`J+4*?{ zS^FHSAl+6%*YnMj8!`SfnXCCHtRbZ*0VE{**) zNj>luVeX#!7hyv57@U29uCCgqXPS&L4|8jA7Lp8+-)`-&mN%LI8U=&HR1DS%kB&?K zybUo;b;#Vu_?r~dejZy}Zrnh$NR__?y;!H1ie<&?)LH_wf9zSa>6?UWIfCqH2a8{r z#bjouN6wg<0YS;nWy{Qx*#ajjy=;C~SE-0R_zqr!1>u=r-%JJgn9qqQYOwX|V>o4wi+8zqGzA^rzdle<` z`0Cr?Z<~+PPL+c#Zd`b14c+@27{!J^av?@O1%86TUBaJm>T;lD&u5lw9Ik}~}q&n{4d z(__gH0HXm+P#7@`>#W@S)QB9q`6{S&t>=%&M!-9>r73Y9?h6@OUp;7)avqe_Hr_v; zv@c6Vt|HJ1^lO;tMWT_hp_j=4lo;>pVDLZk+It#TIcC9;ltzuZQ!wdiJfM}|b394U zyq6Bvbwo5~y>4Az<>pc2#~T91CuqN)Uo3!5A`_Cs1(P0cJ1o?afY^r)ofv3;`MOnR zP5Qqj!JqFLJBA*4D9yQ!<42W%BKso~sDBsw3Yd`FOcjnm_)JkoV@+p)xi_@% literal 0 HcmV?d00001 diff --git a/gnu/llvm/llvm/docs/re_format.7 b/gnu/llvm/llvm/docs/re_format.7 index 96972e72c88..0c0928716f4 100644 --- a/gnu/llvm/llvm/docs/re_format.7 +++ b/gnu/llvm/llvm/docs/re_format.7 @@ -1,4 +1,4 @@ -.\" $OpenBSD: re_format.7,v 1.1.1.1 2016/09/03 22:46:59 pascal Exp $ +.\" $OpenBSD: re_format.7,v 1.14 2007/05/31 19:19:30 jmc Exp $ .\" .\" Copyright (c) 1997, Phillip F Knaack. All rights reserved. .\" @@ -35,7 +35,7 @@ .\" .\" @(#)re_format.7 8.3 (Berkeley) 3/20/94 .\" -.Dd $Mdocdate: September 3 2016 $ +.Dd $Mdocdate: May 31 2007 $ .Dt RE_FORMAT 7 .Os .Sh NAME diff --git a/gnu/llvm/llvm/docs/tutorial/BuildingAJIT1.rst b/gnu/llvm/llvm/docs/tutorial/BuildingAJIT1.rst index 00ad94aa08a..33d36896cbf 100644 --- a/gnu/llvm/llvm/docs/tutorial/BuildingAJIT1.rst +++ b/gnu/llvm/llvm/docs/tutorial/BuildingAJIT1.rst @@ -174,7 +174,7 @@ The ConcurrentIRCompiler utility will use the JITTargetMachineBuilder to build llvm TargetMachines (which are not thread safe) as needed for compiles. After this, we initialize our supporting members: ``DL``, ``Mangler`` and ``Ctx`` with the input DataLayout, the ExecutionSession and DL member, and a new default -constucted LLVMContext respectively. Now that our members have been initialized, +constructed LLVMContext respectively. Now that our members have been initialized, so the one thing that remains to do is to tweak the configuration of the *JITDylib* that we will store our code in. We want to modify this dylib to contain not only the symbols that we add to it, but also the symbols from our @@ -204,7 +204,7 @@ REPL process as well. We do this by attaching a Next we have a named constructor, ``Create``, which will build a KaleidoscopeJIT instance that is configured to generate code for our host process. It does this -by first generating a JITTargetMachineBuilder instance using that clases's +by first generating a JITTargetMachineBuilder instance using that classes' detectHost method and then using that instance to generate a datalayout for the target process. Each of these operations can fail, so each returns its result wrapped in an Expected value [3]_ that we must check for error before @@ -320,4 +320,4 @@ Here is the code: +-----------------------------+-----------------------------------------------+ .. [3] See the ErrorHandling section in the LLVM Programmer's Manual - (http://llvm.org/docs/ProgrammersManual.html#error-handling) \ No newline at end of file + (https://llvm.org/docs/ProgrammersManual.html#error-handling) diff --git a/gnu/llvm/llvm/docs/tutorial/BuildingAJIT2.rst b/gnu/llvm/llvm/docs/tutorial/BuildingAJIT2.rst index 1f818d94566..574cdf1f599 100644 --- a/gnu/llvm/llvm/docs/tutorial/BuildingAJIT2.rst +++ b/gnu/llvm/llvm/docs/tutorial/BuildingAJIT2.rst @@ -170,7 +170,7 @@ can be implemented. TransformFunction Transform; }; - // From IRTransfomrLayer.cpp: + // From IRTransformLayer.cpp: IRTransformLayer::IRTransformLayer(ExecutionSession &ES, IRLayer &BaseLayer, @@ -250,7 +250,7 @@ each function just passes through code-gen. If we both optimize and code-gen lazily we can start executing the first function more quickly, but we will have longer pauses as each function has to be both optimized and code-gen'd when it is first executed. Things become even more interesting if we consider -interproceedural optimizations like inlining, which must be performed eagerly. +interprocedural optimizations like inlining, which must be performed eagerly. These are complex trade-offs, and there is no one-size-fits all solution to them, but by providing composable layers we leave the decisions to the person implementing the JIT, and make it easy for them to experiment with different diff --git a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl02.rst b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl02.rst index c07c3ab192b..9091043e6a0 100644 --- a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl02.rst +++ b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl02.rst @@ -314,7 +314,7 @@ Now that we have all of our simple expression-parsing logic in place, we can define a helper function to wrap it together into one entry point. We call this class of expressions "primary" expressions, for reasons that will become more clear `later in the -tutorial `_. In order to parse an arbitrary +tutorial `_. In order to parse an arbitrary primary expression, we need to determine what sort of expression it is: .. code-block:: c++ @@ -718,7 +718,7 @@ Full Code Listing Here is the complete code listing for our running example. Because this uses the LLVM libraries, we need to link them in. To do this, we use the -`llvm-config `_ tool to inform +`llvm-config `_ tool to inform our makefile/command line about which options to use: .. code-block:: bash diff --git a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl03.rst b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl03.rst index 50e8c44bfc1..32472e3a482 100644 --- a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl03.rst +++ b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl03.rst @@ -20,7 +20,7 @@ later. LLVM 3.6 and before will not work with it. Also note that you need to use a version of this tutorial that matches your LLVM release: If you are using an official LLVM release, use the version of the documentation included with your release or on the `llvm.org releases -page `_. +page `_. Code Generation Setup ===================== @@ -90,7 +90,7 @@ detail, we just need a single instance to pass into APIs that require it. The ``Builder`` object is a helper object that makes it easy to generate LLVM instructions. Instances of the -`IRBuilder `_ +`IRBuilder `_ class template keep track of the current place to insert instructions and has methods to create new instructions. @@ -549,7 +549,7 @@ Full Code Listing Here is the complete code listing for our running example, enhanced with the LLVM code generator. Because this uses the LLVM libraries, we need to link them in. To do this, we use the -`llvm-config `_ tool to inform +`llvm-config `_ tool to inform our makefile/command line about which options to use: .. code-block:: bash diff --git a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl04.rst b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl04.rst index 24c2b0f1755..78aa31b30cd 100644 --- a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl04.rst +++ b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl04.rst @@ -98,7 +98,7 @@ LLVM Optimization Passes Due to the transition to the new PassManager infrastructure this tutorial is based on ``llvm::legacy::FunctionPassManager`` which can be found in - `LegacyPassManager.h `_. + `LegacyPassManager.h `_. For the purpose of the this tutorial the above should be used until the pass manager transition is complete. @@ -142,7 +142,7 @@ for us: TheModule = std::make_unique("my cool jit", TheContext); // Create a new pass manager attached to it. - TheFPM = std::make_unique(TheModule.get()); + TheFPM = std::make_unique(TheModule.get()); // Do simple "peephole" optimizations and bit-twiddling optzns. TheFPM->add(createInstructionCombiningPass()); @@ -275,7 +275,7 @@ We also need to setup the data layout for the JIT: TheModule->setDataLayout(TheJIT->getTargetMachine().createDataLayout()); // Create a new pass manager attached to it. - TheFPM = std::make_unique(TheModule.get()); + TheFPM = std::make_unique(TheModule.get()); ... The KaleidoscopeJIT class is a simple JIT built specifically for these diff --git a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst index 11ae79de301..a55cfe277de 100644 --- a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst +++ b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst @@ -213,7 +213,7 @@ Kaleidoscope looks like this: } To visualize the control flow graph, you can use a nifty feature of the -LLVM '`opt `_' tool. If you put this LLVM +LLVM '`opt `_' tool. If you put this LLVM IR into "t.ll" and run "``llvm-as < t.ll | opt -analyze -view-cfg``", `a window will pop up <../../ProgrammersManual.html#viewing-graphs-while-debugging-code>`_ and you'll see this graph: diff --git a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl06.rst b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl06.rst index dd3a3f17137..87c7a3753b3 100644 --- a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl06.rst +++ b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl06.rst @@ -113,7 +113,7 @@ keywords: return tok_identifier; This just adds lexer support for the unary and binary keywords, like we -did in `previous chapters `_. One nice thing +did in `previous chapters `_. One nice thing about our current AST, is that we represent binary operators with full generalisation by using their ASCII code as the opcode. For our extended operators, we'll use this same representation, so we don't need any new diff --git a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl07.rst b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl07.rst index a30be9894c3..d7abeeac805 100644 --- a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl07.rst +++ b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl07.rst @@ -399,7 +399,7 @@ the unabridged code): ... This code is virtually identical to the code `before we allowed mutable -variables `_. The big difference is that we +variables `_. The big difference is that we no longer have to construct a PHI node, and we use load/store to access the variable as needed. diff --git a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl08.rst b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl08.rst index 82776006a80..16b45323154 100644 --- a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl08.rst +++ b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl08.rst @@ -23,7 +23,7 @@ machine. To specify the architecture that you want to target, we use a string called a "target triple". This takes the form ``---`` (see the `cross compilation docs -`_). +`_). As an example, we can see what clang thinks is our current target triple: diff --git a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl09.rst b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl09.rst index 4cdecc3ff13..0304c8ec813 100644 --- a/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl09.rst +++ b/gnu/llvm/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl09.rst @@ -165,13 +165,13 @@ DWARF Emission Setup ==================== Similar to the ``IRBuilder`` class we have a -`DIBuilder `_ class +`DIBuilder `_ class that helps in constructing debug metadata for an LLVM IR file. It corresponds 1:1 similarly to ``IRBuilder`` and LLVM IR, but with nicer names. Using it does require that you be more familiar with DWARF terminology than you needed to be with ``IRBuilder`` and ``Instruction`` names, but if you read through the general documentation on the -`Metadata Format `_ it +`Metadata Format `_ it should be a little more clear. We'll be using this class to construct all of our IR level descriptions. Construction for it takes a module so we need to construct it shortly after we construct our module. We've left it diff --git a/gnu/llvm/llvm/docs/tutorial/OCamlLangImpl3.rst b/gnu/llvm/llvm/docs/tutorial/OCamlLangImpl3.rst index a76b46d1bf6..0b37ecd5ffd 100644 --- a/gnu/llvm/llvm/docs/tutorial/OCamlLangImpl3.rst +++ b/gnu/llvm/llvm/docs/tutorial/OCamlLangImpl3.rst @@ -59,13 +59,13 @@ parser, which will be used to report errors found during code generation let double_type = double_type context The static variables will be used during code generation. -``Codgen.the_module`` is the LLVM construct that contains all of the +``Codegen.the_module`` is the LLVM construct that contains all of the functions and global variables in a chunk of code. In many ways, it is the top-level structure that the LLVM IR uses to contain code. The ``Codegen.builder`` object is a helper object that makes it easy to generate LLVM instructions. Instances of the -`IRBuilder `_ +`IRBuilder `_ class keep track of the current place to insert instructions and has methods to create new instructions. @@ -78,7 +78,7 @@ function body. With these basics in place, we can start talking about how to generate code for each expression. Note that this assumes that the -``Codgen.builder`` has been set up to generate code *into* something. +``Codegen.builder`` has been set up to generate code *into* something. For now, we'll assume that this has already been done, and we'll just use it to emit code. @@ -522,7 +522,7 @@ Full Code Listing Here is the complete code listing for our running example, enhanced with the LLVM code generator. Because this uses the LLVM libraries, we need to link them in. To do this, we use the -`llvm-config `_ tool to inform +`llvm-config `_ tool to inform our makefile/command line about which options to use: .. code-block:: bash diff --git a/gnu/llvm/llvm/docs/tutorial/OCamlLangImpl5.rst b/gnu/llvm/llvm/docs/tutorial/OCamlLangImpl5.rst index 34d2dbb4c4d..871eb05df37 100644 --- a/gnu/llvm/llvm/docs/tutorial/OCamlLangImpl5.rst +++ b/gnu/llvm/llvm/docs/tutorial/OCamlLangImpl5.rst @@ -161,7 +161,7 @@ Kaleidoscope looks like this: } To visualize the control flow graph, you can use a nifty feature of the -LLVM '`opt `_' tool. If you put this LLVM +LLVM '`opt `_' tool. If you put this LLVM IR into "t.ll" and run "``llvm-as < t.ll | opt -analyze -view-cfg``", `a window will pop up <../ProgrammersManual.html#viewing-graphs-while-debugging-code>`_ and you'll see this graph: diff --git a/gnu/llvm/llvm/docs/tutorial/index.rst b/gnu/llvm/llvm/docs/tutorial/index.rst index 8aa45184902..e3c50f04245 100644 --- a/gnu/llvm/llvm/docs/tutorial/index.rst +++ b/gnu/llvm/llvm/docs/tutorial/index.rst @@ -51,5 +51,5 @@ External Tutorials Advanced Topics =============== -#. `Writing an Optimization for LLVM `_ +#. `Writing an Optimization for LLVM `_ diff --git a/gnu/llvm/llvm/examples/BrainF/BrainF.cpp b/gnu/llvm/llvm/examples/BrainF/BrainF.cpp index 2937f8c6cc1..067dad13765 100644 --- a/gnu/llvm/llvm/examples/BrainF/BrainF.cpp +++ b/gnu/llvm/llvm/examples/BrainF/BrainF.cpp @@ -66,7 +66,7 @@ void BrainF::header(LLVMContext& C) { //Function prototypes - //declare void @llvm.memset.p0i8.i32(i8 *, i8, i32, i32, i1) + //declare void @llvm.memset.p0i8.i32(i8 *, i8, i32, i1) Type *Tys[] = { Type::getInt8PtrTy(C), Type::getInt32Ty(C) }; Function *memset_func = Intrinsic::getDeclaration(module, Intrinsic::memset, Tys); @@ -98,13 +98,12 @@ void BrainF::header(LLVMContext& C) { nullptr, "arr"); BB->getInstList().push_back(cast(ptr_arr)); - //call void @llvm.memset.p0i8.i32(i8 *%arr, i8 0, i32 %d, i32 1, i1 0) + //call void @llvm.memset.p0i8.i32(i8 *%arr, i8 0, i32 %d, i1 0) { Value *memset_params[] = { ptr_arr, ConstantInt::get(C, APInt(8, 0)), val_mem, - ConstantInt::get(C, APInt(32, 1)), ConstantInt::get(C, APInt(1, 0)) }; @@ -440,7 +439,8 @@ void BrainF::readloop(PHINode *phi, BasicBlock *oldbb, BasicBlock *testbb, Value *head_0 = phi; //%tape.%d = load i8 *%head.%d - LoadInst *tape_0 = new LoadInst(head_0, tapereg, testbb); + LoadInst *tape_0 = new LoadInst(IntegerType::getInt8Ty(C), head_0, + tapereg, testbb); //%test.%d = icmp eq i8 %tape.%d, 0 ICmpInst *test_0 = new ICmpInst(*testbb, ICmpInst::ICMP_EQ, tape_0, diff --git a/gnu/llvm/llvm/examples/Bye/Bye.cpp b/gnu/llvm/llvm/examples/Bye/Bye.cpp index 6a2fea44d4c..4e39cd5c660 100644 --- a/gnu/llvm/llvm/examples/Bye/Bye.cpp +++ b/gnu/llvm/llvm/examples/Bye/Bye.cpp @@ -45,7 +45,7 @@ static RegisterPass X("goodbye", "Good Bye World Pass", /* Legacy PM Registration */ static llvm::RegisterStandardPasses RegisterBye( - llvm::PassManagerBuilder::EP_EarlyAsPossible, + llvm::PassManagerBuilder::EP_VectorizerStart, [](const llvm::PassManagerBuilder &Builder, llvm::legacy::PassManagerBase &PM) { PM.add(new LegacyBye()); }); @@ -58,6 +58,15 @@ llvm::PassPluginLibraryInfo getByePluginInfo() { llvm::PassBuilder::OptimizationLevel Level) { PM.addPass(Bye()); }); + PB.registerPipelineParsingCallback( + [](StringRef Name, llvm::FunctionPassManager &PM, + ArrayRef) { + if (Name == "goodbye") { + PM.addPass(Bye()); + return true; + } + return false; + }); }}; } diff --git a/gnu/llvm/llvm/examples/Bye/CMakeLists.txt b/gnu/llvm/llvm/examples/Bye/CMakeLists.txt index 3206f90d091..bb96edb4b4b 100644 --- a/gnu/llvm/llvm/examples/Bye/CMakeLists.txt +++ b/gnu/llvm/llvm/examples/Bye/CMakeLists.txt @@ -2,12 +2,18 @@ if(LLVM_BYE_LINK_INTO_TOOLS) message(WARNING "Setting LLVM_BYE_LINK_INTO_TOOLS=ON only makes sense for testing purpose") endif() -add_llvm_pass_plugin(Bye - Bye.cpp - DEPENDS - intrinsics_gen - BUILDTREE_ONLY - ) +# The plugin expects to not link against the Support and Core libraries, +# but expects them to exist in the process loading the plugin. This doesn't +# work with DLLs on Windows (where a shared library can't have undefined +# references), so just skip this example on Windows. +if (NOT WIN32) + add_llvm_pass_plugin(Bye + Bye.cpp + DEPENDS + intrinsics_gen + BUILDTREE_ONLY + ) -install(TARGETS ${name} RUNTIME DESTINATION examples) -set_target_properties(${name} PROPERTIES FOLDER "Examples") + install(TARGETS ${name} RUNTIME DESTINATION examples) + set_target_properties(${name} PROPERTIES FOLDER "Examples") +endif() diff --git a/gnu/llvm/llvm/examples/CMakeLists.txt b/gnu/llvm/llvm/examples/CMakeLists.txt index 863c12afbda..6d926d0bfba 100644 --- a/gnu/llvm/llvm/examples/CMakeLists.txt +++ b/gnu/llvm/llvm/examples/CMakeLists.txt @@ -3,11 +3,12 @@ add_subdirectory(Fibonacci) add_subdirectory(HowToUseJIT) add_subdirectory(HowToUseLLJIT) add_subdirectory(IRTransforms) -add_subdirectory(LLJITExamples) add_subdirectory(Kaleidoscope) add_subdirectory(ModuleMaker) +add_subdirectory(OrcV2Examples) add_subdirectory(SpeculativeJIT) add_subdirectory(Bye) +add_subdirectory(ThinLtoJIT) if(LLVM_ENABLE_EH AND (NOT WIN32) AND (NOT "${LLVM_NATIVE_ARCH}" STREQUAL "ARM")) add_subdirectory(ExceptionDemo) diff --git a/gnu/llvm/llvm/examples/ExceptionDemo/ExceptionDemo.cpp b/gnu/llvm/llvm/examples/ExceptionDemo/ExceptionDemo.cpp index 0ecb527f4ec..1b3ec7c91dd 100644 --- a/gnu/llvm/llvm/examples/ExceptionDemo/ExceptionDemo.cpp +++ b/gnu/llvm/llvm/examples/ExceptionDemo/ExceptionDemo.cpp @@ -792,7 +792,7 @@ _Unwind_Reason_Code ourPersonality(int version, _Unwind_Action actions, } #endif - const uint8_t *lsda = _Unwind_GetLanguageSpecificData(context); + const uint8_t *lsda = (const uint8_t *)_Unwind_GetLanguageSpecificData(context); #ifdef DEBUG fprintf(stderr, @@ -1959,11 +1959,13 @@ int main(int argc, char *argv[]) { executionEngine->finalizeObject(); +#ifndef NDEBUG fprintf(stderr, "\nBegin module dump:\n\n"); module->dump(); fprintf(stderr, "\nEnd module dump:\n"); +#endif fprintf(stderr, "\n\nBegin Test:\n"); diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/KaleidoscopeJIT.h b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/KaleidoscopeJIT.h index b7404baf1ff..adb6be43666 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/KaleidoscopeJIT.h +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/KaleidoscopeJIT.h @@ -49,7 +49,7 @@ public: std::make_unique(std::move(JTMB))), DL(std::move(DL)), Mangle(ES, this->DL), Ctx(std::make_unique()), - MainJD(ES.createJITDylib("
")) { + MainJD(ES.createBareJITDylib("
")) { MainJD.addGenerator( cantFail(DynamicLibrarySearchGenerator::GetForCurrentProcess( DL.getGlobalPrefix()))); diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/toy.cpp index b4605bae4ed..ad942d1e45e 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/toy.cpp @@ -727,7 +727,7 @@ Function *getFunction(std::string Name) { /// CreateEntryBlockAlloca - Create an alloca instruction in the entry block of /// the function. This is used for mutable variables etc. static AllocaInst *CreateEntryBlockAlloca(Function *TheFunction, - const std::string &VarName) { + StringRef VarName) { IRBuilder<> TmpB(&TheFunction->getEntryBlock(), TheFunction->getEntryBlock().begin()); return TmpB.CreateAlloca(Type::getDoubleTy(*TheContext), nullptr, VarName); @@ -1076,7 +1076,7 @@ Function *FunctionAST::codegen() { Builder->CreateStore(&Arg, Alloca); // Add arguments to variable symbol table. - NamedValues[Arg.getName()] = Alloca; + NamedValues[std::string(Arg.getName())] = Alloca; } if (Value *RetVal = Body->codegen()) { diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter2/KaleidoscopeJIT.h b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter2/KaleidoscopeJIT.h index efb19349e3e..28649ffe491 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter2/KaleidoscopeJIT.h +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter2/KaleidoscopeJIT.h @@ -55,7 +55,7 @@ public: std::make_unique(std::move(JTMB))), OptimizeLayer(ES, CompileLayer, optimizeModule), DL(std::move(DL)), Mangle(ES, this->DL), Ctx(std::make_unique()), - MainJD(ES.createJITDylib("
")) { + MainJD(ES.createBareJITDylib("
")) { MainJD.addGenerator( cantFail(DynamicLibrarySearchGenerator::GetForCurrentProcess( DL.getGlobalPrefix()))); diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter2/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter2/toy.cpp index 743d50829dc..136ae9636c5 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter2/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter2/toy.cpp @@ -727,7 +727,7 @@ Function *getFunction(std::string Name) { /// CreateEntryBlockAlloca - Create an alloca instruction in the entry block of /// the function. This is used for mutable variables etc. static AllocaInst *CreateEntryBlockAlloca(Function *TheFunction, - const std::string &VarName) { + StringRef VarName) { IRBuilder<> TmpB(&TheFunction->getEntryBlock(), TheFunction->getEntryBlock().begin()); return TmpB.CreateAlloca(Type::getDoubleTy(*TheContext), nullptr, VarName); @@ -1076,7 +1076,7 @@ Function *FunctionAST::codegen() { Builder->CreateStore(&Arg, Alloca); // Add arguments to variable symbol table. - NamedValues[Arg.getName()] = Alloca; + NamedValues[std::string(Arg.getName())] = Alloca; } if (Value *RetVal = Body->codegen()) { diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter3/KaleidoscopeJIT.h b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter3/KaleidoscopeJIT.h index add38fdb819..34c4b968357 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter3/KaleidoscopeJIT.h +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter3/KaleidoscopeJIT.h @@ -100,13 +100,13 @@ public: // Build a resolver and associate it with the new key. Resolvers[K] = createLegacyLookupResolver( ES, - [this](const std::string &Name) -> JITSymbol { - if (auto Sym = CompileLayer.findSymbol(Name, false)) + [this](StringRef Name) -> JITSymbol { + if (auto Sym = CompileLayer.findSymbol(std::string(Name), false)) return Sym; else if (auto Err = Sym.takeError()) return std::move(Err); - if (auto SymAddr = - RTDyldMemoryManager::getSymbolAddressInProcess(Name)) + if (auto SymAddr = RTDyldMemoryManager::getSymbolAddressInProcess( + std::string(Name))) return JITSymbol(SymAddr, JITSymbolFlags::Exported); return nullptr; }, diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter3/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter3/toy.cpp index e9505033106..d082e510e29 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter3/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter3/toy.cpp @@ -726,7 +726,7 @@ Function *getFunction(std::string Name) { /// CreateEntryBlockAlloca - Create an alloca instruction in the entry block of /// the function. This is used for mutable variables etc. static AllocaInst *CreateEntryBlockAlloca(Function *TheFunction, - const std::string &VarName) { + StringRef VarName) { IRBuilder<> TmpB(&TheFunction->getEntryBlock(), TheFunction->getEntryBlock().begin()); return TmpB.CreateAlloca(Type::getDoubleTy(TheContext), nullptr, VarName); @@ -1075,7 +1075,7 @@ Function *FunctionAST::codegen() { Builder.CreateStore(&Arg, Alloca); // Add arguments to variable symbol table. - NamedValues[Arg.getName()] = Alloca; + NamedValues[std::string(Arg.getName())] = Alloca; } if (Value *RetVal = Body->codegen()) { diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter4/KaleidoscopeJIT.h b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter4/KaleidoscopeJIT.h index dd6304b7a78..c87565737f2 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter4/KaleidoscopeJIT.h +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter4/KaleidoscopeJIT.h @@ -91,15 +91,15 @@ public: KaleidoscopeJIT() : Resolver(createLegacyLookupResolver( ES, - [this](const std::string &Name) -> JITSymbol { + [this](StringRef Name) -> JITSymbol { if (auto Sym = IndirectStubsMgr->findStub(Name, false)) return Sym; - if (auto Sym = OptimizeLayer.findSymbol(Name, false)) + if (auto Sym = OptimizeLayer.findSymbol(std::string(Name), false)) return Sym; else if (auto Err = Sym.takeError()) return std::move(Err); - if (auto SymAddr = - RTDyldMemoryManager::getSymbolAddressInProcess(Name)) + if (auto SymAddr = RTDyldMemoryManager::getSymbolAddressInProcess( + std::string(Name))) return JITSymbol(SymAddr, JITSymbolFlags::Exported); return nullptr; }, diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter4/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter4/toy.cpp index bfd57e621cd..e39e8a94d03 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter4/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter4/toy.cpp @@ -712,7 +712,7 @@ Function *getFunction(std::string Name) { /// CreateEntryBlockAlloca - Create an alloca instruction in the entry block of /// the function. This is used for mutable variables etc. static AllocaInst *CreateEntryBlockAlloca(Function *TheFunction, - const std::string &VarName) { + StringRef VarName) { IRBuilder<> TmpB(&TheFunction->getEntryBlock(), TheFunction->getEntryBlock().begin()); return TmpB.CreateAlloca(Type::getDoubleTy(TheContext), nullptr, VarName); @@ -1068,7 +1068,7 @@ Function *FunctionAST::codegen() { Builder.CreateStore(&Arg, Alloca); // Add arguments to variable symbol table. - NamedValues[Arg.getName()] = Alloca; + NamedValues[std::string(Arg.getName())] = Alloca; } if (Value *RetVal = Body->codegen()) { diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/KaleidoscopeJIT.h b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/KaleidoscopeJIT.h index 1d9c98a9d72..d22f893ac61 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/KaleidoscopeJIT.h +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/KaleidoscopeJIT.h @@ -98,10 +98,10 @@ public: : ES(ES), Resolver(createLegacyLookupResolver( ES, - [this](const std::string &Name) -> JITSymbol { + [this](StringRef Name) -> JITSymbol { if (auto Sym = IndirectStubsMgr->findStub(Name, false)) return Sym; - if (auto Sym = OptimizeLayer.findSymbol(Name, false)) + if (auto Sym = OptimizeLayer.findSymbol(std::string(Name), false)) return Sym; else if (auto Err = Sym.takeError()) return std::move(Err); diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/toy.cpp index eff61fb954d..b9819327f84 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter5/toy.cpp @@ -736,7 +736,7 @@ Function *getFunction(std::string Name) { /// CreateEntryBlockAlloca - Create an alloca instruction in the entry block of /// the function. This is used for mutable variables etc. static AllocaInst *CreateEntryBlockAlloca(Function *TheFunction, - const std::string &VarName) { + StringRef VarName) { IRBuilder<> TmpB(&TheFunction->getEntryBlock(), TheFunction->getEntryBlock().begin()); return TmpB.CreateAlloca(Type::getDoubleTy(TheContext), nullptr, VarName); @@ -1092,7 +1092,7 @@ Function *FunctionAST::codegen() { Builder.CreateStore(&Arg, Alloca); // Add arguments to variable symbol table. - NamedValues[Arg.getName()] = Alloca; + NamedValues[std::string(Arg.getName())] = Alloca; } if (Value *RetVal = Body->codegen()) { diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter3/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter3/toy.cpp index f7b2d988fd1..557780df7b3 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter3/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter3/toy.cpp @@ -497,7 +497,7 @@ Function *FunctionAST::codegen() { // Record the function arguments in the NamedValues map. NamedValues.clear(); for (auto &Arg : TheFunction->args()) - NamedValues[Arg.getName()] = &Arg; + NamedValues[std::string(Arg.getName())] = &Arg; if (Value *RetVal = Body->codegen()) { // Finish off the function. diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter4/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter4/toy.cpp index 3c17a018853..f9321f8ea98 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter4/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter4/toy.cpp @@ -524,7 +524,7 @@ Function *FunctionAST::codegen() { // Record the function arguments in the NamedValues map. NamedValues.clear(); for (auto &Arg : TheFunction->args()) - NamedValues[Arg.getName()] = &Arg; + NamedValues[std::string(Arg.getName())] = &Arg; if (Value *RetVal = Body->codegen()) { // Finish off the function. diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter5/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter5/toy.cpp index 3eeb1c14a36..22bec97b312 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter5/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter5/toy.cpp @@ -798,7 +798,7 @@ Function *FunctionAST::codegen() { // Record the function arguments in the NamedValues map. NamedValues.clear(); for (auto &Arg : TheFunction->args()) - NamedValues[Arg.getName()] = &Arg; + NamedValues[std::string(Arg.getName())] = &Arg; if (Value *RetVal = Body->codegen()) { // Finish off the function. diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter6/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter6/toy.cpp index 5b3dd5a6c4e..2a7dedc510a 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter6/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter6/toy.cpp @@ -914,7 +914,7 @@ Function *FunctionAST::codegen() { // Record the function arguments in the NamedValues map. NamedValues.clear(); for (auto &Arg : TheFunction->args()) - NamedValues[Arg.getName()] = &Arg; + NamedValues[std::string(Arg.getName())] = &Arg; if (Value *RetVal = Body->codegen()) { // Finish off the function. diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter7/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter7/toy.cpp index c42431a8ba1..317b602765e 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter7/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter7/toy.cpp @@ -732,7 +732,7 @@ Function *getFunction(std::string Name) { /// CreateEntryBlockAlloca - Create an alloca instruction in the entry block of /// the function. This is used for mutable variables etc. static AllocaInst *CreateEntryBlockAlloca(Function *TheFunction, - const std::string &VarName) { + StringRef VarName) { IRBuilder<> TmpB(&TheFunction->getEntryBlock(), TheFunction->getEntryBlock().begin()); return TmpB.CreateAlloca(Type::getDoubleTy(TheContext), nullptr, VarName); @@ -1081,7 +1081,7 @@ Function *FunctionAST::codegen() { Builder.CreateStore(&Arg, Alloca); // Add arguments to variable symbol table. - NamedValues[Arg.getName()] = Alloca; + NamedValues[std::string(Arg.getName())] = Alloca; } if (Value *RetVal = Body->codegen()) { diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter8/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter8/toy.cpp index 2da3b602b62..92903741f21 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter8/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter8/toy.cpp @@ -731,7 +731,7 @@ Function *getFunction(std::string Name) { /// CreateEntryBlockAlloca - Create an alloca instruction in the entry block of /// the function. This is used for mutable variables etc. static AllocaInst *CreateEntryBlockAlloca(Function *TheFunction, - const std::string &VarName) { + StringRef VarName) { IRBuilder<> TmpB(&TheFunction->getEntryBlock(), TheFunction->getEntryBlock().begin()); return TmpB.CreateAlloca(Type::getDoubleTy(TheContext), nullptr, VarName); @@ -1080,7 +1080,7 @@ Function *FunctionAST::codegen() { Builder.CreateStore(&Arg, Alloca); // Add arguments to variable symbol table. - NamedValues[Arg.getName()] = Alloca; + NamedValues[std::string(Arg.getName())] = Alloca; } if (Value *RetVal = Body->codegen()) { diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter9/toy.cpp b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter9/toy.cpp index 21c8993e1a0..7b33dae6e13 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/Chapter9/toy.cpp +++ b/gnu/llvm/llvm/examples/Kaleidoscope/Chapter9/toy.cpp @@ -7,6 +7,7 @@ #include "llvm/IR/LegacyPassManager.h" #include "llvm/IR/Module.h" #include "llvm/IR/Verifier.h" +#include "llvm/Support/Host.h" #include "llvm/Support/TargetSelect.h" #include "llvm/Transforms/Scalar.h" #include @@ -884,11 +885,10 @@ Function *getFunction(std::string Name) { /// CreateEntryBlockAlloca - Create an alloca instruction in the entry block of /// the function. This is used for mutable variables etc. static AllocaInst *CreateEntryBlockAlloca(Function *TheFunction, - const std::string &VarName) { + StringRef VarName) { IRBuilder<> TmpB(&TheFunction->getEntryBlock(), TheFunction->getEntryBlock().begin()); - return TmpB.CreateAlloca(Type::getDoubleTy(TheContext), nullptr, - VarName.c_str()); + return TmpB.CreateAlloca(Type::getDoubleTy(TheContext), nullptr, VarName); } Value *NumberExprAST::codegen() { @@ -1277,7 +1277,7 @@ Function *FunctionAST::codegen() { Builder.CreateStore(&Arg, Alloca); // Add arguments to variable symbol table. - NamedValues[Arg.getName()] = Alloca; + NamedValues[std::string(Arg.getName())] = Alloca; } KSDbgInfo.emitLocation(Body.get()); diff --git a/gnu/llvm/llvm/examples/Kaleidoscope/include/KaleidoscopeJIT.h b/gnu/llvm/llvm/examples/Kaleidoscope/include/KaleidoscopeJIT.h index a253a973a4c..86fdc1ed4fe 100644 --- a/gnu/llvm/llvm/examples/Kaleidoscope/include/KaleidoscopeJIT.h +++ b/gnu/llvm/llvm/examples/Kaleidoscope/include/KaleidoscopeJIT.h @@ -45,7 +45,9 @@ public: KaleidoscopeJIT() : Resolver(createLegacyLookupResolver( ES, - [this](const std::string &Name) { return findMangledSymbol(Name); }, + [this](StringRef Name) { + return findMangledSymbol(std::string(Name)); + }, [](Error Err) { cantFail(std::move(Err), "lookupFlags failed"); })), TM(EngineBuilder().selectTarget()), DL(TM->createDataLayout()), ObjectLayer(AcknowledgeORCv1Deprecation, ES, diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/CMakeLists.txt new file mode 100644 index 00000000000..2c737296ae1 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/CMakeLists.txt @@ -0,0 +1,10 @@ +add_subdirectory(LLJITDumpObjects) +add_subdirectory(LLJITWithCustomObjectLinkingLayer) +add_subdirectory(LLJITWithGDBRegistrationListener) +add_subdirectory(LLJITWithInitializers) +add_subdirectory(LLJITWithLazyReexports) +add_subdirectory(LLJITWithObjectCache) +add_subdirectory(LLJITWithObjectLinkingLayerPlugin) +add_subdirectory(OrcV2CBindingsAddObjectFile) +add_subdirectory(OrcV2CBindingsBasicUsage) +add_subdirectory(OrcV2CBindingsReflectProcessSymbols) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/ExampleModules.h b/gnu/llvm/llvm/examples/OrcV2Examples/ExampleModules.h new file mode 100644 index 00000000000..ae0089fd9dd --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/ExampleModules.h @@ -0,0 +1,54 @@ +//===----- ExampleModules.h - IR modules for LLJIT examples -----*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// +// Example modules for LLJIT examples +// +//===----------------------------------------------------------------------===// + +#ifndef LLVM_EXAMPLES_HOWTOUSELLJIT_EXAMPLEMODULES_H +#define LLVM_EXAMPLES_HOWTOUSELLJIT_EXAMPLEMODULES_H + +#include "llvm/ADT/StringRef.h" +#include "llvm/ExecutionEngine/Orc/ThreadSafeModule.h" +#include "llvm/IR/LLVMContext.h" +#include "llvm/IR/Module.h" +#include "llvm/IRReader/IRReader.h" +#include "llvm/Support/Error.h" +#include "llvm/Support/SourceMgr.h" + +const llvm::StringRef Add1Example = + R"( + define i32 @add1(i32 %x) { + entry: + %r = add nsw i32 %x, 1 + ret i32 %r + } +)"; + +inline llvm::Expected +parseExampleModule(llvm::StringRef Source, llvm::StringRef Name) { + using namespace llvm; + using namespace llvm::orc; + + auto Ctx = std::make_unique(); + SMDiagnostic Err; + auto M = parseIR(MemoryBufferRef(Source, Name), Err, *Ctx); + + if (!M) { + std::string ErrMsg; + { + raw_string_ostream ErrStream(ErrMsg); + Err.print("", ErrStream); + } + return make_error(std::move(ErrMsg), inconvertibleErrorCode()); + } + + return ThreadSafeModule(std::move(M), std::move(Ctx)); +} + +#endif // LLVM_EXAMPLES_HOWTOUSELLJIT_EXAMPLEMODULES_H diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITDumpObjects/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITDumpObjects/CMakeLists.txt new file mode 100644 index 00000000000..3d83ee6864d --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITDumpObjects/CMakeLists.txt @@ -0,0 +1,13 @@ +set(LLVM_LINK_COMPONENTS + Core + ExecutionEngine + IRReader + JITLink + OrcJIT + Support + nativecodegen + ) + +add_llvm_example(LLJITDumpObjects + LLJITDumpObjects.cpp + ) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITDumpObjects/LLJITDumpObjects.cpp b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITDumpObjects/LLJITDumpObjects.cpp new file mode 100644 index 00000000000..9b020ef8c49 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITDumpObjects/LLJITDumpObjects.cpp @@ -0,0 +1,70 @@ +//===----- LLJITDumpObjects.cpp - How to dump JIT'd objects with LLJIT ----===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#include "llvm/ADT/StringMap.h" +#include "llvm/ExecutionEngine/Orc/DebugUtils.h" +#include "llvm/ExecutionEngine/Orc/LLJIT.h" +#include "llvm/Support/InitLLVM.h" +#include "llvm/Support/TargetSelect.h" +#include "llvm/Support/raw_ostream.h" + +#include "../ExampleModules.h" + +using namespace llvm; +using namespace llvm::orc; + +ExitOnError ExitOnErr; + +cl::opt DumpJITdObjects("dump-jitted-objects", + cl::desc("dump jitted objects"), cl::Optional, + cl::init(true)); + +cl::opt DumpDir("dump-dir", + cl::desc("directory to dump objects to"), + cl::Optional, cl::init("")); + +cl::opt DumpFileStem("dump-file-stem", + cl::desc("Override default dump names"), + cl::Optional, cl::init("")); + +int main(int argc, char *argv[]) { + // Initialize LLVM. + InitLLVM X(argc, argv); + + InitializeNativeTarget(); + InitializeNativeTargetAsmPrinter(); + + cl::ParseCommandLineOptions(argc, argv, "LLJITDumpObjects"); + ExitOnErr.setBanner(std::string(argv[0]) + ": "); + + outs() + << "Usage notes:\n" + " Use -debug-only=orc on debug builds to see log messages of objects " + "being dumped\n" + " Specify -dump-dir to specify a dump directory\n" + " Specify -dump-file-stem to override the dump file stem\n" + " Specify -dump-jitted-objects=false to disable dumping\n"; + + auto J = ExitOnErr(LLJITBuilder().create()); + + if (DumpJITdObjects) + J->getObjTransformLayer().setTransform(DumpObjects(DumpDir, DumpFileStem)); + + auto M = ExitOnErr(parseExampleModule(Add1Example, "add1")); + + ExitOnErr(J->addIRModule(std::move(M))); + + // Look up the JIT'd function, cast it to a function pointer, then call it. + auto Add1Sym = ExitOnErr(J->lookup("add1")); + int (*Add1)(int) = (int (*)(int))Add1Sym.getAddress(); + + int Result = Add1(42); + outs() << "add1(42) = " << Result << "\n"; + + return 0; +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer/CMakeLists.txt new file mode 100644 index 00000000000..6034fc67911 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer/CMakeLists.txt @@ -0,0 +1,12 @@ +set(LLVM_LINK_COMPONENTS + Core + IRReader + JITLink + OrcJIT + Support + nativecodegen + ) + +add_llvm_example(LLJITWithCustomObjectLinkingLayer + LLJITWithCustomObjectLinkingLayer.cpp + ) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer/LLJITWithCustomObjectLinkingLayer.cpp b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer/LLJITWithCustomObjectLinkingLayer.cpp new file mode 100644 index 00000000000..a2bdbcbb08a --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer/LLJITWithCustomObjectLinkingLayer.cpp @@ -0,0 +1,66 @@ +//===--------------- LLJITWithCustomObjectLinkingLayer.cpp ----------------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// +// This file shows how to switch LLJIT to use a custom object linking layer (we +// use ObjectLinkingLayer, which is backed by JITLink, as an example). +// +//===----------------------------------------------------------------------===// + +#include "llvm/ADT/StringMap.h" +#include "llvm/ExecutionEngine/JITLink/JITLinkMemoryManager.h" +#include "llvm/ExecutionEngine/Orc/LLJIT.h" +#include "llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h" +#include "llvm/Support/InitLLVM.h" +#include "llvm/Support/TargetSelect.h" +#include "llvm/Support/raw_ostream.h" + +#include "../ExampleModules.h" + +using namespace llvm; +using namespace llvm::orc; + +ExitOnError ExitOnErr; + +int main(int argc, char *argv[]) { + // Initialize LLVM. + InitLLVM X(argc, argv); + + InitializeNativeTarget(); + InitializeNativeTargetAsmPrinter(); + + cl::ParseCommandLineOptions(argc, argv, "LLJITWithCustomObjectLinkingLayer"); + ExitOnErr.setBanner(std::string(argv[0]) + ": "); + + // Detect the host and set code model to small. + auto JTMB = ExitOnErr(JITTargetMachineBuilder::detectHost()); + JTMB.setCodeModel(CodeModel::Small); + + // Create an LLJIT instance with an ObjectLinkingLayer as the base layer. + auto J = ExitOnErr( + LLJITBuilder() + .setJITTargetMachineBuilder(std::move(JTMB)) + .setObjectLinkingLayerCreator( + [&](ExecutionSession &ES, const Triple &TT) { + return std::make_unique( + ES, std::make_unique()); + }) + .create()); + + auto M = ExitOnErr(parseExampleModule(Add1Example, "add1")); + + ExitOnErr(J->addIRModule(std::move(M))); + + // Look up the JIT'd function, cast it to a function pointer, then call it. + auto Add1Sym = ExitOnErr(J->lookup("add1")); + int (*Add1)(int) = (int (*)(int))Add1Sym.getAddress(); + + int Result = Add1(42); + outs() << "add1(42) = " << Result << "\n"; + + return 0; +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener/CMakeLists.txt new file mode 100644 index 00000000000..0b1cdffb380 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener/CMakeLists.txt @@ -0,0 +1,17 @@ +set(LLVM_LINK_COMPONENTS + Core + ExecutionEngine + IRReader + JITLink + OrcJIT + Support + nativecodegen + ) + +add_llvm_example(LLJITWithGDBRegistrationListener + LLJITWithGDBRegistrationListener.cpp + ) + +# We want JIT'd code to be able to link against process symbols like printf +# for this example, so make sure they're exported. +export_executable_symbols(LLJITWithGDBRegistrationListener) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener/LLJITWithGDBRegistrationListener.cpp b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener/LLJITWithGDBRegistrationListener.cpp new file mode 100644 index 00000000000..493d1214c60 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener/LLJITWithGDBRegistrationListener.cpp @@ -0,0 +1,115 @@ +//===--------------- LLJITWithCustomObjectLinkingLayer.cpp ----------------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// +// This file shows how to switch LLJIT to use a custom object linking layer (we +// use ObjectLinkingLayer, which is backed by JITLink, as an example). +// +//===----------------------------------------------------------------------===// + +#include "llvm/ADT/StringMap.h" +#include "llvm/ExecutionEngine/JITEventListener.h" +#include "llvm/ExecutionEngine/JITLink/JITLinkMemoryManager.h" +#include "llvm/ExecutionEngine/Orc/ExecutionUtils.h" +#include "llvm/ExecutionEngine/Orc/LLJIT.h" +#include "llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h" +#include "llvm/ExecutionEngine/SectionMemoryManager.h" +#include "llvm/Support/InitLLVM.h" +#include "llvm/Support/TargetSelect.h" +#include "llvm/Support/raw_ostream.h" + +#include "../ExampleModules.h" + +using namespace llvm; +using namespace llvm::orc; + +ExitOnError ExitOnErr; + +static cl::opt + EntryPointName("entry", cl::desc("Symbol to call as main entry point"), + cl::init("main")); + +static cl::list InputFiles(cl::Positional, cl::OneOrMore, + cl::desc("input files")); + +static cl::list InputArgv("args", cl::Positional, + cl::desc("..."), + cl::ZeroOrMore, cl::PositionalEatsArgs); + +int main(int argc, char *argv[]) { + // Initialize LLVM. + InitLLVM X(argc, argv); + + InitializeNativeTarget(); + InitializeNativeTargetAsmPrinter(); + + cl::ParseCommandLineOptions(argc, argv, "LLJITWithCustomObjectLinkingLayer"); + ExitOnErr.setBanner(std::string(argv[0]) + ": "); + + // Detect the host and set code model to small. + auto JTMB = ExitOnErr(JITTargetMachineBuilder::detectHost()); + if (!JTMB.getTargetTriple().isOSLinux()) + errs() + << "Warning: This demo may not work for platforms other than Linux.\n"; + + // Create an LLJIT instance and use a custom object linking layer creator to + // register the GDBRegistrationListener with our RTDyldObjectLinkingLayer. + auto J = + ExitOnErr(LLJITBuilder() + .setJITTargetMachineBuilder(std::move(JTMB)) + .setObjectLinkingLayerCreator([&](ExecutionSession &ES, + const Triple &TT) { + auto GetMemMgr = []() { + return std::make_unique(); + }; + auto ObjLinkingLayer = + std::make_unique( + ES, std::move(GetMemMgr)); + + // Register the event listener. + ObjLinkingLayer->registerJITEventListener( + *JITEventListener::createGDBRegistrationListener()); + + // Make sure the debug info sections aren't stripped. + ObjLinkingLayer->setProcessAllSections(true); + + return ObjLinkingLayer; + }) + .create()); + + // Make sure that our process symbols are visible to JIT'd code. + { + MangleAndInterner Mangle(J->getExecutionSession(), J->getDataLayout()); + J->getMainJITDylib().addGenerator( + ExitOnErr(orc::DynamicLibrarySearchGenerator::GetForCurrentProcess( + J->getDataLayout().getGlobalPrefix(), + [MainName = Mangle("main")](const orc::SymbolStringPtr &Name) { + return Name != MainName; + }))); + } + + // Load the input modules. + for (auto &InputFile : InputFiles) { + auto Ctx = std::make_unique(); + SMDiagnostic Err; + std::unique_ptr M = parseIRFile(InputFile, Err, *Ctx); + if (!M) { + Err.print(argv[0], errs()); + return 1; + } + + ExitOnErr(J->addIRModule(ThreadSafeModule(std::move(M), std::move(Ctx)))); + } + + // Look up the entry point, cast it to a C main function pointer, then use + // runAsMain to call it. + auto EntrySym = ExitOnErr(J->lookup(EntryPointName)); + auto EntryFn = + jitTargetAddressToFunction(EntrySym.getAddress()); + + return runAsMain(EntryFn, InputArgv, StringRef(InputFiles.front())); +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithInitializers/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithInitializers/CMakeLists.txt new file mode 100644 index 00000000000..302647564ab --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithInitializers/CMakeLists.txt @@ -0,0 +1,13 @@ +set(LLVM_LINK_COMPONENTS + Core + ExecutionEngine + IRReader + JITLink + OrcJIT + Support + nativecodegen + ) + +add_llvm_example(LLJITWithInitializers + LLJITWithInitializers.cpp + ) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithInitializers/LLJITWithInitializers.cpp b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithInitializers/LLJITWithInitializers.cpp new file mode 100644 index 00000000000..063b9f6060e --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithInitializers/LLJITWithInitializers.cpp @@ -0,0 +1,97 @@ +//===----- LLJITDumpObjects.cpp - How to dump JIT'd objects with LLJIT ----===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +/// +/// \file +/// +/// This example demonstrates how to use LLJIT to: +/// - Add absolute symbol definitions. +/// - Run static constructors for a JITDylib. +/// - Run static destructors for a JITDylib. +/// +/// This example does not call any functions (e.g. main or equivalent) between +/// running the static constructors and running the static destructors. +/// +//===----------------------------------------------------------------------===// + +#include "llvm/ADT/StringMap.h" +#include "llvm/ExecutionEngine/Orc/LLJIT.h" +#include "llvm/Support/InitLLVM.h" +#include "llvm/Support/TargetSelect.h" +#include "llvm/Support/raw_ostream.h" + +#include "../ExampleModules.h" + +using namespace llvm; +using namespace llvm::orc; + +ExitOnError ExitOnErr; + +const llvm::StringRef ModuleWithInitializer = + R"( + + @InitializersRunFlag = external global i32 + @DeinitializersRunFlag = external global i32 + + declare i32 @__cxa_atexit(void (i8*)*, i8*, i8*) + @__dso_handle = external hidden global i8 + + @llvm.global_ctors = + appending global [1 x { i32, void ()*, i8* }] + [{ i32, void ()*, i8* } { i32 65535, void ()* @init_func, i8* null }] + + define internal void @init_func() { + entry: + store i32 1, i32* @InitializersRunFlag + %0 = call i32 @__cxa_atexit(void (i8*)* @deinit_func, i8* null, + i8* @__dso_handle) + ret void + } + + define internal void @deinit_func(i8* %0) { + store i32 1, i32* @DeinitializersRunFlag + ret void + } + +)"; + +int main(int argc, char *argv[]) { + // Initialize LLVM. + InitLLVM X(argc, argv); + + InitializeNativeTarget(); + InitializeNativeTargetAsmPrinter(); + + cl::ParseCommandLineOptions(argc, argv, "LLJITWithInitializers"); + ExitOnErr.setBanner(std::string(argv[0]) + ": "); + + auto J = ExitOnErr(LLJITBuilder().create()); + auto M = ExitOnErr(parseExampleModule(ModuleWithInitializer, "M")); + + // Load the module. + ExitOnErr(J->addIRModule(std::move(M))); + + int32_t InitializersRunFlag = 0; + int32_t DeinitializersRunFlag = 0; + + ExitOnErr(J->define(absoluteSymbols( + {{J->mangleAndIntern("InitializersRunFlag"), + JITEvaluatedSymbol::fromPointer(&InitializersRunFlag)}, + {J->mangleAndIntern("DeinitializersRunFlag"), + JITEvaluatedSymbol::fromPointer(&DeinitializersRunFlag)}}))); + + // Run static initializers. + ExitOnErr(J->initialize(J->getMainJITDylib())); + + // Run deinitializers. + ExitOnErr(J->deinitialize(J->getMainJITDylib())); + + outs() << "InitializerRanFlag = " << InitializersRunFlag << "\n" + << "DeinitializersRunFlag = " << DeinitializersRunFlag << "\n"; + + return 0; +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithLazyReexports/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithLazyReexports/CMakeLists.txt new file mode 100644 index 00000000000..cdff74b10ad --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithLazyReexports/CMakeLists.txt @@ -0,0 +1,12 @@ +set(LLVM_LINK_COMPONENTS + Core + ExecutionEngine + IRReader + OrcJIT + Support + nativecodegen + ) + +add_llvm_example(LLJITWithLazyReexports + LLJITWithLazyReexports.cpp + ) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithLazyReexports/LLJITWithLazyReexports.cpp b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithLazyReexports/LLJITWithLazyReexports.cpp new file mode 100644 index 00000000000..5d4a27c4324 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithLazyReexports/LLJITWithLazyReexports.cpp @@ -0,0 +1,163 @@ +//===--- LLJITWithLazyReexports.cpp - LLJIT example with custom laziness --===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// +// In this example we will use the lazy re-exports utility to lazily compile +// IR modules. We will do this in seven steps: +// +// 1. Create an LLJIT instance. +// 2. Install a transform so that we can see what is being compiled. +// 3. Create an indirect stubs manager and lazy call-through manager. +// 4. Add two modules that will be conditionally compiled, plus a main module. +// 5. Add lazy-rexports of the symbols in the conditionally compiled modules. +// 6. Dump the ExecutionSession state to see the symbol table prior to +// executing any code. +// 7. Verify that only modules containing executed code are compiled. +// +//===----------------------------------------------------------------------===// + +#include "llvm/ADT/StringMap.h" +#include "llvm/ExecutionEngine/JITLink/JITLinkMemoryManager.h" +#include "llvm/ExecutionEngine/Orc/LLJIT.h" +#include "llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h" +#include "llvm/Support/InitLLVM.h" +#include "llvm/Support/TargetSelect.h" +#include "llvm/Support/raw_ostream.h" + +#include "../ExampleModules.h" + +using namespace llvm; +using namespace llvm::orc; + +ExitOnError ExitOnErr; + +// Example IR modules. +// +// Note that in the conditionally compiled modules, FooMod and BarMod, functions +// have been given an _body suffix. This is to ensure that their names do not +// clash with their lazy-reexports. +// For clients who do not wish to rename function bodies (e.g. because they want +// to re-use cached objects between static and JIT compiles) techniques exist to +// avoid renaming. See the lazy-reexports section of the ORCv2 design doc. + +const llvm::StringRef FooMod = + R"( + define i32 @foo_body() { + entry: + ret i32 1 + } +)"; + +const llvm::StringRef BarMod = + R"( + define i32 @bar_body() { + entry: + ret i32 2 + } +)"; + +const llvm::StringRef MainMod = + R"( + + define i32 @entry(i32 %argc) { + entry: + %and = and i32 %argc, 1 + %tobool = icmp eq i32 %and, 0 + br i1 %tobool, label %if.end, label %if.then + + if.then: ; preds = %entry + %call = tail call i32 @foo() #2 + br label %return + + if.end: ; preds = %entry + %call1 = tail call i32 @bar() #2 + br label %return + + return: ; preds = %if.end, %if.then + %retval.0 = phi i32 [ %call, %if.then ], [ %call1, %if.end ] + ret i32 %retval.0 + } + + declare i32 @foo() + declare i32 @bar() +)"; + +cl::list InputArgv(cl::Positional, + cl::desc("...")); + +int main(int argc, char *argv[]) { + // Initialize LLVM. + InitLLVM X(argc, argv); + + InitializeNativeTarget(); + InitializeNativeTargetAsmPrinter(); + + cl::ParseCommandLineOptions(argc, argv, "LLJITWithLazyReexports"); + ExitOnErr.setBanner(std::string(argv[0]) + ": "); + + // (1) Create LLJIT instance. + auto J = ExitOnErr(LLJITBuilder().create()); + + // (2) Install transform to print modules as they are compiled: + J->getIRTransformLayer().setTransform( + [](ThreadSafeModule TSM, + const MaterializationResponsibility &R) -> Expected { + TSM.withModuleDo([](Module &M) { dbgs() << "---Compiling---\n" << M; }); + return std::move(TSM); // Not a redundant move: fix build on gcc-7.5 + }); + + // (3) Create stubs and call-through managers: + std::unique_ptr ISM; + { + auto ISMBuilder = + createLocalIndirectStubsManagerBuilder(J->getTargetTriple()); + if (!ISMBuilder()) + ExitOnErr(make_error("Could not create stubs manager for " + + J->getTargetTriple().str(), + inconvertibleErrorCode())); + ISM = ISMBuilder(); + } + auto LCTM = ExitOnErr(createLocalLazyCallThroughManager( + J->getTargetTriple(), J->getExecutionSession(), 0)); + + // (4) Add modules. + ExitOnErr(J->addIRModule(ExitOnErr(parseExampleModule(FooMod, "foo-mod")))); + ExitOnErr(J->addIRModule(ExitOnErr(parseExampleModule(BarMod, "bar-mod")))); + ExitOnErr(J->addIRModule(ExitOnErr(parseExampleModule(MainMod, "main-mod")))); + + // (5) Add lazy reexports. + MangleAndInterner Mangle(J->getExecutionSession(), J->getDataLayout()); + SymbolAliasMap ReExports( + {{Mangle("foo"), + {Mangle("foo_body"), + JITSymbolFlags::Exported | JITSymbolFlags::Callable}}, + {Mangle("bar"), + {Mangle("bar_body"), + JITSymbolFlags::Exported | JITSymbolFlags::Callable}}}); + ExitOnErr(J->getMainJITDylib().define( + lazyReexports(*LCTM, *ISM, J->getMainJITDylib(), std::move(ReExports)))); + + // (6) Dump the ExecutionSession state. + dbgs() << "---Session state---\n"; + J->getExecutionSession().dump(dbgs()); + dbgs() << "\n"; + + // (7) Execute the JIT'd main function and pass the example's command line + // arguments unmodified. This should cause either ExampleMod1 or ExampleMod2 + // to be compiled, and either "1" or "2" returned depending on the number of + // arguments passed. + + // Look up the JIT'd function, cast it to a function pointer, then call it. + auto EntrySym = ExitOnErr(J->lookup("entry")); + auto *Entry = (int (*)(int))EntrySym.getAddress(); + + int Result = Entry(argc); + outs() << "---Result---\n" + << "entry(" << argc << ") = " << Result << "\n"; + + return 0; +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectCache/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectCache/CMakeLists.txt new file mode 100644 index 00000000000..c5f8fd6a97a --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectCache/CMakeLists.txt @@ -0,0 +1,12 @@ +set(LLVM_LINK_COMPONENTS + Core + ExecutionEngine + IRReader + OrcJIT + Support + nativecodegen + ) + +add_llvm_example(LLJITWithObjectCache + LLJITWithObjectCache.cpp + ) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectCache/LLJITWithObjectCache.cpp b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectCache/LLJITWithObjectCache.cpp new file mode 100644 index 00000000000..f94fd853ed0 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectCache/LLJITWithObjectCache.cpp @@ -0,0 +1,95 @@ +//===--- LLJITWithObjectCache.cpp - An LLJIT example with an ObjectCache --===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#include "llvm/ADT/StringMap.h" +#include "llvm/ExecutionEngine/ObjectCache.h" +#include "llvm/ExecutionEngine/Orc/LLJIT.h" +#include "llvm/IR/Function.h" +#include "llvm/IR/IRBuilder.h" +#include "llvm/IR/Module.h" +#include "llvm/Support/InitLLVM.h" +#include "llvm/Support/TargetSelect.h" +#include "llvm/Support/raw_ostream.h" + +#include "../ExampleModules.h" + +using namespace llvm; +using namespace llvm::orc; + +ExitOnError ExitOnErr; + +class MyObjectCache : public ObjectCache { +public: + void notifyObjectCompiled(const Module *M, + MemoryBufferRef ObjBuffer) override { + CachedObjects[M->getModuleIdentifier()] = MemoryBuffer::getMemBufferCopy( + ObjBuffer.getBuffer(), ObjBuffer.getBufferIdentifier()); + } + + std::unique_ptr getObject(const Module *M) override { + auto I = CachedObjects.find(M->getModuleIdentifier()); + if (I == CachedObjects.end()) { + dbgs() << "No object for " << M->getModuleIdentifier() + << " in cache. Compiling.\n"; + return nullptr; + } + + dbgs() << "Object for " << M->getModuleIdentifier() + << " loaded from cache.\n"; + return MemoryBuffer::getMemBuffer(I->second->getMemBufferRef()); + } + +private: + StringMap> CachedObjects; +}; + +void runJITWithCache(ObjectCache &ObjCache) { + + // Create an LLJIT instance with a custom IRCompiler. + auto J = ExitOnErr( + LLJITBuilder() + .setCompileFunctionCreator( + [&](JITTargetMachineBuilder JTMB) + -> Expected> { + auto TM = JTMB.createTargetMachine(); + if (!TM) + return TM.takeError(); + return std::make_unique(std::move(*TM), + &ObjCache); + }) + .create()); + + auto M = ExitOnErr(parseExampleModule(Add1Example, "add1")); + + ExitOnErr(J->addIRModule(std::move(M))); + + // Look up the JIT'd function, cast it to a function pointer, then call it. + auto Add1Sym = ExitOnErr(J->lookup("add1")); + int (*Add1)(int) = (int (*)(int))Add1Sym.getAddress(); + + int Result = Add1(42); + outs() << "add1(42) = " << Result << "\n"; +} + +int main(int argc, char *argv[]) { + // Initialize LLVM. + InitLLVM X(argc, argv); + + InitializeNativeTarget(); + InitializeNativeTargetAsmPrinter(); + + cl::ParseCommandLineOptions(argc, argv, "LLJITWithObjectCache"); + ExitOnErr.setBanner(std::string(argv[0]) + ": "); + + MyObjectCache MyCache; + + runJITWithCache(MyCache); + runJITWithCache(MyCache); + + return 0; +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/CMakeLists.txt new file mode 100644 index 00000000000..54814621a5a --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/CMakeLists.txt @@ -0,0 +1,12 @@ +set(LLVM_LINK_COMPONENTS + Core + IRReader + JITLink + OrcJIT + Support + nativecodegen + ) + +add_llvm_example(LLJITWithObjectLinkingLayerPlugin + LLJITWithObjectLinkingLayerPlugin.cpp + ) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp new file mode 100644 index 00000000000..9bb6daa01da --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp @@ -0,0 +1,156 @@ +//===--------------- LLJITWithCustomObjectLinkingLayer.cpp ----------------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// +// This file shows how to switch LLJIT to use a custom object linking layer (we +// use ObjectLinkingLayer, which is backed by JITLink, as an example). +// +//===----------------------------------------------------------------------===// + +#include "llvm/ADT/StringMap.h" +#include "llvm/ExecutionEngine/JITLink/JITLink.h" +#include "llvm/ExecutionEngine/JITLink/JITLinkMemoryManager.h" +#include "llvm/ExecutionEngine/Orc/LLJIT.h" +#include "llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h" +#include "llvm/Support/InitLLVM.h" +#include "llvm/Support/TargetSelect.h" +#include "llvm/Support/raw_ostream.h" + +#include "../ExampleModules.h" + +using namespace llvm; +using namespace llvm::orc; + +ExitOnError ExitOnErr; + +const llvm::StringRef TestMod = + R"( + define i32 @callee() { + entry: + ret i32 7 + } + + define i32 @entry() { + entry: + %0 = call i32 @callee() + ret i32 %0 + } +)"; + +class MyPlugin : public ObjectLinkingLayer::Plugin { +public: + // The modifyPassConfig callback gives us a chance to inspect the + // MaterializationResponsibility and target triple for the object being + // linked, then add any JITLink passes that we would like to run on the + // link graph. A pass is just a function object that is callable as + // Error(jitlink::LinkGraph&). In this case we will add two passes + // defined as lambdas that call the printLinkerGraph method on our + // plugin: One to run before the linker applies fixups and another to + // run afterwards. + void modifyPassConfig(MaterializationResponsibility &MR, const Triple &TT, + jitlink::PassConfiguration &Config) override { + Config.PostPrunePasses.push_back([this](jitlink::LinkGraph &G) -> Error { + printLinkGraph(G, "Before fixup:"); + return Error::success(); + }); + Config.PostFixupPasses.push_back([this](jitlink::LinkGraph &G) -> Error { + printLinkGraph(G, "After fixup:"); + return Error::success(); + }); + } + + void notifyLoaded(MaterializationResponsibility &MR) override { + dbgs() << "Loading object defining " << MR.getSymbols() << "\n"; + } + + Error notifyEmitted(MaterializationResponsibility &MR) override { + dbgs() << "Emitted object defining " << MR.getSymbols() << "\n"; + return Error::success(); + } + +private: + void printLinkGraph(jitlink::LinkGraph &G, StringRef Title) { + constexpr JITTargetAddress LineWidth = 16; + + dbgs() << "--- " << Title << "---\n"; + for (auto &S : G.sections()) { + dbgs() << " section: " << S.getName() << "\n"; + for (auto *B : S.blocks()) { + dbgs() << " block@" << formatv("{0:x16}", B->getAddress()) << ":\n"; + + if (B->isZeroFill()) + continue; + + JITTargetAddress InitAddr = B->getAddress() & ~(LineWidth - 1); + JITTargetAddress StartAddr = B->getAddress(); + JITTargetAddress EndAddr = B->getAddress() + B->getSize(); + auto *Data = reinterpret_cast(B->getContent().data()); + + for (JITTargetAddress CurAddr = InitAddr; CurAddr != EndAddr; + ++CurAddr) { + if (CurAddr % LineWidth == 0) + dbgs() << " " << formatv("{0:x16}", CurAddr) << ": "; + if (CurAddr < StartAddr) + dbgs() << " "; + else + dbgs() << formatv("{0:x-2}", Data[CurAddr - StartAddr]) << " "; + if (CurAddr % LineWidth == LineWidth - 1) + dbgs() << "\n"; + } + if (EndAddr % LineWidth != 0) + dbgs() << "\n"; + dbgs() << "\n"; + } + } + } +}; + +int main(int argc, char *argv[]) { + // Initialize LLVM. + InitLLVM X(argc, argv); + + InitializeNativeTarget(); + InitializeNativeTargetAsmPrinter(); + + cl::ParseCommandLineOptions(argc, argv, "LLJITWithObjectLinkingLayerPlugin"); + ExitOnErr.setBanner(std::string(argv[0]) + ": "); + + // Detect the host and set code model to small. + auto JTMB = ExitOnErr(JITTargetMachineBuilder::detectHost()); + JTMB.setCodeModel(CodeModel::Small); + + // Create an LLJIT instance with an ObjectLinkingLayer as the base layer. + // We attach our plugin in to the newly created ObjectLinkingLayer before + // returning it. + auto J = ExitOnErr( + LLJITBuilder() + .setJITTargetMachineBuilder(std::move(JTMB)) + .setObjectLinkingLayerCreator( + [&](ExecutionSession &ES, const Triple &TT) { + // Create ObjectLinkingLayer. + auto ObjLinkingLayer = std::make_unique( + ES, std::make_unique()); + // Add an instance of our plugin. + ObjLinkingLayer->addPlugin(std::make_unique()); + return ObjLinkingLayer; + }) + .create()); + + auto M = ExitOnErr(parseExampleModule(TestMod, "test-module")); + + ExitOnErr(J->addIRModule(std::move(M))); + + // Look up the JIT'd function, cast it to a function pointer, then call it. + auto EntrySym = ExitOnErr(J->lookup("entry")); + auto *Entry = (int (*)())EntrySym.getAddress(); + + int Result = Entry(); + outs() << "---Result---\n" + << "entry() = " << Result << "\n"; + + return 0; +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/CMakeLists.txt new file mode 100644 index 00000000000..cc50112f326 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/CMakeLists.txt @@ -0,0 +1,15 @@ +set(LLVM_LINK_COMPONENTS + Core + ExecutionEngine + IRReader + JITLink + MC + OrcJIT + Support + Target + nativecodegen + ) + +add_llvm_example(OrcV2CBindingsAddObjectFile + OrcV2CBindingsAddObjectFile.c + ) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/OrcV2CBindingsAddObjectFile.c b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/OrcV2CBindingsAddObjectFile.c new file mode 100644 index 00000000000..49eca25b07a --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/OrcV2CBindingsAddObjectFile.c @@ -0,0 +1,158 @@ +//===-------- BasicOrcV2CBindings.c - Basic OrcV2 C Bindings Demo ---------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#include "llvm-c/Core.h" +#include "llvm-c/Error.h" +#include "llvm-c/Initialization.h" +#include "llvm-c/Orc.h" +#include "llvm-c/Support.h" +#include "llvm-c/Target.h" +#include "llvm-c/TargetMachine.h" + +#include + +int handleError(LLVMErrorRef Err) { + char *ErrMsg = LLVMGetErrorMessage(Err); + fprintf(stderr, "Error: %s\n", ErrMsg); + LLVMDisposeErrorMessage(ErrMsg); + return 1; +} + +LLVMModuleRef createDemoModule(LLVMContextRef Ctx) { + // Create a new LLVM module. + LLVMModuleRef M = LLVMModuleCreateWithNameInContext("demo", Ctx); + + // Add a "sum" function": + // - Create the function type and function instance. + LLVMTypeRef ParamTypes[] = {LLVMInt32Type(), LLVMInt32Type()}; + LLVMTypeRef SumFunctionType = + LLVMFunctionType(LLVMInt32Type(), ParamTypes, 2, 0); + LLVMValueRef SumFunction = LLVMAddFunction(M, "sum", SumFunctionType); + + // - Add a basic block to the function. + LLVMBasicBlockRef EntryBB = LLVMAppendBasicBlock(SumFunction, "entry"); + + // - Add an IR builder and point it at the end of the basic block. + LLVMBuilderRef Builder = LLVMCreateBuilder(); + LLVMPositionBuilderAtEnd(Builder, EntryBB); + + // - Get the two function arguments and use them co construct an "add" + // instruction. + LLVMValueRef SumArg0 = LLVMGetParam(SumFunction, 0); + LLVMValueRef SumArg1 = LLVMGetParam(SumFunction, 1); + LLVMValueRef Result = LLVMBuildAdd(Builder, SumArg0, SumArg1, "result"); + + // - Build the return instruction. + LLVMBuildRet(Builder, Result); + + return M; +} + +int main(int argc, char *argv[]) { + + int MainResult = 0; + + // Parse command line arguments and initialize LLVM Core. + LLVMParseCommandLineOptions(argc, (const char **)argv, ""); + LLVMInitializeCore(LLVMGetGlobalPassRegistry()); + + // Initialize native target codegen and asm printer. + LLVMInitializeNativeTarget(); + LLVMInitializeNativeAsmPrinter(); + + // Create the JIT instance. + LLVMOrcLLJITRef J; + { + LLVMErrorRef Err; + if ((Err = LLVMOrcCreateLLJIT(&J, 0))) { + MainResult = handleError(Err); + goto llvm_shutdown; + } + } + + // Create our demo object file. + LLVMMemoryBufferRef ObjectFileBuffer; + { + // Create a module. + LLVMContextRef Ctx = LLVMContextCreate(); + LLVMModuleRef M = createDemoModule(Ctx); + + // Get the Target. + const char *Triple = LLVMOrcLLJITGetTripleString(J); + LLVMTargetRef Target = 0; + char *ErrorMsg = 0; + if (LLVMGetTargetFromTriple(Triple, &Target, &ErrorMsg)) { + fprintf(stderr, "Error getting target for %s: %s\n", Triple, ErrorMsg); + LLVMDisposeModule(M); + LLVMContextDispose(Ctx); + goto jit_cleanup; + } + + // Construct a TargetMachine. + LLVMTargetMachineRef TM = + LLVMCreateTargetMachine(Target, Triple, "", "", LLVMCodeGenLevelNone, + LLVMRelocDefault, LLVMCodeModelDefault); + + // Run CodeGen to produce the buffer. + if (LLVMTargetMachineEmitToMemoryBuffer(TM, M, LLVMObjectFile, &ErrorMsg, + &ObjectFileBuffer)) { + fprintf(stderr, "Error emitting object: %s\n", ErrorMsg); + LLVMDisposeTargetMachine(TM); + LLVMDisposeModule(M); + LLVMContextDispose(Ctx); + goto jit_cleanup; + } + } + + // Add our object file buffer to the JIT. + { + LLVMOrcJITDylibRef MainJD = LLVMOrcLLJITGetMainJITDylib(J); + LLVMErrorRef Err; + if ((Err = LLVMOrcLLJITAddObjectFile(J, MainJD, ObjectFileBuffer))) { + MainResult = handleError(Err); + goto jit_cleanup; + } + } + + // Look up the address of our demo entry point. + LLVMOrcJITTargetAddress SumAddr; + { + LLVMErrorRef Err; + if ((Err = LLVMOrcLLJITLookup(J, &SumAddr, "sum"))) { + MainResult = handleError(Err); + goto jit_cleanup; + } + } + + // If we made it here then everything succeeded. Execute our JIT'd code. + int32_t (*Sum)(int32_t, int32_t) = (int32_t(*)(int32_t, int32_t))SumAddr; + int32_t Result = Sum(1, 2); + + // Print the result. + printf("1 + 2 = %i\n", Result); + +jit_cleanup: + // Destroy our JIT instance. This will clean up any memory that the JIT has + // taken ownership of. This operation is non-trivial (e.g. it may need to + // JIT static destructors) and may also fail. In that case we want to render + // the error to stderr, but not overwrite any existing return value. + { + LLVMErrorRef Err; + if ((Err = LLVMOrcDisposeLLJIT(J))) { + int NewFailureResult = handleError(Err); + if (MainResult == 0) + MainResult = NewFailureResult; + } + } + +llvm_shutdown: + // Shut down LLVM. + LLVMShutdown(); + + return MainResult; +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/CMakeLists.txt new file mode 100644 index 00000000000..0f18d6c2491 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/CMakeLists.txt @@ -0,0 +1,15 @@ +set(LLVM_LINK_COMPONENTS + Core + ExecutionEngine + IRReader + JITLink + MC + OrcJIT + Support + Target + nativecodegen + ) + +add_llvm_example(OrcV2CBindingsBasicUsage + OrcV2CBindingsBasicUsage.c + ) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/OrcV2CBindingsBasicUsage.c b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/OrcV2CBindingsBasicUsage.c new file mode 100644 index 00000000000..cc54cc49ec2 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/OrcV2CBindingsBasicUsage.c @@ -0,0 +1,144 @@ +//===-------- BasicOrcV2CBindings.c - Basic OrcV2 C Bindings Demo ---------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#include "llvm-c/Core.h" +#include "llvm-c/Error.h" +#include "llvm-c/Initialization.h" +#include "llvm-c/Orc.h" +#include "llvm-c/Support.h" +#include "llvm-c/Target.h" + +#include + +int handleError(LLVMErrorRef Err) { + char *ErrMsg = LLVMGetErrorMessage(Err); + fprintf(stderr, "Error: %s\n", ErrMsg); + LLVMDisposeErrorMessage(ErrMsg); + return 1; +} + +LLVMOrcThreadSafeModuleRef createDemoModule() { + // Create a new ThreadSafeContext and underlying LLVMContext. + LLVMOrcThreadSafeContextRef TSCtx = LLVMOrcCreateNewThreadSafeContext(); + + // Get a reference to the underlying LLVMContext. + LLVMContextRef Ctx = LLVMOrcThreadSafeContextGetContext(TSCtx); + + // Create a new LLVM module. + LLVMModuleRef M = LLVMModuleCreateWithNameInContext("demo", Ctx); + + // Add a "sum" function": + // - Create the function type and function instance. + LLVMTypeRef ParamTypes[] = {LLVMInt32Type(), LLVMInt32Type()}; + LLVMTypeRef SumFunctionType = + LLVMFunctionType(LLVMInt32Type(), ParamTypes, 2, 0); + LLVMValueRef SumFunction = LLVMAddFunction(M, "sum", SumFunctionType); + + // - Add a basic block to the function. + LLVMBasicBlockRef EntryBB = LLVMAppendBasicBlock(SumFunction, "entry"); + + // - Add an IR builder and point it at the end of the basic block. + LLVMBuilderRef Builder = LLVMCreateBuilder(); + LLVMPositionBuilderAtEnd(Builder, EntryBB); + + // - Get the two function arguments and use them co construct an "add" + // instruction. + LLVMValueRef SumArg0 = LLVMGetParam(SumFunction, 0); + LLVMValueRef SumArg1 = LLVMGetParam(SumFunction, 1); + LLVMValueRef Result = LLVMBuildAdd(Builder, SumArg0, SumArg1, "result"); + + // - Build the return instruction. + LLVMBuildRet(Builder, Result); + + // Our demo module is now complete. Wrap it and our ThreadSafeContext in a + // ThreadSafeModule. + LLVMOrcThreadSafeModuleRef TSM = LLVMOrcCreateNewThreadSafeModule(M, TSCtx); + + // Dispose of our local ThreadSafeContext value. The underlying LLVMContext + // will be kept alive by our ThreadSafeModule, TSM. + LLVMOrcDisposeThreadSafeContext(TSCtx); + + // Return the result. + return TSM; +} + +int main(int argc, char *argv[]) { + + int MainResult = 0; + + // Parse command line arguments and initialize LLVM Core. + LLVMParseCommandLineOptions(argc, (const char **)argv, ""); + LLVMInitializeCore(LLVMGetGlobalPassRegistry()); + + // Initialize native target codegen and asm printer. + LLVMInitializeNativeTarget(); + LLVMInitializeNativeAsmPrinter(); + + // Create the JIT instance. + LLVMOrcLLJITRef J; + { + LLVMErrorRef Err; + if ((Err = LLVMOrcCreateLLJIT(&J, 0))) { + MainResult = handleError(Err); + goto llvm_shutdown; + } + } + + // Create our demo module. + LLVMOrcThreadSafeModuleRef TSM = createDemoModule(); + + // Add our demo module to the JIT. + { + LLVMOrcJITDylibRef MainJD = LLVMOrcLLJITGetMainJITDylib(J); + LLVMErrorRef Err; + if ((Err = LLVMOrcLLJITAddLLVMIRModule(J, MainJD, TSM))) { + // If adding the ThreadSafeModule fails then we need to clean it up + // ourselves. If adding it succeeds the JIT will manage the memory. + LLVMOrcDisposeThreadSafeModule(TSM); + MainResult = handleError(Err); + goto jit_cleanup; + } + } + + // Look up the address of our demo entry point. + LLVMOrcJITTargetAddress SumAddr; + { + LLVMErrorRef Err; + if ((Err = LLVMOrcLLJITLookup(J, &SumAddr, "sum"))) { + MainResult = handleError(Err); + goto jit_cleanup; + } + } + + // If we made it here then everything succeeded. Execute our JIT'd code. + int32_t (*Sum)(int32_t, int32_t) = (int32_t(*)(int32_t, int32_t))SumAddr; + int32_t Result = Sum(1, 2); + + // Print the result. + printf("1 + 2 = %i\n", Result); + +jit_cleanup: + // Destroy our JIT instance. This will clean up any memory that the JIT has + // taken ownership of. This operation is non-trivial (e.g. it may need to + // JIT static destructors) and may also fail. In that case we want to render + // the error to stderr, but not overwrite any existing return value. + { + LLVMErrorRef Err; + if ((Err = LLVMOrcDisposeLLJIT(J))) { + int NewFailureResult = handleError(Err); + if (MainResult == 0) + MainResult = NewFailureResult; + } + } + +llvm_shutdown: + // Shut down LLVM. + LLVMShutdown(); + + return MainResult; +} diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/CMakeLists.txt b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/CMakeLists.txt new file mode 100644 index 00000000000..beb44692786 --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/CMakeLists.txt @@ -0,0 +1,17 @@ +set(LLVM_LINK_COMPONENTS + Core + ExecutionEngine + IRReader + JITLink + MC + OrcJIT + Support + Target + nativecodegen + ) + +add_llvm_example(OrcV2CBindingsReflectProcessSymbols + OrcV2CBindingsReflectProcessSymbols.c + ) + +export_executable_symbols(OrcV2CBindingsReflectProcessSymbols) diff --git a/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/OrcV2CBindingsReflectProcessSymbols.c b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/OrcV2CBindingsReflectProcessSymbols.c new file mode 100644 index 00000000000..790f153260e --- /dev/null +++ b/gnu/llvm/llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/OrcV2CBindingsReflectProcessSymbols.c @@ -0,0 +1,220 @@ +//===-------- BasicOrcV2CBindings.c - Basic OrcV2 C Bindings Demo ---------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#include "llvm-c/Core.h" +#include "llvm-c/Error.h" +#include "llvm-c/Initialization.h" +#include "llvm-c/Orc.h" +#include "llvm-c/Support.h" +#include "llvm-c/Target.h" + +#include +#include + +int handleError(LLVMErrorRef Err) { + char *ErrMsg = LLVMGetErrorMessage(Err); + fprintf(stderr, "Error: %s\n", ErrMsg); + LLVMDisposeErrorMessage(ErrMsg); + return 1; +} + +int32_t add(int32_t X, int32_t Y) { return X + Y; } + +int32_t mul(int32_t X, int32_t Y) { return X * Y; } + +int allowedSymbols(LLVMOrcSymbolStringPoolEntryRef Sym, void *Ctx) { + assert(Ctx && "Cannot call allowedSymbols with a null context"); + + LLVMOrcSymbolStringPoolEntryRef *AllowList = + (LLVMOrcSymbolStringPoolEntryRef *)Ctx; + + // If Sym appears in the allowed list then return true. + LLVMOrcSymbolStringPoolEntryRef *P = AllowList; + while (*P) { + if (Sym == *P) + return 1; + ++P; + } + + // otherwise return false. + return 0; +} + +LLVMOrcThreadSafeModuleRef createDemoModule() { + // Create a new ThreadSafeContext and underlying LLVMContext. + LLVMOrcThreadSafeContextRef TSCtx = LLVMOrcCreateNewThreadSafeContext(); + + // Get a reference to the underlying LLVMContext. + LLVMContextRef Ctx = LLVMOrcThreadSafeContextGetContext(TSCtx); + + // Create a new LLVM module. + LLVMModuleRef M = LLVMModuleCreateWithNameInContext("demo", Ctx); + + // Add a "sum" function": + // - Create the function type and function instance. + LLVMTypeRef I32BinOpParamTypes[] = {LLVMInt32Type(), LLVMInt32Type()}; + LLVMTypeRef I32BinOpFunctionType = + LLVMFunctionType(LLVMInt32Type(), I32BinOpParamTypes, 2, 0); + LLVMValueRef AddI32Function = LLVMAddFunction(M, "add", I32BinOpFunctionType); + LLVMValueRef MulI32Function = LLVMAddFunction(M, "mul", I32BinOpFunctionType); + + LLVMTypeRef MulAddParamTypes[] = {LLVMInt32Type(), LLVMInt32Type(), + LLVMInt32Type()}; + LLVMTypeRef MulAddFunctionType = + LLVMFunctionType(LLVMInt32Type(), MulAddParamTypes, 3, 0); + LLVMValueRef MulAddFunction = + LLVMAddFunction(M, "mul_add", MulAddFunctionType); + + // - Add a basic block to the function. + LLVMBasicBlockRef EntryBB = LLVMAppendBasicBlock(MulAddFunction, "entry"); + + // - Add an IR builder and point it at the end of the basic block. + LLVMBuilderRef Builder = LLVMCreateBuilder(); + LLVMPositionBuilderAtEnd(Builder, EntryBB); + + // - Get the three function arguments and use them co construct calls to + // 'mul' and 'add': + // + // i32 mul_add(i32 %0, i32 %1, i32 %2) { + // %t = call i32 @mul(i32 %0, i32 %1) + // %r = call i32 @add(i32 %t, i32 %2) + // ret i32 %r + // } + LLVMValueRef SumArg0 = LLVMGetParam(MulAddFunction, 0); + LLVMValueRef SumArg1 = LLVMGetParam(MulAddFunction, 1); + LLVMValueRef SumArg2 = LLVMGetParam(MulAddFunction, 2); + + LLVMValueRef MulArgs[] = {SumArg0, SumArg1}; + LLVMValueRef MulResult = LLVMBuildCall2(Builder, I32BinOpFunctionType, + MulI32Function, MulArgs, 2, "t"); + + LLVMValueRef AddArgs[] = {MulResult, SumArg2}; + LLVMValueRef AddResult = LLVMBuildCall2(Builder, I32BinOpFunctionType, + AddI32Function, AddArgs, 2, "r"); + + // - Build the return instruction. + LLVMBuildRet(Builder, AddResult); + + // Our demo module is now complete. Wrap it and our ThreadSafeContext in a + // ThreadSafeModule. + LLVMOrcThreadSafeModuleRef TSM = LLVMOrcCreateNewThreadSafeModule(M, TSCtx); + + // Dispose of our local ThreadSafeContext value. The underlying LLVMContext + // will be kept alive by our ThreadSafeModule, TSM. + LLVMOrcDisposeThreadSafeContext(TSCtx); + + // Return the result. + return TSM; +} + +int main(int argc, char *argv[]) { + + int MainResult = 0; + + // Parse command line arguments and initialize LLVM Core. + LLVMParseCommandLineOptions(argc, (const char **)argv, ""); + LLVMInitializeCore(LLVMGetGlobalPassRegistry()); + + // Initialize native target codegen and asm printer. + LLVMInitializeNativeTarget(); + LLVMInitializeNativeAsmPrinter(); + + // Create the JIT instance. + LLVMOrcLLJITRef J; + { + LLVMErrorRef Err; + if ((Err = LLVMOrcCreateLLJIT(&J, 0))) { + MainResult = handleError(Err); + goto llvm_shutdown; + } + } + + // Build a filter to allow JIT'd code to only access allowed symbols. + // This filter is optional: If a null value is suppled for the Filter + // argument to LLVMOrcCreateDynamicLibrarySearchGeneratorForProcess then + // all process symbols will be reflected. + LLVMOrcSymbolStringPoolEntryRef AllowList[] = { + LLVMOrcLLJITMangleAndIntern(J, "mul"), + LLVMOrcLLJITMangleAndIntern(J, "add"), 0}; + + { + LLVMOrcJITDylibDefinitionGeneratorRef ProcessSymbolsGenerator = 0; + LLVMErrorRef Err; + if ((Err = LLVMOrcCreateDynamicLibrarySearchGeneratorForProcess( + &ProcessSymbolsGenerator, LLVMOrcLLJITGetGlobalPrefix(J), + allowedSymbols, AllowList))) { + MainResult = handleError(Err); + goto jit_cleanup; + } + + LLVMOrcJITDylibAddGenerator(LLVMOrcLLJITGetMainJITDylib(J), + ProcessSymbolsGenerator); + } + + // Create our demo module. + LLVMOrcThreadSafeModuleRef TSM = createDemoModule(); + + // Add our demo module to the JIT. + { + LLVMOrcJITDylibRef MainJD = LLVMOrcLLJITGetMainJITDylib(J); + LLVMErrorRef Err; + if ((Err = LLVMOrcLLJITAddLLVMIRModule(J, MainJD, TSM))) { + // If adding the ThreadSafeModule fails then we need to clean it up + // ourselves. If adding it succeeds the JIT will manage the memory. + LLVMOrcDisposeThreadSafeModule(TSM); + MainResult = handleError(Err); + goto jit_cleanup; + } + } + + // Look up the address of our demo entry point. + LLVMOrcJITTargetAddress MulAddAddr; + { + LLVMErrorRef Err; + if ((Err = LLVMOrcLLJITLookup(J, &MulAddAddr, "mul_add"))) { + MainResult = handleError(Err); + goto jit_cleanup; + } + } + + // If we made it here then everything succeeded. Execute our JIT'd code. + int32_t (*MulAdd)(int32_t, int32_t, int32_t) = + (int32_t(*)(int32_t, int32_t, int32_t))MulAddAddr; + int32_t Result = MulAdd(3, 4, 5); + + // Print the result. + printf("3 * 4 + 5 = %i\n", Result); + +jit_cleanup: + // Release all symbol string pool entries that we have allocated. In this + // example that's just our allowed entries. + { + LLVMOrcSymbolStringPoolEntryRef *P = AllowList; + while (*P) + LLVMOrcReleaseSymbolStringPoolEntry(*P++); + } + + // Destroy our JIT instance. This will clean up any memory that the JIT has + // taken ownership of. This operation is non-trivial (e.g. it may need to + // JIT static destructors) and may also fail. In that case we want to render + // the error to stderr, but not overwrite any existing return value. + { + LLVMErrorRef Err; + if ((Err = LLVMOrcDisposeLLJIT(J))) { + int NewFailureResult = handleError(Err); + if (MainResult == 0) + MainResult = NewFailureResult; + } + } + +llvm_shutdown: + // Shut down LLVM. + LLVMShutdown(); + + return MainResult; +} diff --git a/gnu/llvm/llvm/examples/SpeculativeJIT/SpeculativeJIT.cpp b/gnu/llvm/llvm/examples/SpeculativeJIT/SpeculativeJIT.cpp index 3828e0a5f82..4de4897053c 100644 --- a/gnu/llvm/llvm/examples/SpeculativeJIT/SpeculativeJIT.cpp +++ b/gnu/llvm/llvm/examples/SpeculativeJIT/SpeculativeJIT.cpp @@ -102,7 +102,7 @@ private: IndirectStubsManagerBuilderFunction ISMBuilder, std::unique_ptr ProcessSymbolsGenerator) : ES(std::move(ES)), DL(std::move(DL)), - MainJD(this->ES->createJITDylib("
")), LCTMgr(std::move(LCTMgr)), + MainJD(this->ES->createBareJITDylib("
")), LCTMgr(std::move(LCTMgr)), CompileLayer(*this->ES, ObjLayer, std::make_unique(std::move(JTMB))), S(Imps, *this->ES), @@ -112,12 +112,15 @@ private: MainJD.addGenerator(std::move(ProcessSymbolsGenerator)); this->CODLayer.setImplMap(&Imps); this->ES->setDispatchMaterialization( - - [this](JITDylib &JD, std::unique_ptr MU) { + [this](std::unique_ptr MU, + MaterializationResponsibility MR) { // FIXME: Switch to move capture once we have C++14. auto SharedMU = std::shared_ptr(std::move(MU)); - auto Work = [SharedMU, &JD]() { SharedMU->doMaterialize(JD); }; - CompileThreads.async(std::move(Work)); + auto SharedMR = + std::make_shared(std::move(MR)); + CompileThreads.async([SharedMU, SharedMR]() { + SharedMU->materialize(std::move(*SharedMR)); + }); }); ExitOnErr(S.addSpeculationRuntime(MainJD, Mangle)); LocalCXXRuntimeOverrides CXXRuntimeoverrides; @@ -131,7 +134,7 @@ private: std::unique_ptr ES; DataLayout DL; MangleAndInterner Mangle{*ES, DL}; - ThreadPool CompileThreads{NumThreads}; + ThreadPool CompileThreads{llvm::hardware_concurrency(NumThreads)}; JITDylib &MainJD; diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/CMakeLists.txt b/gnu/llvm/llvm/examples/ThinLtoJIT/CMakeLists.txt new file mode 100644 index 00000000000..c2b52dc815f --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/CMakeLists.txt @@ -0,0 +1,19 @@ +set(LLVM_LINK_COMPONENTS + BitReader + Core + IRReader + OrcJIT + ExecutionEngine + Support + nativecodegen + Analysis + Passes + ) + +add_llvm_example(ThinLtoJIT + main.cpp + ThinLtoJIT.cpp + ThinLtoModuleIndex.cpp + ThinLtoInstrumentationLayer.cpp + ThinLtoDiscoveryThread.cpp + ) diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.cpp b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.cpp new file mode 100644 index 00000000000..203532436ab --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.cpp @@ -0,0 +1,65 @@ +#include "ThinLtoDiscoveryThread.h" + +#include "llvm/IR/GlobalValue.h" +#include "llvm/Support/Debug.h" +#include "llvm/Support/Error.h" + +#include "ThinLtoInstrumentationLayer.h" +#include "ThinLtoModuleIndex.h" + +#include + +#define DEBUG_TYPE "thinltojit" + +namespace llvm { +namespace orc { + +void ThinLtoDiscoveryThread::operator()() { + while (KeepRunning.load()) { + std::vector Indexes = Layer.takeFlagsThatFired(); + + if (!Indexes.empty()) { + LLVM_DEBUG(dbgs() << Indexes.size() << " new flags raised\n"); + auto ReachedFunctions = Layer.takeFlagOwners(std::move(Indexes)); + + for (GlobalValue::GUID F : ReachedFunctions) { + if (GlobalValueSummary *S = GlobalIndex.getSummary(F)) { + assert(isa(S) && "Reached symbols are functions"); + GlobalIndex.discoverCalleeModulePaths(cast(S), + LookaheadLevels); + } else { + LLVM_DEBUG(dbgs() << "No summary for GUID: " << F << "\n"); + } + } + + if (GlobalIndex.getNumDiscoveredModules() > 0) + spawnLookupForHighRankModules(); + } + } +} + +void ThinLtoDiscoveryThread::spawnLookupForHighRankModules() { + std::vector Paths = GlobalIndex.selectNextPaths(); + GlobalIndex.scheduleModuleParsing(Paths); + + // In order to add modules we need exclusive access to the execution session. + std::thread([this, Paths = std::move(Paths)]() { + ES.runSessionLocked([this, Paths = std::move(Paths)]() mutable { + for (const std::string &Path : Paths) { + ThreadSafeModule TSM = GlobalIndex.takeModule(Path); + if (!TSM) + // In the meantime the module was added synchronously. + continue; + + if (Error LoadErr = AddModule(std::move(TSM))) + // Failed to add the module to the session. + ES.reportError(std::move(LoadErr)); + + ++NumModulesSubmitted; + } + }); + }).detach(); +} + +} // namespace orc +} // namespace llvm diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.h b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.h new file mode 100644 index 00000000000..4ca3c95dee0 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.h @@ -0,0 +1,57 @@ +#ifndef LLVM_EXAMPLES_THINLTOJIT_DISCOVERYTHREAD_H +#define LLVM_EXAMPLES_THINLTOJIT_DISCOVERYTHREAD_H + +#include "llvm/ADT/StringRef.h" +#include "llvm/IR/ModuleSummaryIndex.h" + +#include "ThinLtoJIT.h" + +#include +#include + +namespace llvm { +namespace orc { + +class ExecutionSession; +class ThinLtoModuleIndex; +class ThinLtoInstrumentationLayer; + +class ThinLtoDiscoveryThread { +public: + ThinLtoDiscoveryThread(std::atomic &RunningFlag, ExecutionSession &ES, + JITDylib *MainJD, ThinLtoInstrumentationLayer &L, + ThinLtoModuleIndex &GlobalIndex, + ThinLtoJIT::AddModuleFunction AddModule, + unsigned LookaheadLevels, bool PrintStats) + : KeepRunning(RunningFlag), ES(ES), Layer(L), GlobalIndex(GlobalIndex), + AddModule(std::move(AddModule)), LookaheadLevels(LookaheadLevels), + PrintStats(PrintStats) {} + + ~ThinLtoDiscoveryThread() { + if (PrintStats) + dump(errs()); + } + + void operator()(); + + void dump(raw_ostream &OS) { + OS << format("Modules submitted asynchronously: %d\n", NumModulesSubmitted); + } + +private: + std::atomic &KeepRunning; + ExecutionSession &ES; + ThinLtoInstrumentationLayer &Layer; + ThinLtoModuleIndex &GlobalIndex; + ThinLtoJIT::AddModuleFunction AddModule; + unsigned LookaheadLevels; + bool PrintStats; + unsigned NumModulesSubmitted{0}; + + void spawnLookupForHighRankModules(); +}; + +} // namespace orc +} // namespace llvm + +#endif diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.cpp b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.cpp new file mode 100644 index 00000000000..345bfd8dd87 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.cpp @@ -0,0 +1,225 @@ +#include "ThinLtoInstrumentationLayer.h" + +#include "llvm/IR/BasicBlock.h" +#include "llvm/IR/Constants.h" +#include "llvm/IR/Function.h" +#include "llvm/IR/Module.h" +#include "llvm/IR/Type.h" +#include "llvm/Support/Debug.h" +#include "llvm/Support/Process.h" + +#include + +#define DEBUG_TYPE "thinltojit" + +namespace llvm { +namespace orc { + +// TODO: Fixed set of flags may not always be enough. Make this expandable. +void ThinLtoInstrumentationLayer::allocateDiscoveryFlags(unsigned MinFlags) { + // Round up to full memory pages. + unsigned PageSize = sys::Process::getPageSizeEstimate(); + unsigned NumPagesEach = (MinFlags + (PageSize - 1)) / PageSize; + unsigned NumPagesTotal = 2 * NumPagesEach; + assert(isPowerOf2_64(PageSize) && "Adjust aligned memory alloc below"); + + // Allocate one more page to make up for size loss due to alignment. + void *Storage = std::calloc(NumPagesTotal + 1, PageSize); + uint64_t StorageAddr = reinterpret_cast(Storage); + uint64_t PageSizeDecr = PageSize - 1; + uint64_t AlignedAddr = ((StorageAddr + PageSizeDecr) & ~PageSizeDecr); + uint64_t Diff = AlignedAddr - StorageAddr; + + // For each flag we allocate one byte in each location: Incoming and Handled. + // TODO: 'Handled' could be a bitset, but size must be dynamic + NumFlagsUsed.store(0); + NumFlagsAllocated = NumPagesEach * PageSize; + FlagsStorage = static_cast(Storage); + FlagsIncoming = reinterpret_cast(FlagsStorage + Diff); + FlagsHandled = FlagsIncoming + NumFlagsAllocated; + + static_assert(sizeof(FlagsIncoming[0]) == sizeof(uint8_t), "Flags are bytes"); + assert(reinterpret_cast(FlagsIncoming) % PageSize == 0); + assert(reinterpret_cast(FlagsHandled) % PageSize == 0); + assert(NumFlagsAllocated >= MinFlags); +} + +// Reserve a new set of discovery flags and return the index of the first one. +unsigned ThinLtoInstrumentationLayer::reserveDiscoveryFlags(unsigned Count) { +#ifndef NDEBUG + for (unsigned i = NumFlagsUsed.load(), e = i + Count; i < e; i++) { + assert(FlagsIncoming[i] == Clear); + } +#endif + + assert(Count > 0); + return NumFlagsUsed.fetch_add(Count); +} + +void ThinLtoInstrumentationLayer::registerDiscoveryFlagOwners( + std::vector Guids, unsigned FirstIdx) { + unsigned Count = Guids.size(); + + std::lock_guard Lock(DiscoveryFlagsInfoLock); + for (unsigned i = 0; i < Count; i++) { + assert(!FlagOwnersMap.count(FirstIdx + i) && + "Flag should not have an owner at this point"); + FlagOwnersMap[FirstIdx + i] = Guids[i]; + } +} + +std::vector ThinLtoInstrumentationLayer::takeFlagsThatFired() { + // This is only effective with the respective Release. + FlagsSync.load(std::memory_order_acquire); + + std::vector Indexes; + unsigned NumIndexesUsed = NumFlagsUsed.load(); + for (unsigned i = 0; i < NumIndexesUsed; i++) { + if (FlagsIncoming[i] == Fired && FlagsHandled[i] == Clear) { + FlagsHandled[i] = Fired; + Indexes.push_back(i); + } + } + + return Indexes; +} + +std::vector +ThinLtoInstrumentationLayer::takeFlagOwners(std::vector Indexes) { + std::vector ReachedFunctions; + std::lock_guard Lock(DiscoveryFlagsInfoLock); + + for (unsigned i : Indexes) { + auto KV = FlagOwnersMap.find(i); + assert(KV != FlagOwnersMap.end()); + ReachedFunctions.push_back(KV->second); + FlagOwnersMap.erase(KV); + } + + return ReachedFunctions; +} + +void ThinLtoInstrumentationLayer::nudgeIntoDiscovery( + std::vector Functions) { + unsigned Count = Functions.size(); + + // Registering synthetic flags in advance. We expect them to get processed + // before the respective functions get emitted. If not, the emit() function + unsigned FirstFlagIdx = reserveDiscoveryFlags(Functions.size()); + registerDiscoveryFlagOwners(std::move(Functions), FirstFlagIdx); + + // Initialize the flags as fired and force a cache sync, so discovery will + // pick them up as soon as possible. + for (unsigned i = FirstFlagIdx; i < FirstFlagIdx + Count; i++) { + FlagsIncoming[i] = Fired; + } + if (MemFence & ThinLtoJIT::FenceStaticCode) { + FlagsSync.store(0, std::memory_order_release); + } + + LLVM_DEBUG(dbgs() << "Nudged " << Count << " new functions into discovery\n"); +} + +void ThinLtoInstrumentationLayer::emit(MaterializationResponsibility R, + ThreadSafeModule TSM) { + TSM.withModuleDo([this](Module &M) { + std::vector FunctionsToInstrument; + + // We may have discovered ahead of some functions already, but we still + // instrument them all. Their notifications steer the future direction of + // discovery. + for (Function &F : M.getFunctionList()) + if (!F.isDeclaration()) + FunctionsToInstrument.push_back(&F); + + if (!FunctionsToInstrument.empty()) { + IRBuilder<> B(M.getContext()); + std::vector NewDiscoveryRoots; + + // Flags that fire must have owners registered. We will do it below and + // that's fine, because they can only be reached once the code is emitted. + unsigned FirstFlagIdx = + reserveDiscoveryFlags(FunctionsToInstrument.size()); + + unsigned NextFlagIdx = FirstFlagIdx; + for (Function *F : FunctionsToInstrument) { + // TODO: Emitting the write operation into an indirection stub would + // allow to skip it once we got the notification. + BasicBlock *E = &F->getEntryBlock(); + B.SetInsertPoint(BasicBlock::Create( + M.getContext(), "NotifyFunctionReachedProlog", F, E)); + compileFunctionReachedFlagSetter(B, FlagsIncoming + NextFlagIdx); + B.CreateBr(E); + + std::string GlobalName = GlobalValue::getGlobalIdentifier( + F->getName(), F->getLinkage(), M.getSourceFileName()); + NewDiscoveryRoots.push_back(GlobalValue::getGUID(GlobalName)); + ++NextFlagIdx; + } + + LLVM_DEBUG(dbgs() << "Instrumented " << NewDiscoveryRoots.size() + << " new functions in module " << M.getName() << "\n"); + + // Submit owner info, so the DiscoveryThread can evaluate the flags. + registerDiscoveryFlagOwners(std::move(NewDiscoveryRoots), FirstFlagIdx); + } + }); + + BaseLayer.emit(std::move(R), std::move(TSM)); +} + +void ThinLtoInstrumentationLayer::compileFunctionReachedFlagSetter( + IRBuilder<> &B, Flag *F) { + assert(*F == Clear); + Type *Int64Ty = Type::getInt64Ty(B.getContext()); + + // Write one immediate 8bit value to a fixed location in memory. + auto FlagAddr = pointerToJITTargetAddress(F); + Type *FlagTy = Type::getInt8Ty(B.getContext()); + B.CreateStore(ConstantInt::get(FlagTy, Fired), + B.CreateIntToPtr(ConstantInt::get(Int64Ty, FlagAddr), + FlagTy->getPointerTo())); + + if (MemFence & ThinLtoJIT::FenceJITedCode) { + // Overwrite the sync value with Release ordering. The discovery thread + // reads it with Acquire ordering. The actual value doesn't matter. + static constexpr bool IsVolatile = true; + static constexpr Instruction *NoInsertBefore = nullptr; + auto SyncFlagAddr = pointerToJITTargetAddress(&FlagsSync); + + B.Insert( + new StoreInst(ConstantInt::get(Int64Ty, 0), + B.CreateIntToPtr(ConstantInt::get(Int64Ty, SyncFlagAddr), + Int64Ty->getPointerTo()), + IsVolatile, Align(64), AtomicOrdering::Release, + SyncScope::System, NoInsertBefore)); + } +} + +void ThinLtoInstrumentationLayer::dump(raw_ostream &OS) { + OS << "Discovery flags stats\n"; + + unsigned NumFlagsFired = 0; + for (unsigned i = 0; i < NumFlagsAllocated; i++) { + if (FlagsIncoming[i] == Fired) + ++NumFlagsFired; + } + OS << "Alloc: " << format("%6.d", NumFlagsAllocated) << "\n"; + OS << "Issued: " << format("%6.d", NumFlagsUsed.load()) << "\n"; + OS << "Fired: " << format("%6.d", NumFlagsFired) << "\n"; + + unsigned RemainingFlagOwners = 0; + for (const auto &_ : FlagOwnersMap) { + ++RemainingFlagOwners; + (void)_; + } + OS << "\nFlagOwnersMap has " << RemainingFlagOwners + << " remaining entries.\n"; +} + +ThinLtoInstrumentationLayer::~ThinLtoInstrumentationLayer() { + std::free(FlagsStorage); +} + +} // namespace orc +} // namespace llvm diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.h b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.h new file mode 100644 index 00000000000..cd872078947 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.h @@ -0,0 +1,77 @@ +#ifndef LLVM_EXAMPLES_THINLTOJIT_DISCOVERYLAYER_H +#define LLVM_EXAMPLES_THINLTOJIT_DISCOVERYLAYER_H + +#include "llvm/ExecutionEngine/JITSymbol.h" +#include "llvm/ExecutionEngine/Orc/Core.h" +#include "llvm/ExecutionEngine/Orc/IRCompileLayer.h" +#include "llvm/ExecutionEngine/Orc/Layer.h" +#include "llvm/ExecutionEngine/Orc/ThreadSafeModule.h" +#include "llvm/IR/GlobalValue.h" +#include "llvm/IR/IRBuilder.h" +#include "llvm/Support/raw_ostream.h" + +#include "ThinLtoJIT.h" + +#include +#include +#include +#include +#include + +namespace llvm { +namespace orc { + +class ThinLtoInstrumentationLayer : public IRLayer { +public: + ThinLtoInstrumentationLayer(ExecutionSession &ES, IRCompileLayer &BaseLayer, + ThinLtoJIT::ExplicitMemoryBarrier MemFence, + unsigned FlagsPerBucket) + : IRLayer(ES, BaseLayer.getManglingOptions()), BaseLayer(BaseLayer), + MemFence(MemFence) { + // TODO: So far we only allocate one bucket. + allocateDiscoveryFlags(FlagsPerBucket); + } + + ~ThinLtoInstrumentationLayer() override; + + void emit(MaterializationResponsibility R, ThreadSafeModule TSM) override; + + unsigned reserveDiscoveryFlags(unsigned Count); + void registerDiscoveryFlagOwners(std::vector Guids, + unsigned FirstIdx); + + void nudgeIntoDiscovery(std::vector Functions); + + std::vector takeFlagsThatFired(); + std::vector takeFlagOwners(std::vector Indexes); + + void dump(raw_ostream &OS); + +private: + IRCompileLayer &BaseLayer; + ThinLtoJIT::ExplicitMemoryBarrier MemFence; + + enum Flag : uint8_t { Clear = 0, Fired = 1 }; + + // Lock-free read access. + uint8_t *FlagsStorage; + Flag *FlagsIncoming; // lock-free write by design + Flag *FlagsHandled; + unsigned NumFlagsAllocated; + std::atomic NumFlagsUsed; // spin-lock + + // Acquire/release sync between writers and reader + std::atomic FlagsSync; + + // STL container requires locking for both, read and write access. + mutable std::mutex DiscoveryFlagsInfoLock; + std::map FlagOwnersMap; + + void allocateDiscoveryFlags(unsigned MinFlags); + void compileFunctionReachedFlagSetter(IRBuilder<> &B, Flag *F); +}; + +} // namespace orc +} // namespace llvm + +#endif diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoJIT.cpp b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoJIT.cpp new file mode 100644 index 00000000000..f5c2b0696f5 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoJIT.cpp @@ -0,0 +1,340 @@ +#include "ThinLtoJIT.h" + +#include "llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h" +#include "llvm/ExecutionEngine/Orc/CompileUtils.h" +#include "llvm/ExecutionEngine/Orc/ExecutionUtils.h" +#include "llvm/ExecutionEngine/Orc/IRCompileLayer.h" +#include "llvm/ExecutionEngine/Orc/IndirectionUtils.h" +#include "llvm/ExecutionEngine/Orc/JITTargetMachineBuilder.h" +#include "llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h" +#include "llvm/ExecutionEngine/SectionMemoryManager.h" +#include "llvm/Support/Debug.h" +#include "llvm/Support/Host.h" + +#include "ThinLtoDiscoveryThread.h" +#include "ThinLtoInstrumentationLayer.h" +#include "ThinLtoModuleIndex.h" + +#include +#include +#include + +#ifndef NDEBUG +#include +#endif + +#define DEBUG_TYPE "thinltojit" + +namespace llvm { +namespace orc { + +class ThinLtoDefinitionGenerator : public JITDylib::DefinitionGenerator { +public: + ThinLtoDefinitionGenerator(ThinLtoModuleIndex &GlobalIndex, + ThinLtoInstrumentationLayer &InstrumentationLayer, + ThinLtoJIT::AddModuleFunction AddModule, + char Prefix, bool AllowNudge, bool PrintStats) + : GlobalIndex(GlobalIndex), InstrumentationLayer(InstrumentationLayer), + AddModule(std::move(AddModule)), ManglePrefix(Prefix), + AllowNudgeIntoDiscovery(AllowNudge), PrintStats(PrintStats) {} + + ~ThinLtoDefinitionGenerator() { + if (PrintStats) + dump(errs()); + } + + Error tryToGenerate(LookupKind K, JITDylib &JD, + JITDylibLookupFlags JDLookupFlags, + const SymbolLookupSet &Symbols) override; + + void dump(raw_ostream &OS) { + OS << format("Modules submitted synchronously: %d\n", NumModulesMissed); + } + +private: + ThinLtoModuleIndex &GlobalIndex; + ThinLtoInstrumentationLayer &InstrumentationLayer; + ThinLtoJIT::AddModuleFunction AddModule; + char ManglePrefix; + bool AllowNudgeIntoDiscovery; + bool PrintStats; + unsigned NumModulesMissed{0}; + + // ThinLTO summaries encode unprefixed names. + StringRef stripGlobalManglePrefix(StringRef Symbol) const { + bool Strip = (ManglePrefix != '\0' && Symbol[0] == ManglePrefix); + return Strip ? StringRef(Symbol.data() + 1, Symbol.size() - 1) : Symbol; + } +}; + +Error ThinLtoDefinitionGenerator::tryToGenerate( + LookupKind K, JITDylib &JD, JITDylibLookupFlags JDLookupFlags, + const SymbolLookupSet &Symbols) { + std::set ModulePaths; + std::vector NewDiscoveryRoots; + + for (const auto &KV : Symbols) { + StringRef UnmangledName = stripGlobalManglePrefix(*KV.first); + auto Guid = GlobalValue::getGUID(UnmangledName); + if (GlobalValueSummary *S = GlobalIndex.getSummary(Guid)) { + // We could have discovered it ahead of time. + LLVM_DEBUG(dbgs() << format("Failed to discover symbol: %s\n", + UnmangledName.str().c_str())); + ModulePaths.insert(S->modulePath()); + if (AllowNudgeIntoDiscovery && isa(S)) { + NewDiscoveryRoots.push_back(Guid); + } + } + } + + NumModulesMissed += ModulePaths.size(); + + // Parse the requested modules if it hasn't happened yet. + GlobalIndex.scheduleModuleParsing(ModulePaths); + + for (StringRef Path : ModulePaths) { + ThreadSafeModule TSM = GlobalIndex.takeModule(Path); + assert(TSM && "We own the session lock, no asynchronous access possible"); + + if (Error LoadErr = AddModule(std::move(TSM))) + // Failed to add the module to the session. + return LoadErr; + + LLVM_DEBUG(dbgs() << "Generator: added " << Path << " synchronously\n"); + } + + // Requested functions that we failed to discover ahead of time, are likely + // close to the execution front. We can anticipate to run into them as soon + // as execution continues and trigger their discovery flags already now. This + // behavior is enabled with the 'allow-nudge' option and implemented below. + // On the one hand, it may give us a head start in a moment where discovery + // was lacking behind. On the other hand, we may bet on the wrong horse and + // waste extra time speculating in the wrong direction. + if (!NewDiscoveryRoots.empty()) { + assert(AllowNudgeIntoDiscovery); + InstrumentationLayer.nudgeIntoDiscovery(std::move(NewDiscoveryRoots)); + } + + return Error::success(); +} + +ThinLtoJIT::ThinLtoJIT(ArrayRef InputFiles, + StringRef MainFunctionName, unsigned LookaheadLevels, + unsigned NumCompileThreads, unsigned NumLoadThreads, + unsigned DiscoveryFlagsPerBucket, + ExplicitMemoryBarrier MemFence, + bool AllowNudgeIntoDiscovery, bool PrintStats, + Error &Err) { + ErrorAsOutParameter ErrAsOutParam(&Err); + + // Populate the module index, so we know which modules exist and we can find + // the one that defines the main function. + GlobalIndex = std::make_unique(ES, NumLoadThreads); + for (StringRef F : InputFiles) { + if (auto Err = GlobalIndex->add(F)) + ES.reportError(std::move(Err)); + } + + // Load the module that defines the main function. + auto TSM = setupMainModule(MainFunctionName); + if (!TSM) { + Err = TSM.takeError(); + return; + } + + // Infer target-specific utils from the main module. + ThreadSafeModule MainModule = std::move(*TSM); + auto JTMB = setupTargetUtils(MainModule.getModuleUnlocked()); + if (!JTMB) { + Err = JTMB.takeError(); + return; + } + + // Set up the JIT compile pipeline. + setupLayers(std::move(*JTMB), NumCompileThreads, DiscoveryFlagsPerBucket, + MemFence); + + // We can use the mangler now. Remember the mangled name of the main function. + MainFunctionMangled = (*Mangle)(MainFunctionName); + + // We are restricted to a single dylib currently. Add runtime overrides and + // symbol generators. + MainJD = &ES.createBareJITDylib("main"); + Err = setupJITDylib(MainJD, AllowNudgeIntoDiscovery, PrintStats); + if (Err) + return; + + // Spawn discovery thread and let it add newly discovered modules to the JIT. + setupDiscovery(MainJD, LookaheadLevels, PrintStats); + + Err = AddModule(std::move(MainModule)); + if (Err) + return; + + if (AllowNudgeIntoDiscovery) { + auto MainFunctionGuid = GlobalValue::getGUID(MainFunctionName); + InstrumentationLayer->nudgeIntoDiscovery({MainFunctionGuid}); + } +} + +Expected ThinLtoJIT::setupMainModule(StringRef MainFunction) { + Optional M = GlobalIndex->getModulePathForSymbol(MainFunction); + if (!M) { + std::string Buffer; + raw_string_ostream OS(Buffer); + OS << "No ValueInfo for symbol '" << MainFunction; + OS << "' in provided modules: "; + for (StringRef P : GlobalIndex->getAllModulePaths()) + OS << P << " "; + OS << "\n"; + return createStringError(inconvertibleErrorCode(), OS.str()); + } + + if (auto TSM = GlobalIndex->parseModuleFromFile(*M)) + return std::move(TSM); // Not a redundant move: fix build on gcc-7.5 + + return createStringError(inconvertibleErrorCode(), + "Failed to parse main module"); +} + +Expected ThinLtoJIT::setupTargetUtils(Module *M) { + std::string T = M->getTargetTriple(); + JITTargetMachineBuilder JTMB(Triple(T.empty() ? sys::getProcessTriple() : T)); + + // CallThroughManager is ABI-specific + auto LCTM = createLocalLazyCallThroughManager( + JTMB.getTargetTriple(), ES, + pointerToJITTargetAddress(exitOnLazyCallThroughFailure)); + if (!LCTM) + return LCTM.takeError(); + CallThroughManager = std::move(*LCTM); + + // Use DataLayout or the given module or fall back to the host's default. + DL = DataLayout(M); + if (DL.getStringRepresentation().empty()) { + auto HostDL = JTMB.getDefaultDataLayoutForTarget(); + if (!HostDL) + return HostDL.takeError(); + DL = std::move(*HostDL); + if (Error Err = applyDataLayout(M)) + return std::move(Err); + } + + // Now that we know the target data layout we can setup the mangler. + Mangle = std::make_unique(ES, DL); + return JTMB; +} + +Error ThinLtoJIT::applyDataLayout(Module *M) { + if (M->getDataLayout().isDefault()) + M->setDataLayout(DL); + + if (M->getDataLayout() != DL) + return make_error( + "Added modules have incompatible data layouts", + inconvertibleErrorCode()); + + return Error::success(); +} + +static bool IsTrivialModule(MaterializationUnit *MU) { + StringRef ModuleName = MU->getName(); + return ModuleName == "" || ModuleName == "" || + ModuleName == ""; +} + +void ThinLtoJIT::setupLayers(JITTargetMachineBuilder JTMB, + unsigned NumCompileThreads, + unsigned DiscoveryFlagsPerBucket, + ExplicitMemoryBarrier MemFence) { + ObjLinkingLayer = std::make_unique( + ES, []() { return std::make_unique(); }); + + CompileLayer = std::make_unique( + ES, *ObjLinkingLayer, std::make_unique(JTMB)); + + InstrumentationLayer = std::make_unique( + ES, *CompileLayer, MemFence, DiscoveryFlagsPerBucket); + + OnDemandLayer = std::make_unique( + ES, *InstrumentationLayer, *CallThroughManager, + createLocalIndirectStubsManagerBuilder(JTMB.getTargetTriple())); + // Don't break up modules. Insert stubs on module boundaries. + OnDemandLayer->setPartitionFunction(CompileOnDemandLayer::compileWholeModule); + + // Delegate compilation to the thread pool. + CompileThreads = std::make_unique( + llvm::hardware_concurrency(NumCompileThreads)); + ES.setDispatchMaterialization( + [this](std::unique_ptr MU, + MaterializationResponsibility MR) { + if (IsTrivialModule(MU.get())) { + // This should be quick and we may save a few session locks. + MU->materialize(std::move(MR)); + } else { + // FIXME: Drop the std::shared_ptr workaround once ThreadPool::async() + // accepts llvm::unique_function to define jobs. + auto SharedMU = std::shared_ptr(std::move(MU)); + auto SharedMR = + std::make_shared(std::move(MR)); + CompileThreads->async( + [MU = std::move(SharedMU), MR = std::move(SharedMR)]() { + MU->materialize(std::move(*MR)); + }); + } + }); + + AddModule = [this](ThreadSafeModule TSM) -> Error { + assert(MainJD && "Setup MainJD JITDylib before calling"); + Module *M = TSM.getModuleUnlocked(); + if (Error Err = applyDataLayout(M)) + return Err; + VModuleKey Id = GlobalIndex->getModuleId(M->getName()); + return OnDemandLayer->add(*MainJD, std::move(TSM), Id); + }; +} + +void ThinLtoJIT::setupDiscovery(JITDylib *MainJD, unsigned LookaheadLevels, + bool PrintStats) { + JitRunning.store(true); + DiscoveryThreadWorker = std::make_unique( + JitRunning, ES, MainJD, *InstrumentationLayer, *GlobalIndex, AddModule, + LookaheadLevels, PrintStats); + + DiscoveryThread = std::thread(std::ref(*DiscoveryThreadWorker)); +} + +Error ThinLtoJIT::setupJITDylib(JITDylib *JD, bool AllowNudge, + bool PrintStats) { + // Register symbols for C++ static destructors. + LocalCXXRuntimeOverrides CXXRuntimeoverrides; + Error Err = CXXRuntimeoverrides.enable(*JD, *Mangle); + if (Err) + return Err; + + // Lookup symbol names in the global ThinLTO module index first + char Prefix = DL.getGlobalPrefix(); + JD->addGenerator(std::make_unique( + *GlobalIndex, *InstrumentationLayer, AddModule, Prefix, AllowNudge, + PrintStats)); + + // Then try lookup in the host process. + auto HostLookup = DynamicLibrarySearchGenerator::GetForCurrentProcess(Prefix); + if (!HostLookup) + return HostLookup.takeError(); + JD->addGenerator(std::move(*HostLookup)); + + return Error::success(); +} + +ThinLtoJIT::~ThinLtoJIT() { + // Signal the DiscoveryThread to shut down. + JitRunning.store(false); + DiscoveryThread.join(); + + // Wait for potential compile actions to finish. + CompileThreads->wait(); +} + +} // namespace orc +} // namespace llvm diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoJIT.h b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoJIT.h new file mode 100644 index 00000000000..4c2fddfd577 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoJIT.h @@ -0,0 +1,111 @@ +#ifndef LLVM_EXAMPLES_THINLTOJIT_THINLTOJIT_H +#define LLVM_EXAMPLES_THINLTOJIT_THINLTOJIT_H + +#include "llvm/ADT/StringRef.h" +#include "llvm/ADT/Triple.h" +#include "llvm/ExecutionEngine/Orc/Core.h" +#include "llvm/ExecutionEngine/Orc/ExecutionUtils.h" +#include "llvm/ExecutionEngine/Orc/SymbolStringPool.h" +#include "llvm/ExecutionEngine/Orc/ThreadSafeModule.h" +#include "llvm/IR/DataLayout.h" +#include "llvm/Support/Error.h" +#include "llvm/Support/ThreadPool.h" + +#include +#include +#include +#include +#include + +namespace llvm { +namespace orc { + +class ThinLtoDiscoveryThread; +class ThinLtoInstrumentationLayer; +class ThinLtoModuleIndex; + +class CompileOnDemandLayer; +class IRCompileLayer; +class RTDyldObjectLinkingLayer; + +class JITDylib; +class JITTargetMachineBuilder; +class LazyCallThroughManager; +class MangleAndInterner; + +class ThinLtoJIT { +public: + using AddModuleFunction = std::function; + + enum ExplicitMemoryBarrier { + NeverFence = 0, + FenceStaticCode = 1, + FenceJITedCode = 2, + AlwaysFence = 3 + }; + + ThinLtoJIT(ArrayRef InputFiles, StringRef MainFunctionName, + unsigned LookaheadLevels, unsigned NumCompileThreads, + unsigned NumLoadThreads, unsigned DiscoveryFlagsPerBucket, + ExplicitMemoryBarrier MemFence, bool AllowNudgeIntoDiscovery, + bool PrintStats, Error &Err); + ~ThinLtoJIT(); + + ThinLtoJIT(const ThinLtoJIT &) = delete; + ThinLtoJIT &operator=(const ThinLtoJIT &) = delete; + ThinLtoJIT(ThinLtoJIT &&) = delete; + ThinLtoJIT &operator=(ThinLtoJIT &&) = delete; + + Expected main(ArrayRef Args) { + auto MainSym = ES.lookup({MainJD}, MainFunctionMangled); + if (!MainSym) + return MainSym.takeError(); + + using MainFn = int(int, char *[]); + auto Main = jitTargetAddressToFunction(MainSym->getAddress()); + + return runAsMain(Main, Args, StringRef("ThinLtoJIT")); + } + +private: + ExecutionSession ES; + DataLayout DL{""}; + + JITDylib *MainJD; + SymbolStringPtr MainFunctionMangled; + std::unique_ptr CompileThreads; + std::unique_ptr GlobalIndex; + + AddModuleFunction AddModule; + std::unique_ptr ObjLinkingLayer; + std::unique_ptr CompileLayer; + std::unique_ptr InstrumentationLayer; + std::unique_ptr OnDemandLayer; + + std::atomic JitRunning; + std::thread DiscoveryThread; + std::unique_ptr DiscoveryThreadWorker; + + std::unique_ptr Mangle; + std::unique_ptr CallThroughManager; + + void setupLayers(JITTargetMachineBuilder JTMB, unsigned NumCompileThreads, + unsigned DiscoveryFlagsPerBucket, + ExplicitMemoryBarrier MemFence); + Error setupJITDylib(JITDylib *JD, bool AllowNudge, bool PrintStats); + void setupDiscovery(JITDylib *MainJD, unsigned LookaheadLevels, + bool PrintStats); + Expected setupMainModule(StringRef MainFunction); + Expected setupTargetUtils(Module *M); + Error applyDataLayout(Module *M); + + static void exitOnLazyCallThroughFailure() { + errs() << "Compilation failed. Aborting.\n"; + exit(1); + } +}; + +} // namespace orc +} // namespace llvm + +#endif diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoModuleIndex.cpp b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoModuleIndex.cpp new file mode 100644 index 00000000000..42ee43f1091 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoModuleIndex.cpp @@ -0,0 +1,268 @@ +#include "ThinLtoModuleIndex.h" + +#include "llvm/Bitcode/BitcodeReader.h" +#include "llvm/ExecutionEngine/Orc/SymbolStringPool.h" +#include "llvm/IR/LLVMContext.h" +#include "llvm/IRReader/IRReader.h" +#include "llvm/Support/SourceMgr.h" +#include "llvm/Support/raw_ostream.h" + +#include +#include + +#define DEBUG_TYPE "thinltojit" + +namespace llvm { +namespace orc { + +Error ThinLtoModuleIndex::add(StringRef InputPath) { + auto Buffer = errorOrToExpected(MemoryBuffer::getFile(InputPath)); + if (!Buffer) + return Buffer.takeError(); + + Error ParseErr = readModuleSummaryIndex((*Buffer)->getMemBufferRef(), + CombinedSummaryIndex, NextModuleId); + if (ParseErr) + return ParseErr; + +#ifndef NDEBUG + auto Paths = getAllModulePaths(); + unsigned TotalPaths = Paths.size(); + std::sort(Paths.begin(), Paths.end()); + Paths.erase(std::unique(Paths.begin(), Paths.end()), Paths.end()); + assert(TotalPaths == Paths.size() && "Module paths must be unique"); +#endif + + ++NextModuleId; + return Error::success(); +} + +std::vector ThinLtoModuleIndex::getAllModulePaths() const { + auto ModuleTable = CombinedSummaryIndex.modulePaths(); + + std::vector Paths; + Paths.resize(ModuleTable.size()); + + for (const auto &KV : ModuleTable) { + assert(Paths[KV.second.first].empty() && "IDs are unique and continuous"); + Paths[KV.second.first] = KV.first(); + } + + return Paths; +} + +GlobalValueSummary * +ThinLtoModuleIndex::getSummary(GlobalValue::GUID Function) const { + ValueInfo VI = CombinedSummaryIndex.getValueInfo(Function); + if (!VI || VI.getSummaryList().empty()) + return nullptr; + + // There can be more than one symbol with the same GUID, in the case of same- + // named locals in different but same-named source files that were compiled in + // their respective directories (so the source file name and resulting GUID is + // the same). We avoid this by checking that module paths are unique upon + // add(). + // + // TODO: We can still get duplicates on symbols declared with + // attribute((weak)), a GNU extension supported by gcc and clang. + // We should support it by looking for a symbol in the current module + // or in the same module as the caller. + assert(VI.getSummaryList().size() == 1 && "Weak symbols not yet supported"); + + return VI.getSummaryList().front().get()->getBaseObject(); +} + +Optional +ThinLtoModuleIndex::getModulePathForSymbol(StringRef Name) const { + if (GlobalValueSummary *S = getSummary(GlobalValue::getGUID(Name))) + return S->modulePath(); + return None; // We don't know the symbol. +} + +void ThinLtoModuleIndex::scheduleModuleParsingPrelocked(StringRef Path) { + // Once the module was scheduled, we can call takeModule(). + auto ScheduledIt = ScheduledModules.find(Path); + if (ScheduledIt != ScheduledModules.end()) + return; + + auto Worker = [this](std::string Path) { + if (auto TSM = doParseModule(Path)) { + std::lock_guard Lock(ParsedModulesLock); + ParsedModules[Path] = std::move(*TSM); + + LLVM_DEBUG(dbgs() << "Finished parsing module: " << Path << "\n"); + } else { + ES.reportError(TSM.takeError()); + } + }; + + LLVM_DEBUG(dbgs() << "Schedule module for parsing: " << Path << "\n"); + ScheduledModules[Path] = ParseModuleWorkers.async(Worker, Path.str()); +} + +ThreadSafeModule ThinLtoModuleIndex::takeModule(StringRef Path) { + std::unique_lock ParseLock(ParsedModulesLock); + + auto ParsedIt = ParsedModules.find(Path); + if (ParsedIt == ParsedModules.end()) { + ParseLock.unlock(); + + // The module is not ready, wait for the future we stored. + std::unique_lock ScheduleLock(ScheduledModulesLock); + auto ScheduledIt = ScheduledModules.find(Path); + assert(ScheduledIt != ScheduledModules.end() && + "Don't call for unscheduled modules"); + std::shared_future Future = ScheduledIt->getValue(); + ScheduleLock.unlock(); + Future.get(); + + ParseLock.lock(); + ParsedIt = ParsedModules.find(Path); + assert(ParsedIt != ParsedModules.end() && "Must be ready now"); + } + + // We only add each module once. If it's not here anymore, we can skip it. + ThreadSafeModule TSM = std::move(ParsedIt->getValue()); + ParsedIt->getValue() = ThreadSafeModule(); + return TSM; +} + +ThreadSafeModule ThinLtoModuleIndex::parseModuleFromFile(StringRef Path) { + { + std::lock_guard ScheduleLock(ScheduledModulesLock); + scheduleModuleParsingPrelocked(Path); + } + return takeModule(Path); +} + +Expected ThinLtoModuleIndex::doParseModule(StringRef Path) { + // TODO: make a SMDiagnosticError class for this + SMDiagnostic Err; + auto Ctx = std::make_unique(); + auto M = parseIRFile(Path, Err, *Ctx); + if (!M) { + std::string ErrDescription; + { + raw_string_ostream S(ErrDescription); + Err.print("ThinLtoJIT", S); + } + return createStringError(inconvertibleErrorCode(), + "Failed to load module from file '%s' (%s)", + Path.data(), ErrDescription.c_str()); + } + + return ThreadSafeModule(std::move(M), std::move(Ctx)); +} + +// We don't filter visited functions. Discovery will often be retriggered +// from the middle of already visited functions and it aims to reach a little +// further each time. +void ThinLtoModuleIndex::discoverCalleeModulePaths(FunctionSummary *S, + unsigned LookaheadLevels) { + // Populate initial worklist + std::vector Worklist; + addToWorklist(Worklist, S->calls()); + unsigned Distance = 0; + + while (++Distance < LookaheadLevels) { + // Process current worklist and populate a new one. + std::vector NextWorklist; + for (FunctionSummary *F : Worklist) { + updatePathRank(F->modulePath(), Distance); + addToWorklist(NextWorklist, F->calls()); + } + Worklist = std::move(NextWorklist); + } + + // Process the last worklist without filling a new one + for (FunctionSummary *F : Worklist) { + updatePathRank(F->modulePath(), Distance); + } + + // Reset counts for known paths (includes both, scheduled and parsed modules). + std::lock_guard Lock(ScheduledModulesLock); + for (const auto &KV : ScheduledModules) { + PathRank[KV.first()].Count = 0; + } +} + +void ThinLtoModuleIndex::addToWorklist( + std::vector &List, + ArrayRef Calls) { + for (const auto &Edge : Calls) { + const auto &SummaryList = Edge.first.getSummaryList(); + if (!SummaryList.empty()) { + GlobalValueSummary *S = SummaryList.front().get()->getBaseObject(); + assert(isa(S) && "Callees must be functions"); + List.push_back(cast(S)); + } + } +} + +// PathRank is global and continuous. +void ThinLtoModuleIndex::updatePathRank(StringRef Path, unsigned Distance) { + auto &Entry = PathRank[Path]; + Entry.Count += 1; + Entry.MinDist = std::min(Entry.MinDist, Distance); + assert(Entry.MinDist > 0 && "We want it as a divisor"); +} + +// TODO: The size of a ThreadPool's task queue is not accessible. It would +// be great to know in order to estimate how many modules we schedule. The +// more we schedule, the less precise is the ranking. The less we schedule, +// the higher the risk for downtime. +std::vector ThinLtoModuleIndex::selectNextPaths() { + struct ScorePath { + float Score; + unsigned MinDist; + StringRef Path; + }; + + std::vector Candidates; + Candidates.reserve(PathRank.size()); + for (const auto &KV : PathRank) { + float Score = static_cast(KV.second.Count) / KV.second.MinDist; + if (Score > .0f) { + Candidates.push_back({Score, KV.second.MinDist, KV.first()}); + } + } + + // Sort candidates by descending score. + std::sort(Candidates.begin(), Candidates.end(), + [](const ScorePath &LHS, const ScorePath &RHS) { + return LHS.Score > RHS.Score; + }); + + // Sort highest score candidates by ascending minimal distance. + size_t Selected = + std::min(std::max(NumParseModuleThreads, Candidates.size() / 2), + Candidates.size()); + std::sort(Candidates.begin(), Candidates.begin() + Selected, + [](const ScorePath &LHS, const ScorePath &RHS) { + return LHS.MinDist < RHS.MinDist; + }); + + std::vector Paths; + Paths.reserve(Selected); + for (unsigned i = 0; i < Selected; i++) { + Paths.push_back(Candidates[i].Path.str()); + } + + LLVM_DEBUG(dbgs() << "ModuleIndex: select " << Paths.size() << " out of " + << Candidates.size() << " discovered paths\n"); + + return Paths; +} + +unsigned ThinLtoModuleIndex::getNumDiscoveredModules() const { + // TODO: It would probably be more efficient to track the number of + // unscheduled modules. + unsigned NonNullItems = 0; + for (const auto &KV : PathRank) + if (KV.second.Count > 0) + ++NonNullItems; + return NonNullItems; +} + +} // namespace orc +} // namespace llvm diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoModuleIndex.h b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoModuleIndex.h new file mode 100644 index 00000000000..29a24a0c5e1 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/ThinLtoModuleIndex.h @@ -0,0 +1,94 @@ +#ifndef LLVM_EXAMPLES_THINLTOJIT_THINLTOJITMODULEINDEX_H +#define LLVM_EXAMPLES_THINLTOJIT_THINLTOJITMODULEINDEX_H + +#include "llvm/ADT/Optional.h" +#include "llvm/ExecutionEngine/Orc/Core.h" +#include "llvm/ExecutionEngine/Orc/ThreadSafeModule.h" +#include "llvm/IR/GlobalValue.h" +#include "llvm/IR/ModuleSummaryIndex.h" +#include "llvm/Support/Error.h" +#include "llvm/Support/ThreadPool.h" + +#include +#include +#include +#include +#include + +namespace llvm { +namespace orc { + +class SymbolStringPtr; + +class ThinLtoModuleIndex { + static constexpr bool HaveGVs = false; + +public: + ThinLtoModuleIndex(ExecutionSession &ES, unsigned ParseModuleThreads) + : ES(ES), CombinedSummaryIndex(HaveGVs), + ParseModuleWorkers(llvm::hardware_concurrency(ParseModuleThreads)), + NumParseModuleThreads(ParseModuleThreads) {} + + Error add(StringRef InputPath); + GlobalValueSummary *getSummary(GlobalValue::GUID Function) const; + std::vector getAllModulePaths() const; + Optional getModulePathForSymbol(StringRef Name) const; + + template void scheduleModuleParsing(const RangeT &Paths); + ThreadSafeModule takeModule(StringRef Path); + + // Blocking module parsing, returns a Null-module on error. + // Only used for the main module. + ThreadSafeModule parseModuleFromFile(StringRef Path); + + std::vector selectNextPaths(); + unsigned getNumDiscoveredModules() const; + void discoverCalleeModulePaths(FunctionSummary *S, unsigned LookaheadLevels); + + VModuleKey getModuleId(StringRef Path) const { + return CombinedSummaryIndex.getModuleId(Path); + } + +private: + ExecutionSession &ES; + ModuleSummaryIndex CombinedSummaryIndex; + uint64_t NextModuleId{0}; + + struct PathRankEntry { + uint32_t Count{0}; + uint32_t MinDist{100}; + }; + StringMap PathRank; + + ThreadPool ParseModuleWorkers; + unsigned NumParseModuleThreads; + + std::mutex ScheduledModulesLock; + StringMap> ScheduledModules; + + std::mutex ParsedModulesLock; + StringMap ParsedModules; + + void updatePathRank(StringRef Path, unsigned Distance); + void addToWorklist(std::vector &List, + ArrayRef Calls); + + std::vector selectAllPaths(); + std::vector selectHotPaths(unsigned Count); + + void scheduleModuleParsingPrelocked(StringRef Path); + Expected doParseModule(StringRef Path); +}; + +template +inline void ThinLtoModuleIndex::scheduleModuleParsing(const RangeT &Paths) { + std::lock_guard Lock(ScheduledModulesLock); + for (const auto &Path : Paths) { + scheduleModuleParsingPrelocked(Path); + } +} + +} // namespace orc +} // namespace llvm + +#endif diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/bench b/gnu/llvm/llvm/examples/ThinLtoJIT/bench new file mode 100755 index 00000000000..796697eb594 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/bench @@ -0,0 +1,100 @@ +#!/bin/bash +#set -x + +if [ $# -gt 2 ]; then + TOOLS_DIR="$1" + SOURCE_DIR="$2" + MAIN_SOURCE_FILE="$3" +else + echo "Usage: bench
[]" + exit 1 +fi + +if [ $# -gt 3 ]; then + SYS_ROOT="$4" +else + SYS_ROOT="/" +fi + +function check_tool () +{ + if [ -e "${TOOLS_DIR}/$1" ]; then + echo "Found: $1" + else + echo "!!! Cannot find required tool, please provide it in the LLVM binaries folder: $1" + fi +} + +check_tool lli +check_tool SpeculativeJIT +check_tool ThinLtoJIT + +SKIP_BITCODE_GEN=0 +if [[ -e bc-default || -e bc-thinlto || -e ll-default || -e ll-thinlto ]]; then + echo "Skipping bitcode generation: output directories existing" + echo "Please clean up manually: rm -R bc-default bc-thinlto ll-default ll-thinlto" + SKIP_BITCODE_GEN=1 +else + check_tool clang + check_tool llvm-dis + check_tool llvm-lto + mkdir bc-default + mkdir bc-thinlto + mkdir ll-default + mkdir ll-thinlto +fi + +ROOT_DIR=$(pwd) +ALL_BITCODE_FILES="" + +MAIN_FILE_BASENAME=$(basename "${MAIN_SOURCE_FILE%.c*}") +LLI_EXTRA_MODULES="" + +for f in ${SOURCE_DIR}/*.c* ; do + BASE_NAME=$(basename "${f%.c*}") + + if [ ${SKIP_BITCODE_GEN} -eq 0 ]; then + echo "Compile: $f -> ${BASE_NAME}.bc" + + ${TOOLS_DIR}/clang -c -I ${SOURCE_DIR} ${CFLAGS} -isysroot ${SYS_ROOT} -emit-llvm \ + -o "bc-default/${BASE_NAME}.bc" "$f" + ${TOOLS_DIR}/clang -c -I ${SOURCE_DIR} ${CFLAGS} -isysroot ${SYS_ROOT} -flto=thin \ + -o "bc-thinlto/${BASE_NAME}.bc" "$f" + + echo "Disassemble ${BASE_NAME}.bc -> ${BASE_NAME}.ll" + ${TOOLS_DIR}/llvm-dis bc-default/${BASE_NAME}.bc -o ll-default/${BASE_NAME}.ll + ${TOOLS_DIR}/llvm-dis bc-thinlto/${BASE_NAME}.bc -o ll-thinlto/${BASE_NAME}.ll + fi + + ALL_BITCODE_FILES="${ALL_BITCODE_FILES} ${BASE_NAME}.bc" + if [ "${BASE_NAME}" != "${MAIN_FILE_BASENAME}" ]; then + LLI_EXTRA_MODULES="${LLI_EXTRA_MODULES} -extra-module=${BASE_NAME}.bc" + fi +done + +if [ ${SKIP_BITCODE_GEN} -eq 0 ]; then + echo "Link global index file: index.thinlto.bc" + cd ${ROOT_DIR}/bc-thinlto + ${TOOLS_DIR}/llvm-lto --thinlto -o ${ROOT_DIR}/bc-thinlto/index ${ALL_BITCODE_FILES} + + echo "Disassemble global index file: index.thinlto.ll" + cd ${ROOT_DIR}/ll-thinlto + ${TOOLS_DIR}/llvm-dis -o index.thinlto.ll ${ROOT_DIR}/bc-thinlto/index.thinlto.bc +fi + +set -x +cd ${ROOT_DIR}/bc-default +time (${TOOLS_DIR}/clang -o ${MAIN_FILE_BASENAME} -O0 ${LDFLAGS} ${ALL_BITCODE_FILES} && ./${MAIN_FILE_BASENAME} ${EXEC_ARGS} 1>/dev/null) +time ${TOOLS_DIR}/lli ${LLI_EXTRA_MODULES} -jit-kind=mcjit "${MAIN_FILE_BASENAME}.bc" ${EXEC_ARGS} 1>/dev/null +time ${TOOLS_DIR}/lli ${LLI_EXTRA_MODULES} -jit-kind=orc-mcjit "${MAIN_FILE_BASENAME}.bc" ${EXEC_ARGS} 1>/dev/null +time ${TOOLS_DIR}/lli ${LLI_EXTRA_MODULES} -jit-kind=orc-lazy "${MAIN_FILE_BASENAME}.bc" ${EXEC_ARGS} 1>/dev/null +time ${TOOLS_DIR}/lli ${LLI_EXTRA_MODULES} -jit-kind=orc-lazy -compile-threads=8 "${MAIN_FILE_BASENAME}.bc" ${EXEC_ARGS} 1>/dev/null +time ${TOOLS_DIR}/lli ${LLI_EXTRA_MODULES} -jit-kind=orc-lazy -per-module-lazy "${MAIN_FILE_BASENAME}.bc" ${EXEC_ARGS} 1>/dev/null +time ${TOOLS_DIR}/lli ${LLI_EXTRA_MODULES} -jit-kind=orc-lazy -per-module-lazy -compile-threads=8 "${MAIN_FILE_BASENAME}.bc" ${EXEC_ARGS} 1>/dev/null +time ${TOOLS_DIR}/lli ${LLI_EXTRA_MODULES} -jit-kind=orc-lazy -per-module-lazy -compile-threads=8 -O1 "${MAIN_FILE_BASENAME}.bc" ${EXEC_ARGS} 1>/dev/null +time ${TOOLS_DIR}/lli ${LLI_EXTRA_MODULES} -jit-kind=orc-lazy -per-module-lazy -compile-threads=8 -O0 "${MAIN_FILE_BASENAME}.bc" ${EXEC_ARGS} 1>/dev/null +time ${TOOLS_DIR}/SpeculativeJIT -num-threads=8 ${ALL_BITCODE_FILES} --args ${EXEC_ARGS} 1>/dev/null + +cd ${ROOT_DIR}/bc-thinlto +#time (${TOOLS_DIR}/clang -flto=thin -o test ${ALL_BITCODE_FILES} && ./test ${EXEC_ARGS} 1>/dev/null) +time ${TOOLS_DIR}/ThinLtoJIT index.thinlto.bc --args ${EXEC_ARGS} 1>/dev/null diff --git a/gnu/llvm/llvm/examples/ThinLtoJIT/main.cpp b/gnu/llvm/llvm/examples/ThinLtoJIT/main.cpp new file mode 100644 index 00000000000..5a338e94744 --- /dev/null +++ b/gnu/llvm/llvm/examples/ThinLtoJIT/main.cpp @@ -0,0 +1,83 @@ +#include "llvm/ADT/StringRef.h" +#include "llvm/Support/CommandLine.h" +#include "llvm/Support/Error.h" +#include "llvm/Support/InitLLVM.h" +#include "llvm/Support/TargetSelect.h" + +#include "ThinLtoJIT.h" + +#include +#include + +using namespace llvm; + +static cl::list + InputFiles(cl::Positional, cl::OneOrMore, + cl::desc("")); + +static cl::list InputArgs("args", cl::Positional, + cl::desc("..."), + cl::ZeroOrMore, cl::PositionalEatsArgs); + +static cl::opt CompileThreads("compile-threads", cl::Optional, + cl::desc("Number of compile threads"), + cl::init(4)); + +static cl::opt LoadThreads("load-threads", cl::Optional, + cl::desc("Number of module load threads"), + cl::init(8)); + +static cl::opt + LookaheadLevels("lookahead", cl::Optional, + cl::desc("Calls to look ahead of execution"), cl::init(4)); + +static cl::opt DiscoveryFlagsBucketSize( + "discovery-flag-bucket-size", cl::Optional, + cl::desc("Flags per bucket (rounds up to memory pages)"), cl::init(4096)); + +static cl::opt + MemFence("mem-fence", + cl::desc("Control memory fences for cache synchronization"), + cl::init(orc::ThinLtoJIT::NeverFence), + cl::values(clEnumValN(orc::ThinLtoJIT::NeverFence, "never", + "No use of memory fences"), + clEnumValN(orc::ThinLtoJIT::FenceStaticCode, "static", + "Use of memory fences in static code only"), + clEnumValN(orc::ThinLtoJIT::FenceJITedCode, "jited", + "Install memory fences in JITed code only"), + clEnumValN(orc::ThinLtoJIT::AlwaysFence, "always", + "Always use of memory fences"))); + +static cl::opt + AllowNudge("allow-nudge", + cl::desc("Allow the symbol generator to nudge symbols into " + "discovery even though they haven't been reached"), + cl::init(false)); + +static cl::opt PrintStats("print-stats", + cl::desc("Print module stats on shutdown"), + cl::init(false)); + +int main(int argc, char *argv[]) { + InitLLVM X(argc, argv); + InitializeNativeTarget(); + InitializeNativeTargetAsmPrinter(); + cl::ParseCommandLineOptions(argc, argv, "ThinLtoJIT"); + + Error Err = Error::success(); + auto atLeastOne = [](unsigned N) { return std::max(1u, N); }; + + orc::ThinLtoJIT Jit(InputFiles, "main", atLeastOne(LookaheadLevels), + atLeastOne(CompileThreads), atLeastOne(LoadThreads), + DiscoveryFlagsBucketSize, MemFence, AllowNudge, + PrintStats, Err); + if (Err) { + logAllUnhandledErrors(std::move(Err), errs(), "[ThinLtoJIT] "); + exit(1); + } + + ExitOnError ExitOnErr; + ExitOnErr.setBanner("[ThinLtoJIT] "); + + return ExitOnErr(Jit.main(InputArgs)); +} diff --git a/gnu/llvm/llvm/include/llvm-c/Core.h b/gnu/llvm/llvm/include/llvm-c/Core.h index 7a39731d3e0..c8a6f970419 100644 --- a/gnu/llvm/llvm/include/llvm-c/Core.h +++ b/gnu/llvm/llvm/include/llvm-c/Core.h @@ -144,23 +144,25 @@ typedef enum { } LLVMOpcode; typedef enum { - LLVMVoidTypeKind, /**< type with no size */ - LLVMHalfTypeKind, /**< 16 bit floating point type */ - LLVMFloatTypeKind, /**< 32 bit floating point type */ - LLVMDoubleTypeKind, /**< 64 bit floating point type */ - LLVMX86_FP80TypeKind, /**< 80 bit floating point type (X87) */ - LLVMFP128TypeKind, /**< 128 bit floating point type (112-bit mantissa)*/ - LLVMPPC_FP128TypeKind, /**< 128 bit floating point type (two 64-bits) */ - LLVMLabelTypeKind, /**< Labels */ - LLVMIntegerTypeKind, /**< Arbitrary bit width integers */ - LLVMFunctionTypeKind, /**< Functions */ - LLVMStructTypeKind, /**< Structures */ - LLVMArrayTypeKind, /**< Arrays */ - LLVMPointerTypeKind, /**< Pointers */ - LLVMVectorTypeKind, /**< SIMD 'packed' format, or other vector type */ - LLVMMetadataTypeKind, /**< Metadata */ - LLVMX86_MMXTypeKind, /**< X86 MMX */ - LLVMTokenTypeKind /**< Tokens */ + LLVMVoidTypeKind, /**< type with no size */ + LLVMHalfTypeKind, /**< 16 bit floating point type */ + LLVMFloatTypeKind, /**< 32 bit floating point type */ + LLVMDoubleTypeKind, /**< 64 bit floating point type */ + LLVMX86_FP80TypeKind, /**< 80 bit floating point type (X87) */ + LLVMFP128TypeKind, /**< 128 bit floating point type (112-bit mantissa)*/ + LLVMPPC_FP128TypeKind, /**< 128 bit floating point type (two 64-bits) */ + LLVMLabelTypeKind, /**< Labels */ + LLVMIntegerTypeKind, /**< Arbitrary bit width integers */ + LLVMFunctionTypeKind, /**< Functions */ + LLVMStructTypeKind, /**< Structures */ + LLVMArrayTypeKind, /**< Arrays */ + LLVMPointerTypeKind, /**< Pointers */ + LLVMVectorTypeKind, /**< Fixed width SIMD vector type */ + LLVMMetadataTypeKind, /**< Metadata */ + LLVMX86_MMXTypeKind, /**< X86 MMX */ + LLVMTokenTypeKind, /**< Tokens */ + LLVMScalableVectorTypeKind, /**< Scalable SIMD vector type */ + LLVMBFloatTypeKind /**< 16 bit brain floating point type */ } LLVMTypeKind; typedef enum { @@ -1162,6 +1164,11 @@ unsigned LLVMGetIntTypeWidth(LLVMTypeRef IntegerTy); */ LLVMTypeRef LLVMHalfTypeInContext(LLVMContextRef C); +/** + * Obtain a 16-bit brain floating point type from a context. + */ +LLVMTypeRef LLVMBFloatTypeInContext(LLVMContextRef C); + /** * Obtain a 32-bit floating point type from a context. */ @@ -1194,6 +1201,7 @@ LLVMTypeRef LLVMPPCFP128TypeInContext(LLVMContextRef C); * These map to the functions in this group of the same name. */ LLVMTypeRef LLVMHalfType(void); +LLVMTypeRef LLVMBFloatType(void); LLVMTypeRef LLVMFloatType(void); LLVMTypeRef LLVMDoubleType(void); LLVMTypeRef LLVMX86FP80Type(void); @@ -2690,7 +2698,7 @@ LLVMValueRef LLVMGetNextGlobalIFunc(LLVMValueRef IFunc); * no previous global aliases. */ LLVMValueRef LLVMGetPreviousGlobalIFunc(LLVMValueRef IFunc); - + /** * Retrieves the resolver function associated with this indirect function, or * NULL if it doesn't not exist. @@ -2944,7 +2952,7 @@ void LLVMInsertExistingBasicBlockAfterInsertBlock(LLVMBuilderRef Builder, */ void LLVMAppendExistingBasicBlock(LLVMValueRef Fn, LLVMBasicBlockRef BB); - + /** * Create a new basic block without inserting it into a function. * @@ -3251,8 +3259,8 @@ LLVMTypeRef LLVMGetCalledFunctionType(LLVMValueRef C); * This expects an LLVMValueRef that corresponds to a llvm::CallInst or * llvm::InvokeInst. * - * @see llvm::CallInst::getCalledValue() - * @see llvm::InvokeInst::getCalledValue() + * @see llvm::CallInst::getCalledOperand() + * @see llvm::InvokeInst::getCalledOperand() */ LLVMValueRef LLVMGetCalledValue(LLVMValueRef Instr); @@ -3628,7 +3636,7 @@ void LLVMAddDestination(LLVMValueRef IndirectBr, LLVMBasicBlockRef Dest); /* Get the number of clauses on the landingpad instruction */ unsigned LLVMGetNumClauses(LLVMValueRef LandingPad); -/* Get the value of the clause at idnex Idx on the landingpad instruction */ +/* Get the value of the clause at index Idx on the landingpad instruction */ LLVMValueRef LLVMGetClause(LLVMValueRef LandingPad, unsigned Idx); /* Add a catch or filter clause to the landingpad instruction */ @@ -3755,7 +3763,7 @@ LLVMValueRef LLVMBuildArrayMalloc(LLVMBuilderRef, LLVMTypeRef Ty, LLVMValueRef Val, const char *Name); /** - * Creates and inserts a memset to the specified pointer and the + * Creates and inserts a memset to the specified pointer and the * specified value. * * @see llvm::IRRBuilder::CreateMemSet() @@ -3768,7 +3776,7 @@ LLVMValueRef LLVMBuildMemSet(LLVMBuilderRef B, LLVMValueRef Ptr, * * @see llvm::IRRBuilder::CreateMemCpy() */ -LLVMValueRef LLVMBuildMemCpy(LLVMBuilderRef B, +LLVMValueRef LLVMBuildMemCpy(LLVMBuilderRef B, LLVMValueRef Dst, unsigned DstAlign, LLVMValueRef Src, unsigned SrcAlign, LLVMValueRef Size); @@ -3777,7 +3785,7 @@ LLVMValueRef LLVMBuildMemCpy(LLVMBuilderRef B, * * @see llvm::IRRBuilder::CreateMemMove() */ -LLVMValueRef LLVMBuildMemMove(LLVMBuilderRef B, +LLVMValueRef LLVMBuildMemMove(LLVMBuilderRef B, LLVMValueRef Dst, unsigned DstAlign, LLVMValueRef Src, unsigned SrcAlign, LLVMValueRef Size); @@ -3929,6 +3937,26 @@ LLVMValueRef LLVMBuildAtomicCmpXchg(LLVMBuilderRef B, LLVMValueRef Ptr, LLVMAtomicOrdering FailureOrdering, LLVMBool SingleThread); +/** + * Get the number of elements in the mask of a ShuffleVector instruction. + */ +unsigned LLVMGetNumMaskElements(LLVMValueRef ShuffleVectorInst); + +/** + * \returns a constant that specifies that the result of a \c ShuffleVectorInst + * is undefined. + */ +int LLVMGetUndefMaskElem(void); + +/** + * Get the mask value at position Elt in the mask of a ShuffleVector + * instruction. + * + * \Returns the result of \c LLVMGetUndefMaskElem() if the mask value is undef + * at that position. + */ +int LLVMGetMaskValue(LLVMValueRef ShuffleVectorInst, unsigned Elt); + LLVMBool LLVMIsAtomicSingleThread(LLVMValueRef AtomicInst); void LLVMSetAtomicSingleThread(LLVMValueRef AtomicInst, LLVMBool SingleThread); diff --git a/gnu/llvm/llvm/include/llvm-c/DataTypes.h b/gnu/llvm/llvm/include/llvm-c/DataTypes.h index 893b22b49ff..0f27ba81865 100644 --- a/gnu/llvm/llvm/include/llvm-c/DataTypes.h +++ b/gnu/llvm/llvm/include/llvm-c/DataTypes.h @@ -24,12 +24,6 @@ #ifndef LLVM_C_DATATYPES_H #define LLVM_C_DATATYPES_H -#ifdef __cplusplus -#include -#else -#include -#endif - #include #include diff --git a/gnu/llvm/llvm/include/llvm-c/DebugInfo.h b/gnu/llvm/llvm/include/llvm-c/DebugInfo.h index e933fe4b3f9..cdf5f5a0cca 100644 --- a/gnu/llvm/llvm/include/llvm-c/DebugInfo.h +++ b/gnu/llvm/llvm/include/llvm-c/DebugInfo.h @@ -250,6 +250,10 @@ void LLVMDIBuilderFinalize(LLVMDIBuilderRef Builder); * \param SplitDebugInlining Whether to emit inline debug info. * \param DebugInfoForProfiling Whether to emit extra debug info for * profile collection. + * \param SysRoot The Clang system root (value of -isysroot). + * \param SysRootLen The length of the C string passed to \c SysRoot. + * \param SDK The SDK. On Darwin, the last component of the sysroot. + * \param SDKLen The length of the C string passed to \c SDK. */ LLVMMetadataRef LLVMDIBuilderCreateCompileUnit( LLVMDIBuilderRef Builder, LLVMDWARFSourceLanguage Lang, @@ -257,7 +261,8 @@ LLVMMetadataRef LLVMDIBuilderCreateCompileUnit( LLVMBool isOptimized, const char *Flags, size_t FlagsLen, unsigned RuntimeVer, const char *SplitName, size_t SplitNameLen, LLVMDWARFEmissionKind Kind, unsigned DWOId, LLVMBool SplitDebugInlining, - LLVMBool DebugInfoForProfiling); + LLVMBool DebugInfoForProfiling, const char *SysRoot, size_t SysRootLen, + const char *SDK, size_t SDKLen); /** * Create a file descriptor to hold debugging information for a file. @@ -283,15 +288,15 @@ LLVMDIBuilderCreateFile(LLVMDIBuilderRef Builder, const char *Filename, * \param ConfigMacrosLen The length of the C string passed to \c ConfigMacros. * \param IncludePath The path to the module map file. * \param IncludePathLen The length of the C string passed to \c IncludePath. - * \param SysRoot The Clang system root (value of -isysroot). - * \param SysRootLen The length of the C string passed to \c SysRoot. + * \param APINotesFile The path to an API notes file for the module. + * \param APINotesFileLen The length of the C string passed to \c APINotestFile. */ LLVMMetadataRef LLVMDIBuilderCreateModule(LLVMDIBuilderRef Builder, LLVMMetadataRef ParentScope, const char *Name, size_t NameLen, const char *ConfigMacros, size_t ConfigMacrosLen, const char *IncludePath, size_t IncludePathLen, - const char *SysRoot, size_t SysRootLen); + const char *APINotesFile, size_t APINotesFileLen); /** * Creates a new descriptor for a namespace with the specified parent scope. diff --git a/gnu/llvm/llvm/include/llvm-c/ExecutionEngine.h b/gnu/llvm/llvm/include/llvm-c/ExecutionEngine.h index f31b97ad762..c5fc9bdb4d0 100644 --- a/gnu/llvm/llvm/include/llvm-c/ExecutionEngine.h +++ b/gnu/llvm/llvm/include/llvm-c/ExecutionEngine.h @@ -149,6 +149,11 @@ uint64_t LLVMGetGlobalValueAddress(LLVMExecutionEngineRef EE, const char *Name); uint64_t LLVMGetFunctionAddress(LLVMExecutionEngineRef EE, const char *Name); +/// Returns true on error, false on success. If true is returned then the error +/// message is copied to OutStr and cleared in the ExecutionEngine instance. +LLVMBool LLVMExecutionEngineGetErrMsg(LLVMExecutionEngineRef EE, + char **OutError); + /*===-- Operations on memory managers -------------------------------------===*/ typedef uint8_t *(*LLVMMemoryManagerAllocateCodeSectionCallback)( diff --git a/gnu/llvm/llvm/include/llvm-c/Orc.h b/gnu/llvm/llvm/include/llvm-c/Orc.h new file mode 100644 index 00000000000..09a05884610 --- /dev/null +++ b/gnu/llvm/llvm/include/llvm-c/Orc.h @@ -0,0 +1,335 @@ +/*===---------------- llvm-c/Orc.h - OrcV2 C bindings -----------*- C++ -*-===*\ +|* *| +|* Part of the LLVM Project, under the Apache License v2.0 with LLVM *| +|* Exceptions. *| +|* See https://llvm.org/LICENSE.txt for license information. *| +|* SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception *| +|* *| +|*===----------------------------------------------------------------------===*| +|* *| +|* This header declares the C interface to libLLVMOrcJIT.a, which implements *| +|* JIT compilation of LLVM IR. Minimal documentation of C API specific issues *| +|* (especially memory ownership rules) is provided. Core Orc concepts are *| +|* documented in llvm/docs/ORCv2.rst and APIs are documented in the C++ *| +|* headers *| +|* *| +|* Many exotic languages can interoperate with C code but have a harder time *| +|* with C++ due to name mangling. So in addition to C, this interface enables *| +|* tools written in such languages. *| +|* *| +|* Note: This interface is experimental. It is *NOT* stable, and may be *| +|* changed without warning. Only C API usage documentation is *| +|* provided. See the C++ documentation for all higher level ORC API *| +|* details. *| +|* *| +\*===----------------------------------------------------------------------===*/ + +#ifndef LLVM_C_ORC_H +#define LLVM_C_ORC_H + +#include "llvm-c/Error.h" +#include "llvm-c/TargetMachine.h" +#include "llvm-c/Types.h" + +LLVM_C_EXTERN_C_BEGIN + +/** + * Represents an address in the target process. + */ +typedef uint64_t LLVMOrcJITTargetAddress; + +/** + * A reference to an orc::ExecutionSession instance. + */ +typedef struct LLVMOrcOpaqueExecutionSession *LLVMOrcExecutionSessionRef; + +/** + * A reference to an orc::SymbolStringPool table entry. + */ +typedef struct LLVMOrcQuaqueSymbolStringPoolEntryPtr + *LLVMOrcSymbolStringPoolEntryRef; + +/** + * A reference to an orc::JITDylib instance. + */ +typedef struct LLVMOrcOpaqueJITDylib *LLVMOrcJITDylibRef; + +/** + * A reference to an orc::JITDylib::DefinitionGenerator. + */ +typedef struct LLVMOrcOpaqueJITDylibDefinitionGenerator + *LLVMOrcJITDylibDefinitionGeneratorRef; + +/** + * Predicate function for SymbolStringPoolEntries. + */ +typedef int (*LLVMOrcSymbolPredicate)(LLVMOrcSymbolStringPoolEntryRef Sym, + void *Ctx); + +/** + * A reference to an orc::ThreadSafeContext instance. + */ +typedef struct LLVMOrcOpaqueThreadSafeContext *LLVMOrcThreadSafeContextRef; + +/** + * A reference to an orc::ThreadSafeModule instance. + */ +typedef struct LLVMOrcOpaqueThreadSafeModule *LLVMOrcThreadSafeModuleRef; + +/** + * A reference to an orc::JITTargetMachineBuilder instance. + */ +typedef struct LLVMOrcOpaqueJITTargetMachineBuilder + *LLVMOrcJITTargetMachineBuilderRef; + +/** + * A reference to an orc::LLJITBuilder instance. + */ +typedef struct LLVMOrcOpaqueLLJITBuilder *LLVMOrcLLJITBuilderRef; + +/** + * A reference to an orc::LLJIT instance. + */ +typedef struct LLVMOrcOpaqueLLJIT *LLVMOrcLLJITRef; + +/** + * Intern a string in the ExecutionSession's SymbolStringPool and return a + * reference to it. This increments the ref-count of the pool entry, and the + * returned value should be released once the client is done with it by + * calling LLVMOrReleaseSymbolStringPoolEntry. + * + * Since strings are uniqued within the SymbolStringPool + * LLVMOrcSymbolStringPoolEntryRefs can be compared by value to test string + * equality. + * + * Note that this function does not perform linker-mangling on the string. + */ +LLVMOrcSymbolStringPoolEntryRef +LLVMOrcExecutionSessionIntern(LLVMOrcExecutionSessionRef ES, const char *Name); + +/** + * Reduces the ref-count for of a SymbolStringPool entry. + */ +void LLVMOrcReleaseSymbolStringPoolEntry(LLVMOrcSymbolStringPoolEntryRef S); + +/** + * Dispose of a JITDylib::DefinitionGenerator. This should only be called if + * ownership has not been passed to a JITDylib (e.g. because some error + * prevented the client from calling LLVMOrcJITDylibAddGenerator). + */ +void LLVMOrcDisposeJITDylibDefinitionGenerator( + LLVMOrcJITDylibDefinitionGeneratorRef DG); + +/** + * Add a JITDylib::DefinitionGenerator to the given JITDylib. + * + * The JITDylib will take ownership of the given generator: The client is no + * longer responsible for managing its memory. + */ +void LLVMOrcJITDylibAddGenerator(LLVMOrcJITDylibRef JD, + LLVMOrcJITDylibDefinitionGeneratorRef DG); + +/** + * Get a DynamicLibrarySearchGenerator that will reflect process symbols into + * the JITDylib. On success the resulting generator is owned by the client. + * Ownership is typically transferred by adding the instance to a JITDylib + * using LLVMOrcJITDylibAddGenerator, + * + * The GlobalPrefix argument specifies the character that appears on the front + * of linker-mangled symbols for the target platform (e.g. '_' on MachO). + * If non-null, this character will be stripped from the start of all symbol + * strings before passing the remaining substring to dlsym. + * + * The optional Filter and Ctx arguments can be used to supply a symbol name + * filter: Only symbols for which the filter returns true will be visible to + * JIT'd code. If the Filter argument is null then all process symbols will + * be visible to JIT'd code. Note that the symbol name passed to the Filter + * function is the full mangled symbol: The client is responsible for stripping + * the global prefix if present. + */ +LLVMErrorRef LLVMOrcCreateDynamicLibrarySearchGeneratorForProcess( + LLVMOrcJITDylibDefinitionGeneratorRef *Result, char GlobalPrefx, + LLVMOrcSymbolPredicate Filter, void *FilterCtx); + +/** + * Create a ThreadSafeContext containing a new LLVMContext. + * + * Ownership of the underlying ThreadSafeContext data is shared: Clients + * can and should dispose of their ThreadSafeContext as soon as they no longer + * need to refer to it directly. Other references (e.g. from ThreadSafeModules + * will keep the data alive as long as it is needed. + */ +LLVMOrcThreadSafeContextRef LLVMOrcCreateNewThreadSafeContext(void); + +/** + * Get a reference to the wrapped LLVMContext. + */ +LLVMContextRef +LLVMOrcThreadSafeContextGetContext(LLVMOrcThreadSafeContextRef TSCtx); + +/** + * Dispose of a ThreadSafeContext. + */ +void LLVMOrcDisposeThreadSafeContext(LLVMOrcThreadSafeContextRef TSCtx); + +/** + * Create a ThreadSafeModule wrapper around the given LLVM module. This takes + * ownership of the M argument which should not be disposed of or referenced + * after this function returns. + * + * Ownership of the ThreadSafeModule is unique: If it is transferred to the JIT + * (e.g. by LLVMOrcLLJITAddLLVMIRModule), in which case the client is no longer + * responsible for it. If it is not transferred to the JIT then the client + * should call LLVMOrcDisposeThreadSafeModule to dispose of it. + */ +LLVMOrcThreadSafeModuleRef +LLVMOrcCreateNewThreadSafeModule(LLVMModuleRef M, + LLVMOrcThreadSafeContextRef TSCtx); + +/** + * Dispose of a ThreadSafeModule. This should only be called if ownership has + * not been passed to LLJIT (e.g. because some error prevented the client from + * adding this to the JIT). + */ +void LLVMOrcDisposeThreadSafeModule(LLVMOrcThreadSafeModuleRef TSM); + +/** + * Create a JITTargetMachineBuilder by detecting the host. + * + * On success the client owns the resulting JITTargetMachineBuilder. It must be + * passed to a consuming operation (e.g. LLVMOrcCreateLLJITBuilder) or disposed + * of by calling LLVMOrcDisposeJITTargetMachineBuilder. + */ +LLVMErrorRef LLVMOrcJITTargetMachineBuilderDetectHost( + LLVMOrcJITTargetMachineBuilderRef *Result); + +/** + * Create a JITTargetMachineBuilder from the given TargetMachine template. + * + * This operation takes ownership of the given TargetMachine and destroys it + * before returing. The resulting JITTargetMachineBuilder is owned by the client + * and must be passed to a consuming operation (e.g. LLVMOrcCreateLLJITBuilder) + * or disposed of by calling LLVMOrcDisposeJITTargetMachineBuilder. + */ +LLVMOrcJITTargetMachineBuilderRef +LLVMOrcJITTargetMachineBuilderCreateFromTargetMachine(LLVMTargetMachineRef TM); + +/** + * Dispose of a JITTargetMachineBuilder. + */ +void LLVMOrcDisposeJITTargetMachineBuilder( + LLVMOrcJITTargetMachineBuilderRef JTMB); + +/** + * Create an LLJITTargetMachineBuilder. + * + * The client owns the resulting LLJITBuilder and should dispose of it using + * LLVMOrcDisposeLLJITBuilder once they are done with it. + */ +LLVMOrcLLJITBuilderRef LLVMOrcCreateLLJITBuilder(void); + +/** + * Dispose of an LLVMOrcLLJITBuilderRef. This should only be called if ownership + * has not been passed to LLVMOrcCreateLLJIT (e.g. because some error prevented + * that function from being called). + */ +void LLVMOrcDisposeLLJITBuilder(LLVMOrcLLJITBuilderRef Builder); + +/** + * Set the JITTargetMachineBuilder to be used when constructing the LLJIT + * instance. Calling this function is optional: if it is not called then the + * LLJITBuilder will use JITTargeTMachineBuilder::detectHost to construct a + * JITTargetMachineBuilder. + */ +void LLVMOrcLLJITBuilderSetJITTargetMachineBuilder( + LLVMOrcLLJITBuilderRef Builder, LLVMOrcJITTargetMachineBuilderRef JTMB); + +/** + * Create an LLJIT instance from an LLJITBuilder. + * + * This operation takes ownership of the Builder argument: clients should not + * dispose of the builder after calling this function (even if the function + * returns an error). If a null Builder argument is provided then a + * default-constructed LLJITBuilder will be used. + * + * On success the resulting LLJIT instance is uniquely owned by the client and + * automatically manages the memory of all JIT'd code and all modules that are + * transferred to it (e.g. via LLVMOrcLLJITAddLLVMIRModule). Disposing of the + * LLJIT instance will free all memory managed by the JIT, including JIT'd code + * and not-yet compiled modules. + */ +LLVMErrorRef LLVMOrcCreateLLJIT(LLVMOrcLLJITRef *Result, + LLVMOrcLLJITBuilderRef Builder); + +/** + * Dispose of an LLJIT instance. + */ +LLVMErrorRef LLVMOrcDisposeLLJIT(LLVMOrcLLJITRef J); + +/** + * Get a reference to the ExecutionSession for this LLJIT instance. + * + * The ExecutionSession is owned by the LLJIT instance. The client is not + * responsible for managing its memory. + */ +LLVMOrcExecutionSessionRef LLVMOrcLLJITGetExecutionSession(LLVMOrcLLJITRef J); + +/** + * Return a reference to the Main JITDylib. + * + * The JITDylib is owned by the LLJIT instance. The client is not responsible + * for managing its memory. + */ +LLVMOrcJITDylibRef LLVMOrcLLJITGetMainJITDylib(LLVMOrcLLJITRef J); + +/** + * Return the target triple for this LLJIT instance. This string is owned by + * the LLJIT instance and should not be freed by the client. + */ +const char *LLVMOrcLLJITGetTripleString(LLVMOrcLLJITRef J); + +/** + * Returns the global prefix character according to the LLJIT's DataLayout. + */ +char LLVMOrcLLJITGetGlobalPrefix(LLVMOrcLLJITRef J); + +/** + * Mangles the given string according to the LLJIT instance's DataLayout, then + * interns the result in the SymbolStringPool and returns a reference to the + * pool entry. Clients should call LLVMOrcReleaseSymbolStringPoolEntry to + * decrement the ref-count on the pool entry once they are finished with this + * value. + */ +LLVMOrcSymbolStringPoolEntryRef +LLVMOrcLLJITMangleAndIntern(LLVMOrcLLJITRef J, const char *UnmangledName); + +/** + * Add a buffer representing an object file to the given JITDylib in the given + * LLJIT instance. This operation transfers ownership of the buffer to the + * LLJIT instance. The buffer should not be disposed of or referenced once this + * function returns. + */ +LLVMErrorRef LLVMOrcLLJITAddObjectFile(LLVMOrcLLJITRef J, LLVMOrcJITDylibRef JD, + LLVMMemoryBufferRef ObjBuffer); + +/** + * Add an IR module to the given JITDylib of the given LLJIT instance. This + * operation transfers ownership of the TSM argument to the LLJIT instance. + * The TSM argument should not be 3disposed of or referenced once this + * function returns. + */ +LLVMErrorRef LLVMOrcLLJITAddLLVMIRModule(LLVMOrcLLJITRef J, + LLVMOrcJITDylibRef JD, + LLVMOrcThreadSafeModuleRef TSM); +/** + * Look up the given symbol in the main JITDylib of the given LLJIT instance. + * + * This operation does not take ownership of the Name argument. + */ +LLVMErrorRef LLVMOrcLLJITLookup(LLVMOrcLLJITRef J, + LLVMOrcJITTargetAddress *Result, + const char *Name); + +LLVM_C_EXTERN_C_END + +#endif /* LLVM_C_ORC_H */ diff --git a/gnu/llvm/llvm/include/llvm-c/Transforms/Coroutines.h b/gnu/llvm/llvm/include/llvm-c/Transforms/Coroutines.h index 15798af7d66..03b6822033c 100644 --- a/gnu/llvm/llvm/include/llvm-c/Transforms/Coroutines.h +++ b/gnu/llvm/llvm/include/llvm-c/Transforms/Coroutines.h @@ -21,6 +21,7 @@ #include "llvm-c/ExternC.h" #include "llvm-c/Types.h" +#include "llvm-c/Transforms/PassManagerBuilder.h" LLVM_C_EXTERN_C_BEGIN @@ -43,6 +44,9 @@ void LLVMAddCoroElidePass(LLVMPassManagerRef PM); /** See llvm::createCoroCleanupLegacyPass function. */ void LLVMAddCoroCleanupPass(LLVMPassManagerRef PM); +/** See llvm::addCoroutinePassesToExtensionPoints. */ +void LLVMPassManagerBuilderAddCoroutinePassesToExtensionPoints(LLVMPassManagerBuilderRef PMB); + /** * @} */ diff --git a/gnu/llvm/llvm/include/llvm-c/lto.h b/gnu/llvm/llvm/include/llvm-c/lto.h index 97a8f482332..4dbc77f294c 100644 --- a/gnu/llvm/llvm/include/llvm-c/lto.h +++ b/gnu/llvm/llvm/include/llvm-c/lto.h @@ -46,7 +46,7 @@ typedef bool lto_bool_t; * @{ */ -#define LTO_API_VERSION 26 +#define LTO_API_VERSION 27 /** * \since prior to LTO_API_VERSION=3 @@ -297,6 +297,21 @@ lto_module_get_symbol_attribute(lto_module_t mod, unsigned int index); extern const char* lto_module_get_linkeropts(lto_module_t mod); +/** + * If targeting mach-o on darwin, this function gets the CPU type and subtype + * that will end up being encoded in the mach-o header. These are the values + * that can be found in mach/machine.h. + * + * \p out_cputype and \p out_cpusubtype must be non-NULL. + * + * Returns true on error (check lto_get_error_message() for details). + * + * \since LTO_API_VERSION=27 + */ +extern lto_bool_t lto_module_get_macho_cputype(lto_module_t mod, + unsigned int *out_cputype, + unsigned int *out_cpusubtype); + /** * Diagnostic severity. * diff --git a/gnu/llvm/llvm/include/llvm/ADT/APFloat.h b/gnu/llvm/llvm/include/llvm/ADT/APFloat.h index ed25b2cd89f..876e52c150a 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/APFloat.h +++ b/gnu/llvm/llvm/include/llvm/ADT/APFloat.h @@ -18,6 +18,7 @@ #include "llvm/ADT/APInt.h" #include "llvm/ADT/ArrayRef.h" +#include "llvm/ADT/FloatingPointMode.h" #include "llvm/Support/ErrorHandling.h" #include @@ -141,7 +142,7 @@ enum lostFraction { // Example of truncated bits: // members. struct APFloatBase { typedef APInt::WordType integerPart; - static const unsigned integerPartWidth = APInt::APINT_BITS_PER_WORD; + static constexpr unsigned integerPartWidth = APInt::APINT_BITS_PER_WORD; /// A signed type to represent a floating point numbers unbiased exponent. typedef int32_t ExponentType; @@ -150,6 +151,7 @@ struct APFloatBase { /// @{ enum Semantics { S_IEEEhalf, + S_BFloat, S_IEEEsingle, S_IEEEdouble, S_x87DoubleExtended, @@ -161,6 +163,7 @@ struct APFloatBase { static Semantics SemanticsToEnum(const llvm::fltSemantics &Sem); static const fltSemantics &IEEEhalf() LLVM_READNONE; + static const fltSemantics &BFloat() LLVM_READNONE; static const fltSemantics &IEEEsingle() LLVM_READNONE; static const fltSemantics &IEEEdouble() LLVM_READNONE; static const fltSemantics &IEEEquad() LLVM_READNONE; @@ -182,13 +185,15 @@ struct APFloatBase { }; /// IEEE-754R 4.3: Rounding-direction attributes. - enum roundingMode { - rmNearestTiesToEven, - rmTowardPositive, - rmTowardNegative, - rmTowardZero, - rmNearestTiesToAway - }; + using roundingMode = llvm::RoundingMode; + + static constexpr roundingMode rmNearestTiesToEven = + RoundingMode::NearestTiesToEven; + static constexpr roundingMode rmTowardPositive = RoundingMode::TowardPositive; + static constexpr roundingMode rmTowardNegative = RoundingMode::TowardNegative; + static constexpr roundingMode rmTowardZero = RoundingMode::TowardZero; + static constexpr roundingMode rmNearestTiesToAway = + RoundingMode::NearestTiesToAway; /// IEEE-754R 7: Default exception handling. /// @@ -511,6 +516,7 @@ private: opStatus divideSpecials(const IEEEFloat &); opStatus multiplySpecials(const IEEEFloat &); opStatus modSpecials(const IEEEFloat &); + opStatus remainderSpecials(const IEEEFloat&); /// @} @@ -537,6 +543,7 @@ private: /// @} APInt convertHalfAPFloatToAPInt() const; + APInt convertBFloatAPFloatToAPInt() const; APInt convertFloatAPFloatToAPInt() const; APInt convertDoubleAPFloatToAPInt() const; APInt convertQuadrupleAPFloatToAPInt() const; @@ -544,6 +551,7 @@ private: APInt convertPPCDoubleDoubleAPFloatToAPInt() const; void initFromAPInt(const fltSemantics *Sem, const APInt &api); void initFromHalfAPInt(const APInt &api); + void initFromBFloatAPInt(const APInt &api); void initFromFloatAPInt(const APInt &api); void initFromDoubleAPInt(const APInt &api); void initFromQuadrupleAPInt(const APInt &api); @@ -585,7 +593,7 @@ IEEEFloat scalbn(IEEEFloat X, int Exp, IEEEFloat::roundingMode); IEEEFloat frexp(const IEEEFloat &Val, int &Exp, IEEEFloat::roundingMode RM); // This mode implements more precise float in terms of two APFloats. -// The interface and layout is designed for arbitray underlying semantics, +// The interface and layout is designed for arbitrary underlying semantics, // though currently only PPCDoubleDouble semantics are supported, whose // corresponding underlying semantics are IEEEdouble. class DoubleAPFloat final : public APFloatBase { @@ -853,8 +861,8 @@ public: APFloat(const fltSemantics &Semantics) : U(Semantics) {} APFloat(const fltSemantics &Semantics, StringRef S); APFloat(const fltSemantics &Semantics, integerPart I) : U(Semantics, I) {} - template ::value>::type> + template ::value>> APFloat(const fltSemantics &Semantics, T V) = delete; // TODO: Remove this constructor. This isn't faster than the first one. APFloat(const fltSemantics &Semantics, uninitializedTag) @@ -950,9 +958,10 @@ public: /// Returns a float which is bitcasted from an all one value int. /// + /// \param Semantics - type float semantics /// \param BitWidth - Select float type - /// \param isIEEE - If 128 bit number, select between PPC and IEEE - static APFloat getAllOnesValue(unsigned BitWidth, bool isIEEE = false); + static APFloat getAllOnesValue(const fltSemantics &Semantics, + unsigned BitWidth); /// Used to insert APFloat objects, or objects that contain APFloat objects, /// into FoldingSets. @@ -1035,6 +1044,13 @@ public: APFLOAT_DISPATCH_ON_SEMANTICS(next(nextDown)); } + /// Negate an APFloat. + APFloat operator-() const { + APFloat Result(*this); + Result.changeSign(); + return Result; + } + /// Add two APFloats, rounding ties to the nearest even. /// No error checking. APFloat operator+(const APFloat &RHS) const { @@ -1117,7 +1133,27 @@ public: double convertToDouble() const { return getIEEE().convertToDouble(); } float convertToFloat() const { return getIEEE().convertToFloat(); } - bool operator==(const APFloat &) const = delete; + bool operator==(const APFloat &RHS) const { return compare(RHS) == cmpEqual; } + + bool operator!=(const APFloat &RHS) const { return compare(RHS) != cmpEqual; } + + bool operator<(const APFloat &RHS) const { + return compare(RHS) == cmpLessThan; + } + + bool operator>(const APFloat &RHS) const { + return compare(RHS) == cmpGreaterThan; + } + + bool operator<=(const APFloat &RHS) const { + cmpResult Res = compare(RHS); + return Res == cmpLessThan || Res == cmpEqual; + } + + bool operator>=(const APFloat &RHS) const { + cmpResult Res = compare(RHS); + return Res == cmpGreaterThan || Res == cmpEqual; + } cmpResult compare(const APFloat &RHS) const { assert(&getSemantics() == &RHS.getSemantics() && @@ -1249,7 +1285,7 @@ inline APFloat minnum(const APFloat &A, const APFloat &B) { return B; if (B.isNaN()) return A; - return (B.compare(A) == APFloat::cmpLessThan) ? B : A; + return B < A ? B : A; } /// Implements IEEE maxNum semantics. Returns the larger of the 2 arguments if @@ -1260,7 +1296,7 @@ inline APFloat maxnum(const APFloat &A, const APFloat &B) { return B; if (B.isNaN()) return A; - return (A.compare(B) == APFloat::cmpLessThan) ? B : A; + return A < B ? B : A; } /// Implements IEEE 754-2018 minimum semantics. Returns the smaller of 2 @@ -1273,7 +1309,7 @@ inline APFloat minimum(const APFloat &A, const APFloat &B) { return B; if (A.isZero() && B.isZero() && (A.isNegative() != B.isNegative())) return A.isNegative() ? A : B; - return (B.compare(A) == APFloat::cmpLessThan) ? B : A; + return B < A ? B : A; } /// Implements IEEE 754-2018 maximum semantics. Returns the larger of 2 @@ -1286,7 +1322,7 @@ inline APFloat maximum(const APFloat &A, const APFloat &B) { return B; if (A.isZero() && B.isZero() && (A.isNegative() != B.isNegative())) return A.isNegative() ? B : A; - return (A.compare(B) == APFloat::cmpLessThan) ? B : A; + return A < B ? B : A; } } // namespace llvm diff --git a/gnu/llvm/llvm/include/llvm/ADT/APInt.h b/gnu/llvm/llvm/include/llvm/ADT/APInt.h index 0791a6d686a..f7df648d27e 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/APInt.h +++ b/gnu/llvm/llvm/include/llvm/ADT/APInt.h @@ -84,7 +84,7 @@ public: UP, }; - static const WordType WORDTYPE_MAX = ~WordType(0); + static constexpr WordType WORDTYPE_MAX = ~WordType(0); private: /// This union is used to store the integer value. When the @@ -616,9 +616,11 @@ public: } /// Wrap version of getBitsSet. - /// If \p hiBit is no less than \p loBit, this is same with getBitsSet. - /// If \p hiBit is less than \p loBit, the set bits "wrap". For example, with - /// parameters (32, 28, 4), you would get 0xF000000F. + /// If \p hiBit is bigger than \p loBit, this is same with getBitsSet. + /// If \p hiBit is not bigger than \p loBit, the set bits "wrap". For example, + /// with parameters (32, 28, 4), you would get 0xF000000F. + /// If \p hiBit is equal to \p loBit, you would get a result with all bits + /// set. static APInt getBitsSetWithWrap(unsigned numBits, unsigned loBit, unsigned hiBit) { APInt Res(numBits, 0); @@ -1448,12 +1450,13 @@ public: } /// Set the bits from loBit (inclusive) to hiBit (exclusive) to 1. - /// This function handles "wrap" case when \p loBit > \p hiBit, and calls - /// setBits when \p loBit <= \p hiBit. + /// This function handles "wrap" case when \p loBit >= \p hiBit, and calls + /// setBits when \p loBit < \p hiBit. + /// For \p loBit == \p hiBit wrap case, set every bit to 1. void setBitsWithWrap(unsigned loBit, unsigned hiBit) { assert(hiBit <= BitWidth && "hiBit out of range"); assert(loBit <= BitWidth && "loBit out of range"); - if (loBit <= hiBit) { + if (loBit < hiBit) { setBits(loBit, hiBit); return; } @@ -2283,7 +2286,7 @@ void StoreIntToMemory(const APInt &IntVal, uint8_t *Dst, unsigned StoreBytes); /// LoadIntFromMemory - Loads the integer stored in the LoadBytes bytes starting /// from Src into IntVal, which is assumed to be wide enough and to hold zero. -void LoadIntFromMemory(APInt &IntVal, uint8_t *Src, unsigned LoadBytes); +void LoadIntFromMemory(APInt &IntVal, const uint8_t *Src, unsigned LoadBytes); } // namespace llvm diff --git a/gnu/llvm/llvm/include/llvm/ADT/AllocatorList.h b/gnu/llvm/llvm/include/llvm/ADT/AllocatorList.h index 405a2e4264d..447d7a7538d 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/AllocatorList.h +++ b/gnu/llvm/llvm/include/llvm/ADT/AllocatorList.h @@ -110,8 +110,8 @@ private: template IteratorImpl(const IteratorImpl &X, - typename std::enable_if::value>::type * = nullptr) + std::enable_if_t::value> * = nullptr) : base_type(X.wrapped()) {} ~IteratorImpl() = default; diff --git a/gnu/llvm/llvm/include/llvm/ADT/Any.h b/gnu/llvm/llvm/include/llvm/ADT/Any.h index 49657e02a99..0aded628cda 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/Any.h +++ b/gnu/llvm/llvm/include/llvm/ADT/Any.h @@ -59,26 +59,26 @@ public: // When T is Any or T is not copy-constructible we need to explicitly disable // the forwarding constructor so that the copy constructor gets selected // instead. - template < - typename T, - typename std::enable_if< - llvm::conjunction< - llvm::negation::type, Any>>, - // We also disable this overload when an `Any` object can be - // converted to the parameter type because in that case, this - // constructor may combine with that conversion during overload - // resolution for determining copy constructibility, and then - // when we try to determine copy constructibility below we may - // infinitely recurse. This is being evaluated by the standards - // committee as a potential DR in `std::any` as well, but we're - // going ahead and adopting it to work-around usage of `Any` with - // types that need to be implicitly convertible from an `Any`. - llvm::negation::type>>, - std::is_copy_constructible::type>>::value, - int>::type = 0> + template , Any>>, + // We also disable this overload when an `Any` object can be + // converted to the parameter type because in that case, + // this constructor may combine with that conversion during + // overload resolution for determining copy + // constructibility, and then when we try to determine copy + // constructibility below we may infinitely recurse. This is + // being evaluated by the standards committee as a potential + // DR in `std::any` as well, but we're going ahead and + // adopting it to work-around usage of `Any` with types that + // need to be implicitly convertible from an `Any`. + llvm::negation>>, + std::is_copy_constructible>>::value, + int> = 0> Any(T &&Value) { - using U = typename std::decay::type; - Storage = std::make_unique>(std::forward(Value)); + Storage = + std::make_unique>>(std::forward(Value)); } Any(Any &&Other) : Storage(std::move(Other.Storage)) {} @@ -114,32 +114,27 @@ template const char Any::TypeId::Id = 0; template bool any_isa(const Any &Value) { if (!Value.Storage) return false; - using U = - typename std::remove_cv::type>::type; - return Value.Storage->id() == &Any::TypeId::Id; + return Value.Storage->id() == + &Any::TypeId>>::Id; } template T any_cast(const Any &Value) { - using U = - typename std::remove_cv::type>::type; - return static_cast(*any_cast(&Value)); + return static_cast( + *any_cast>>(&Value)); } template T any_cast(Any &Value) { - using U = - typename std::remove_cv::type>::type; - return static_cast(*any_cast(&Value)); + return static_cast( + *any_cast>>(&Value)); } template T any_cast(Any &&Value) { - using U = - typename std::remove_cv::type>::type; - return static_cast(std::move(*any_cast(&Value))); + return static_cast(std::move( + *any_cast>>(&Value))); } template const T *any_cast(const Any *Value) { - using U = - typename std::remove_cv::type>::type; + using U = std::remove_cv_t>; assert(Value && any_isa(*Value) && "Bad any cast!"); if (!Value || !any_isa(*Value)) return nullptr; @@ -147,7 +142,7 @@ template const T *any_cast(const Any *Value) { } template T *any_cast(Any *Value) { - using U = typename std::decay::type; + using U = std::decay_t; assert(Value && any_isa(*Value) && "Bad any cast!"); if (!Value || !any_isa(*Value)) return nullptr; diff --git a/gnu/llvm/llvm/include/llvm/ADT/ArrayRef.h b/gnu/llvm/llvm/include/llvm/ADT/ArrayRef.h index 3d22442918c..5ed4d0766c3 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/ArrayRef.h +++ b/gnu/llvm/llvm/include/llvm/ADT/ArrayRef.h @@ -38,7 +38,7 @@ namespace llvm { /// This is intended to be trivially copyable, so it should be passed by /// value. template - class LLVM_NODISCARD ArrayRef { + class LLVM_GSL_POINTER LLVM_NODISCARD ArrayRef { public: using iterator = const T *; using const_iterator = const T *; @@ -114,30 +114,28 @@ namespace llvm { /// Construct an ArrayRef from ArrayRef. This uses SFINAE to /// ensure that only ArrayRefs of pointers can be converted. template - ArrayRef( - const ArrayRef &A, - typename std::enable_if< - std::is_convertible::value>::type * = nullptr) - : Data(A.data()), Length(A.size()) {} + ArrayRef(const ArrayRef &A, + std::enable_if_t::value> + * = nullptr) + : Data(A.data()), Length(A.size()) {} /// Construct an ArrayRef from a SmallVector. This is /// templated in order to avoid instantiating SmallVectorTemplateCommon /// whenever we copy-construct an ArrayRef. - template + template /*implicit*/ ArrayRef( - const SmallVectorTemplateCommon &Vec, - typename std::enable_if< - std::is_convertible::value>::type * = nullptr) - : Data(Vec.data()), Length(Vec.size()) { - } + const SmallVectorTemplateCommon &Vec, + std::enable_if_t::value> * = + nullptr) + : Data(Vec.data()), Length(Vec.size()) {} /// Construct an ArrayRef from std::vector. This uses SFINAE /// to ensure that only vectors of pointers can be converted. - template + template ArrayRef(const std::vector &Vec, - typename std::enable_if< - std::is_convertible::value>::type* = 0) - : Data(Vec.data()), Length(Vec.size()) {} + std::enable_if_t::value> + * = 0) + : Data(Vec.data()), Length(Vec.size()) {} /// @} /// @name Simple Operations @@ -256,7 +254,7 @@ namespace llvm { /// The declaration here is extra complicated so that "arrayRef = {}" /// continues to select the move assignment operator. template - typename std::enable_if::value, ArrayRef>::type & + std::enable_if_t::value, ArrayRef> & operator=(U &&Temporary) = delete; /// Disallow accidental assignment from a temporary. @@ -264,7 +262,7 @@ namespace llvm { /// The declaration here is extra complicated so that "arrayRef = {}" /// continues to select the move assignment operator. template - typename std::enable_if::value, ArrayRef>::type & + std::enable_if_t::value, ArrayRef> & operator=(std::initializer_list) = delete; /// @} @@ -308,17 +306,17 @@ namespace llvm { /// Construct an empty MutableArrayRef from None. /*implicit*/ MutableArrayRef(NoneType) : ArrayRef() {} - /// Construct an MutableArrayRef from a single element. + /// Construct a MutableArrayRef from a single element. /*implicit*/ MutableArrayRef(T &OneElt) : ArrayRef(OneElt) {} - /// Construct an MutableArrayRef from a pointer and length. + /// Construct a MutableArrayRef from a pointer and length. /*implicit*/ MutableArrayRef(T *data, size_t length) : ArrayRef(data, length) {} - /// Construct an MutableArrayRef from a range. + /// Construct a MutableArrayRef from a range. MutableArrayRef(T *begin, T *end) : ArrayRef(begin, end) {} - /// Construct an MutableArrayRef from a SmallVector. + /// Construct a MutableArrayRef from a SmallVector. /*implicit*/ MutableArrayRef(SmallVectorImpl &Vec) : ArrayRef(Vec) {} @@ -326,12 +324,12 @@ namespace llvm { /*implicit*/ MutableArrayRef(std::vector &Vec) : ArrayRef(Vec) {} - /// Construct an ArrayRef from a std::array + /// Construct a MutableArrayRef from a std::array template /*implicit*/ constexpr MutableArrayRef(std::array &Arr) : ArrayRef(Arr) {} - /// Construct an MutableArrayRef from a C array. + /// Construct a MutableArrayRef from a C array. template /*implicit*/ constexpr MutableArrayRef(T (&Arr)[N]) : ArrayRef(Arr) {} @@ -534,11 +532,21 @@ namespace llvm { return LHS.equals(RHS); } - template + template + inline bool operator==(SmallVectorImpl &LHS, ArrayRef RHS) { + return ArrayRef(LHS).equals(RHS); + } + + template inline bool operator!=(ArrayRef LHS, ArrayRef RHS) { return !(LHS == RHS); } + template + inline bool operator!=(SmallVectorImpl &LHS, ArrayRef RHS) { + return !(LHS == RHS); + } + /// @} template hash_code hash_value(ArrayRef S) { diff --git a/gnu/llvm/llvm/include/llvm/ADT/BitVector.h b/gnu/llvm/llvm/include/llvm/ADT/BitVector.h index 5284be8c4a0..a8d0f07af94 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/BitVector.h +++ b/gnu/llvm/llvm/include/llvm/ADT/BitVector.h @@ -14,6 +14,7 @@ #define LLVM_ADT_BITVECTOR_H #include "llvm/ADT/ArrayRef.h" +#include "llvm/ADT/DenseMapInfo.h" #include "llvm/ADT/iterator_range.h" #include "llvm/Support/MathExtras.h" #include @@ -531,24 +532,10 @@ public: // Comparison operators. bool operator==(const BitVector &RHS) const { - unsigned ThisWords = NumBitWords(size()); - unsigned RHSWords = NumBitWords(RHS.size()); - unsigned i; - for (i = 0; i != std::min(ThisWords, RHSWords); ++i) - if (Bits[i] != RHS.Bits[i]) - return false; - - // Verify that any extra words are all zeros. - if (i != ThisWords) { - for (; i != ThisWords; ++i) - if (Bits[i]) - return false; - } else if (i != RHSWords) { - for (; i != RHSWords; ++i) - if (RHS.Bits[i]) - return false; - } - return true; + if (size() != RHS.size()) + return false; + unsigned NumWords = NumBitWords(size()); + return Bits.take_front(NumWords) == RHS.Bits.take_front(NumWords); } bool operator!=(const BitVector &RHS) const { @@ -719,6 +706,14 @@ public: if (this == &RHS) return *this; Size = RHS.size(); + + // Handle tombstone when the BitVector is a key of a DenseHash. + if (RHS.isInvalid()) { + std::free(Bits.data()); + Bits = None; + return *this; + } + unsigned RHSWords = NumBitWords(Size); if (Size <= getBitCapacity()) { if (Size) @@ -758,6 +753,16 @@ public: std::swap(Size, RHS.Size); } + void invalid() { + assert(!Size && Bits.empty()); + Size = (unsigned)-1; + } + bool isInvalid() const { return Size == (unsigned)-1; } + + ArrayRef getData() const { + return Bits.take_front(NumBitWords(size())); + } + //===--------------------------------------------------------------------===// // Portable bit mask operations. //===--------------------------------------------------------------------===// @@ -932,6 +937,23 @@ inline size_t capacity_in_bytes(const BitVector &X) { return X.getMemorySize(); } +template <> struct DenseMapInfo { + static inline BitVector getEmptyKey() { return BitVector(); } + static inline BitVector getTombstoneKey() { + BitVector V; + V.invalid(); + return V; + } + static unsigned getHashValue(const BitVector &V) { + return DenseMapInfo>>::getHashValue( + std::make_pair(V.size(), V.getData())); + } + static bool isEqual(const BitVector &LHS, const BitVector &RHS) { + if (LHS.isInvalid() || RHS.isInvalid()) + return LHS.isInvalid() == RHS.isInvalid(); + return LHS == RHS; + } +}; } // end namespace llvm namespace std { diff --git a/gnu/llvm/llvm/include/llvm/ADT/Bitfields.h b/gnu/llvm/llvm/include/llvm/ADT/Bitfields.h new file mode 100644 index 00000000000..d93f6483fa5 --- /dev/null +++ b/gnu/llvm/llvm/include/llvm/ADT/Bitfields.h @@ -0,0 +1,289 @@ +//===-- llvm/ADT/Bitfield.h - Get and Set bits in an integer ---*- C++ -*--===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +/// +/// \file +/// This file implements methods to test, set and extract typed bits from packed +/// unsigned integers. +/// +/// Why not C++ bitfields? +/// ---------------------- +/// C++ bitfields do not offer control over the bit layout nor consistent +/// behavior when it comes to out of range values. +/// For instance, the layout is implementation defined and adjacent bits may be +/// packed together but are not required to. This is problematic when storage is +/// sparse and data must be stored in a particular integer type. +/// +/// The methods provided in this file ensure precise control over the +/// layout/storage as well as protection against out of range values. +/// +/// Usage example +/// ------------- +/// \code{.cpp} +/// uint8_t Storage = 0; +/// +/// // Store and retrieve a single bit as bool. +/// using Bool = Bitfield::Element; +/// Bitfield::set(Storage, true); +/// EXPECT_EQ(Storage, 0b00000001); +/// // ^ +/// EXPECT_EQ(Bitfield::get(Storage), true); +/// +/// // Store and retrieve a 2 bit typed enum. +/// // Note: enum underlying type must be unsigned. +/// enum class SuitEnum : uint8_t { CLUBS, DIAMONDS, HEARTS, SPADES }; +/// // Note: enum maximum value needs to be passed in as last parameter. +/// using Suit = Bitfield::Element; +/// Bitfield::set(Storage, SuitEnum::HEARTS); +/// EXPECT_EQ(Storage, 0b00000101); +/// // ^^ +/// EXPECT_EQ(Bitfield::get(Storage), SuitEnum::HEARTS); +/// +/// // Store and retrieve a 5 bit value as unsigned. +/// using Value = Bitfield::Element; +/// Bitfield::set(Storage, 10); +/// EXPECT_EQ(Storage, 0b01010101); +/// // ^^^^^ +/// EXPECT_EQ(Bitfield::get(Storage), 10U); +/// +/// // Interpret the same 5 bit value as signed. +/// using SignedValue = Bitfield::Element; +/// Bitfield::set(Storage, -2); +/// EXPECT_EQ(Storage, 0b11110101); +/// // ^^^^^ +/// EXPECT_EQ(Bitfield::get(Storage), -2); +/// +/// // Ability to efficiently test if a field is non zero. +/// EXPECT_TRUE(Bitfield::test(Storage)); +/// +/// // Alter Storage changes value. +/// Storage = 0; +/// EXPECT_EQ(Bitfield::get(Storage), false); +/// EXPECT_EQ(Bitfield::get(Storage), SuitEnum::CLUBS); +/// EXPECT_EQ(Bitfield::get(Storage), 0U); +/// EXPECT_EQ(Bitfield::get(Storage), 0); +/// +/// Storage = 255; +/// EXPECT_EQ(Bitfield::get(Storage), true); +/// EXPECT_EQ(Bitfield::get(Storage), SuitEnum::SPADES); +/// EXPECT_EQ(Bitfield::get(Storage), 31U); +/// EXPECT_EQ(Bitfield::get(Storage), -1); +/// \endcode +/// +//===----------------------------------------------------------------------===// + +#ifndef LLVM_ADT_BITFIELDS_H +#define LLVM_ADT_BITFIELDS_H + +#include +#include // CHAR_BIT +#include // size_t +#include // uintXX_t +#include // numeric_limits +#include + +namespace llvm { + +namespace bitfields_details { + +/// A struct defining useful bit patterns for n-bits integer types. +template struct BitPatterns { + /// Bit patterns are forged using the equivalent `Unsigned` type because of + /// undefined operations over signed types (e.g. Bitwise shift operators). + /// Moreover same size casting from unsigned to signed is well defined but not + /// the other way around. + using Unsigned = typename std::make_unsigned::type; + static_assert(sizeof(Unsigned) == sizeof(T), "Types must have same size"); + + static constexpr unsigned TypeBits = sizeof(Unsigned) * CHAR_BIT; + static_assert(TypeBits >= Bits, "n-bit must fit in T"); + + /// e.g. with TypeBits == 8 and Bits == 6. + static constexpr Unsigned AllZeros = Unsigned(0); // 00000000 + static constexpr Unsigned AllOnes = ~Unsigned(0); // 11111111 + static constexpr Unsigned Umin = AllZeros; // 00000000 + static constexpr Unsigned Umax = AllOnes >> (TypeBits - Bits); // 00111111 + static constexpr Unsigned SignBitMask = Unsigned(1) << (Bits - 1); // 00100000 + static constexpr Unsigned Smax = Umax >> 1U; // 00011111 + static constexpr Unsigned Smin = ~Smax; // 11100000 + static constexpr Unsigned SignExtend = Unsigned(Smin << 1U); // 11000000 +}; + +/// `Compressor` is used to manipulate the bits of a (possibly signed) integer +/// type so it can be packed and unpacked into a `bits` sized integer, +/// `Compressor` is specialized on signed-ness so no runtime cost is incurred. +/// The `pack` method also checks that the passed in `UserValue` is valid. +template ::value> +struct Compressor { + static_assert(std::is_unsigned::value, "T is unsigned"); + using BP = BitPatterns; + + static T pack(T UserValue, T UserMaxValue) { + assert(UserValue <= UserMaxValue && "value is too big"); + assert(UserValue <= BP::Umax && "value is too big"); + return UserValue; + } + + static T unpack(T StorageValue) { return StorageValue; } +}; + +template struct Compressor { + static_assert(std::is_signed::value, "T is signed"); + using BP = BitPatterns; + + static T pack(T UserValue, T UserMaxValue) { + assert(UserValue <= UserMaxValue && "value is too big"); + assert(UserValue <= T(BP::Smax) && "value is too big"); + assert(UserValue >= T(BP::Smin) && "value is too small"); + if (UserValue < 0) + UserValue &= ~BP::SignExtend; + return UserValue; + } + + static T unpack(T StorageValue) { + if (StorageValue >= T(BP::SignBitMask)) + StorageValue |= BP::SignExtend; + return StorageValue; + } +}; + +/// Impl is where Bifield description and Storage are put together to interact +/// with values. +template struct Impl { + static_assert(std::is_unsigned::value, + "Storage must be unsigned"); + using IntegerType = typename Bitfield::IntegerType; + using C = Compressor; + using BP = BitPatterns; + + static constexpr size_t StorageBits = sizeof(StorageType) * CHAR_BIT; + static_assert(Bitfield::FirstBit <= StorageBits, "Data must fit in mask"); + static_assert(Bitfield::LastBit <= StorageBits, "Data must fit in mask"); + static constexpr StorageType Mask = BP::Umax << Bitfield::Shift; + + /// Checks `UserValue` is within bounds and packs it between `FirstBit` and + /// `LastBit` of `Packed` leaving the rest unchanged. + static void update(StorageType &Packed, IntegerType UserValue) { + const StorageType StorageValue = C::pack(UserValue, Bitfield::UserMaxValue); + Packed &= ~Mask; + Packed |= StorageValue << Bitfield::Shift; + } + + /// Interprets bits between `FirstBit` and `LastBit` of `Packed` as + /// an`IntegerType`. + static IntegerType extract(StorageType Packed) { + const StorageType StorageValue = (Packed & Mask) >> Bitfield::Shift; + return C::unpack(StorageValue); + } + + /// Interprets bits between `FirstBit` and `LastBit` of `Packed` as + /// an`IntegerType`. + static StorageType test(StorageType Packed) { return Packed & Mask; } +}; + +/// `Bitfield` deals with the following type: +/// - unsigned enums +/// - signed and unsigned integer +/// - `bool` +/// Internally though we only manipulate integer with well defined and +/// consistent semantics, this excludes typed enums and `bool` that are replaced +/// with their unsigned counterparts. The correct type is restored in the public +/// API. +template ::value> +struct ResolveUnderlyingType { + using type = typename std::underlying_type::type; +}; +template struct ResolveUnderlyingType { + using type = T; +}; +template <> struct ResolveUnderlyingType { + /// In case sizeof(bool) != 1, replace `void` by an additionnal + /// std::conditional. + using type = std::conditional::type; +}; + +} // namespace bitfields_details + +/// Holds functions to get, set or test bitfields. +struct Bitfield { + /// Describes an element of a Bitfield. This type is then used with the + /// Bitfield static member functions. + /// \tparam T The type of the field once in unpacked form. + /// \tparam Offset The position of the first bit. + /// \tparam Size The size of the field. + /// \tparam MaxValue For enums the maximum enum allowed. + template ::value + ? T(0) // coupled with static_assert below + : std::numeric_limits::max()> + struct Element { + using Type = T; + using IntegerType = + typename bitfields_details::ResolveUnderlyingType::type; + static constexpr unsigned Shift = Offset; + static constexpr unsigned Bits = Size; + static constexpr unsigned FirstBit = Offset; + static constexpr unsigned LastBit = Shift + Bits - 1; + static constexpr unsigned NextBit = Shift + Bits; + + private: + template friend struct bitfields_details::Impl; + + static_assert(Bits > 0, "Bits must be non zero"); + static constexpr size_t TypeBits = sizeof(IntegerType) * CHAR_BIT; + static_assert(Bits <= TypeBits, "Bits may not be greater than T size"); + static_assert(!std::is_enum::value || MaxValue != T(0), + "Enum Bitfields must provide a MaxValue"); + static_assert(!std::is_enum::value || + std::is_unsigned::value, + "Enum must be unsigned"); + static_assert(std::is_integral::value && + std::numeric_limits::is_integer, + "IntegerType must be an integer type"); + + static constexpr IntegerType UserMaxValue = + static_cast(MaxValue); + }; + + /// Unpacks the field from the `Packed` value. + template + static typename Bitfield::Type get(StorageType Packed) { + using I = bitfields_details::Impl; + return static_cast(I::extract(Packed)); + } + + /// Return a non-zero value if the field is non-zero. + /// It is more efficient than `getField`. + template + static StorageType test(StorageType Packed) { + using I = bitfields_details::Impl; + return I::test(Packed); + } + + /// Sets the typed value in the provided `Packed` value. + /// The method will asserts if the provided value is too big to fit in. + template + static void set(StorageType &Packed, typename Bitfield::Type Value) { + using I = bitfields_details::Impl; + I::update(Packed, static_cast(Value)); + } + + /// Returns whether the two bitfields share common bits. + template static constexpr bool isOverlapping() { + return A::LastBit >= B::FirstBit && B::LastBit >= A::FirstBit; + } + + template static constexpr bool areContiguous() { return true; } + template + static constexpr bool areContiguous() { + return A::NextBit == B::FirstBit && areContiguous(); + } +}; + +} // namespace llvm + +#endif // LLVM_ADT_BITFIELDS_H diff --git a/gnu/llvm/llvm/include/llvm/ADT/BitmaskEnum.h b/gnu/llvm/llvm/include/llvm/ADT/BitmaskEnum.h index 1a18bc721b2..89e5508e08e 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/BitmaskEnum.h +++ b/gnu/llvm/llvm/include/llvm/ADT/BitmaskEnum.h @@ -71,49 +71,49 @@ struct is_bitmask_enum : std::false_type {}; template struct is_bitmask_enum< - E, typename std::enable_if= - 0>::type> : std::true_type {}; + E, std::enable_if_t= 0>> + : std::true_type {}; namespace BitmaskEnumDetail { /// Get a bitmask with 1s in all places up to the high-order bit of E's largest /// value. -template typename std::underlying_type::type Mask() { +template std::underlying_type_t Mask() { // On overflow, NextPowerOf2 returns zero with the type uint64_t, so // subtracting 1 gives us the mask with all bits set, like we want. - return NextPowerOf2(static_cast::type>( + return NextPowerOf2(static_cast>( E::LLVM_BITMASK_LARGEST_ENUMERATOR)) - 1; } /// Check that Val is in range for E, and return Val cast to E's underlying /// type. -template typename std::underlying_type::type Underlying(E Val) { - auto U = static_cast::type>(Val); +template std::underlying_type_t Underlying(E Val) { + auto U = static_cast>(Val); assert(U >= 0 && "Negative enum values are not allowed."); assert(U <= Mask() && "Enum value too large (or largest val too small?)"); return U; } -template ::value>::type> +constexpr unsigned bitWidth(uint64_t Value) { + return Value ? 1 + bitWidth(Value >> 1) : 0; +} + +template ::value>> E operator~(E Val) { return static_cast(~Underlying(Val) & Mask()); } -template ::value>::type> +template ::value>> E operator|(E LHS, E RHS) { return static_cast(Underlying(LHS) | Underlying(RHS)); } -template ::value>::type> +template ::value>> E operator&(E LHS, E RHS) { return static_cast(Underlying(LHS) & Underlying(RHS)); } -template ::value>::type> +template ::value>> E operator^(E LHS, E RHS) { return static_cast(Underlying(LHS) ^ Underlying(RHS)); } @@ -121,22 +121,19 @@ E operator^(E LHS, E RHS) { // |=, &=, and ^= return a reference to LHS, to match the behavior of the // operators on builtin types. -template ::value>::type> +template ::value>> E &operator|=(E &LHS, E RHS) { LHS = LHS | RHS; return LHS; } -template ::value>::type> +template ::value>> E &operator&=(E &LHS, E RHS) { LHS = LHS & RHS; return LHS; } -template ::value>::type> +template ::value>> E &operator^=(E &LHS, E RHS) { LHS = LHS ^ RHS; return LHS; @@ -146,6 +143,10 @@ E &operator^=(E &LHS, E RHS) { // Enable bitmask enums in namespace ::llvm and all nested namespaces. LLVM_ENABLE_BITMASK_ENUMS_IN_NAMESPACE(); +template ::value>> +constexpr unsigned BitWidth = BitmaskEnumDetail::bitWidth(uint64_t{ + static_cast>( + E::LLVM_BITMASK_LARGEST_ENUMERATOR)}); } // namespace llvm diff --git a/gnu/llvm/llvm/include/llvm/ADT/CachedHashString.h b/gnu/llvm/llvm/include/llvm/ADT/CachedHashString.h index 80144fb87e0..6233d0fc08f 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/CachedHashString.h +++ b/gnu/llvm/llvm/include/llvm/ADT/CachedHashString.h @@ -19,9 +19,8 @@ #ifndef LLVM_ADT_CACHED_HASH_STRING_H #define LLVM_ADT_CACHED_HASH_STRING_H -#include "llvm/ADT/DenseMap.h" +#include "llvm/ADT/DenseMapInfo.h" #include "llvm/ADT/StringRef.h" -#include "llvm/Support/raw_ostream.h" namespace llvm { diff --git a/gnu/llvm/llvm/include/llvm/ADT/CoalescingBitVector.h b/gnu/llvm/llvm/include/llvm/ADT/CoalescingBitVector.h new file mode 100644 index 00000000000..0a7dcfe2263 --- /dev/null +++ b/gnu/llvm/llvm/include/llvm/ADT/CoalescingBitVector.h @@ -0,0 +1,443 @@ +//===- llvm/ADT/CoalescingBitVector.h - A coalescing bitvector --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +/// +/// \file A bitvector that uses an IntervalMap to coalesce adjacent elements +/// into intervals. +/// +//===----------------------------------------------------------------------===// + +#ifndef LLVM_ADT_COALESCINGBITVECTOR_H +#define LLVM_ADT_COALESCINGBITVECTOR_H + +#include "llvm/ADT/IntervalMap.h" +#include "llvm/ADT/SmallVector.h" +#include "llvm/ADT/iterator_range.h" +#include "llvm/Support/Debug.h" +#include "llvm/Support/raw_ostream.h" + +#include +#include + +namespace llvm { + +/// A bitvector that, under the hood, relies on an IntervalMap to coalesce +/// elements into intervals. Good for representing sets which predominantly +/// contain contiguous ranges. Bad for representing sets with lots of gaps +/// between elements. +/// +/// Compared to SparseBitVector, CoalescingBitVector offers more predictable +/// performance for non-sequential find() operations. +/// +/// \tparam IndexT - The type of the index into the bitvector. +template class CoalescingBitVector { + static_assert(std::is_unsigned::value, + "Index must be an unsigned integer."); + + using ThisT = CoalescingBitVector; + + /// An interval map for closed integer ranges. The mapped values are unused. + using MapT = IntervalMap; + + using UnderlyingIterator = typename MapT::const_iterator; + + using IntervalT = std::pair; + +public: + using Allocator = typename MapT::Allocator; + + /// Construct by passing in a CoalescingBitVector::Allocator + /// reference. + CoalescingBitVector(Allocator &Alloc) + : Alloc(&Alloc), Intervals(Alloc) {} + + /// \name Copy/move constructors and assignment operators. + /// @{ + + CoalescingBitVector(const ThisT &Other) + : Alloc(Other.Alloc), Intervals(*Other.Alloc) { + set(Other); + } + + ThisT &operator=(const ThisT &Other) { + clear(); + set(Other); + return *this; + } + + CoalescingBitVector(ThisT &&Other) = delete; + ThisT &operator=(ThisT &&Other) = delete; + + /// @} + + /// Clear all the bits. + void clear() { Intervals.clear(); } + + /// Check whether no bits are set. + bool empty() const { return Intervals.empty(); } + + /// Count the number of set bits. + unsigned count() const { + unsigned Bits = 0; + for (auto It = Intervals.begin(), End = Intervals.end(); It != End; ++It) + Bits += 1 + It.stop() - It.start(); + return Bits; + } + + /// Set the bit at \p Index. + /// + /// This method does /not/ support setting a bit that has already been set, + /// for efficiency reasons. If possible, restructure your code to not set the + /// same bit multiple times, or use \ref test_and_set. + void set(IndexT Index) { + assert(!test(Index) && "Setting already-set bits not supported/efficient, " + "IntervalMap will assert"); + insert(Index, Index); + } + + /// Set the bits set in \p Other. + /// + /// This method does /not/ support setting already-set bits, see \ref set + /// for the rationale. For a safe set union operation, use \ref operator|=. + void set(const ThisT &Other) { + for (auto It = Other.Intervals.begin(), End = Other.Intervals.end(); + It != End; ++It) + insert(It.start(), It.stop()); + } + + /// Set the bits at \p Indices. Used for testing, primarily. + void set(std::initializer_list Indices) { + for (IndexT Index : Indices) + set(Index); + } + + /// Check whether the bit at \p Index is set. + bool test(IndexT Index) const { + const auto It = Intervals.find(Index); + if (It == Intervals.end()) + return false; + assert(It.stop() >= Index && "Interval must end after Index"); + return It.start() <= Index; + } + + /// Set the bit at \p Index. Supports setting an already-set bit. + void test_and_set(IndexT Index) { + if (!test(Index)) + set(Index); + } + + /// Reset the bit at \p Index. Supports resetting an already-unset bit. + void reset(IndexT Index) { + auto It = Intervals.find(Index); + if (It == Intervals.end()) + return; + + // Split the interval containing Index into up to two parts: one from + // [Start, Index-1] and another from [Index+1, Stop]. If Index is equal to + // either Start or Stop, we create one new interval. If Index is equal to + // both Start and Stop, we simply erase the existing interval. + IndexT Start = It.start(); + if (Index < Start) + // The index was not set. + return; + IndexT Stop = It.stop(); + assert(Index <= Stop && "Wrong interval for index"); + It.erase(); + if (Start < Index) + insert(Start, Index - 1); + if (Index < Stop) + insert(Index + 1, Stop); + } + + /// Set union. If \p RHS is guaranteed to not overlap with this, \ref set may + /// be a faster alternative. + void operator|=(const ThisT &RHS) { + // Get the overlaps between the two interval maps. + SmallVector Overlaps; + getOverlaps(RHS, Overlaps); + + // Insert the non-overlapping parts of all the intervals from RHS. + for (auto It = RHS.Intervals.begin(), End = RHS.Intervals.end(); + It != End; ++It) { + IndexT Start = It.start(); + IndexT Stop = It.stop(); + SmallVector NonOverlappingParts; + getNonOverlappingParts(Start, Stop, Overlaps, NonOverlappingParts); + for (IntervalT AdditivePortion : NonOverlappingParts) + insert(AdditivePortion.first, AdditivePortion.second); + } + } + + /// Set intersection. + void operator&=(const ThisT &RHS) { + // Get the overlaps between the two interval maps (i.e. the intersection). + SmallVector Overlaps; + getOverlaps(RHS, Overlaps); + // Rebuild the interval map, including only the overlaps. + clear(); + for (IntervalT Overlap : Overlaps) + insert(Overlap.first, Overlap.second); + } + + /// Reset all bits present in \p Other. + void intersectWithComplement(const ThisT &Other) { + SmallVector Overlaps; + if (!getOverlaps(Other, Overlaps)) { + // If there is no overlap with Other, the intersection is empty. + return; + } + + // Delete the overlapping intervals. Split up intervals that only partially + // intersect an overlap. + for (IntervalT Overlap : Overlaps) { + IndexT OlapStart, OlapStop; + std::tie(OlapStart, OlapStop) = Overlap; + + auto It = Intervals.find(OlapStart); + IndexT CurrStart = It.start(); + IndexT CurrStop = It.stop(); + assert(CurrStart <= OlapStart && OlapStop <= CurrStop && + "Expected some intersection!"); + + // Split the overlap interval into up to two parts: one from [CurrStart, + // OlapStart-1] and another from [OlapStop+1, CurrStop]. If OlapStart is + // equal to CurrStart, the first split interval is unnecessary. Ditto for + // when OlapStop is equal to CurrStop, we omit the second split interval. + It.erase(); + if (CurrStart < OlapStart) + insert(CurrStart, OlapStart - 1); + if (OlapStop < CurrStop) + insert(OlapStop + 1, CurrStop); + } + } + + bool operator==(const ThisT &RHS) const { + // We cannot just use std::equal because it checks the dereferenced values + // of an iterator pair for equality, not the iterators themselves. In our + // case that results in comparison of the (unused) IntervalMap values. + auto ItL = Intervals.begin(); + auto ItR = RHS.Intervals.begin(); + while (ItL != Intervals.end() && ItR != RHS.Intervals.end() && + ItL.start() == ItR.start() && ItL.stop() == ItR.stop()) { + ++ItL; + ++ItR; + } + return ItL == Intervals.end() && ItR == RHS.Intervals.end(); + } + + bool operator!=(const ThisT &RHS) const { return !operator==(RHS); } + + class const_iterator + : public std::iterator { + friend class CoalescingBitVector; + + // For performance reasons, make the offset at the end different than the + // one used in \ref begin, to optimize the common `It == end()` pattern. + static constexpr unsigned kIteratorAtTheEndOffset = ~0u; + + UnderlyingIterator MapIterator; + unsigned OffsetIntoMapIterator = 0; + + // Querying the start/stop of an IntervalMap iterator can be very expensive. + // Cache these values for performance reasons. + IndexT CachedStart = IndexT(); + IndexT CachedStop = IndexT(); + + void setToEnd() { + OffsetIntoMapIterator = kIteratorAtTheEndOffset; + CachedStart = IndexT(); + CachedStop = IndexT(); + } + + /// MapIterator has just changed, reset the cached state to point to the + /// start of the new underlying iterator. + void resetCache() { + if (MapIterator.valid()) { + OffsetIntoMapIterator = 0; + CachedStart = MapIterator.start(); + CachedStop = MapIterator.stop(); + } else { + setToEnd(); + } + } + + /// Advance the iterator to \p Index, if it is contained within the current + /// interval. The public-facing method which supports advancing past the + /// current interval is \ref advanceToLowerBound. + void advanceTo(IndexT Index) { + assert(Index <= CachedStop && "Cannot advance to OOB index"); + if (Index < CachedStart) + // We're already past this index. + return; + OffsetIntoMapIterator = Index - CachedStart; + } + + const_iterator(UnderlyingIterator MapIt) : MapIterator(MapIt) { + resetCache(); + } + + public: + const_iterator() { setToEnd(); } + + bool operator==(const const_iterator &RHS) const { + // Do /not/ compare MapIterator for equality, as this is very expensive. + // The cached start/stop values make that check unnecessary. + return std::tie(OffsetIntoMapIterator, CachedStart, CachedStop) == + std::tie(RHS.OffsetIntoMapIterator, RHS.CachedStart, + RHS.CachedStop); + } + + bool operator!=(const const_iterator &RHS) const { + return !operator==(RHS); + } + + IndexT operator*() const { return CachedStart + OffsetIntoMapIterator; } + + const_iterator &operator++() { // Pre-increment (++It). + if (CachedStart + OffsetIntoMapIterator < CachedStop) { + // Keep going within the current interval. + ++OffsetIntoMapIterator; + } else { + // We reached the end of the current interval: advance. + ++MapIterator; + resetCache(); + } + return *this; + } + + const_iterator operator++(int) { // Post-increment (It++). + const_iterator tmp = *this; + operator++(); + return tmp; + } + + /// Advance the iterator to the first set bit AT, OR AFTER, \p Index. If + /// no such set bit exists, advance to end(). This is like std::lower_bound. + /// This is useful if \p Index is close to the current iterator position. + /// However, unlike \ref find(), this has worst-case O(n) performance. + void advanceToLowerBound(IndexT Index) { + if (OffsetIntoMapIterator == kIteratorAtTheEndOffset) + return; + + // Advance to the first interval containing (or past) Index, or to end(). + while (Index > CachedStop) { + ++MapIterator; + resetCache(); + if (OffsetIntoMapIterator == kIteratorAtTheEndOffset) + return; + } + + advanceTo(Index); + } + }; + + const_iterator begin() const { return const_iterator(Intervals.begin()); } + + const_iterator end() const { return const_iterator(); } + + /// Return an iterator pointing to the first set bit AT, OR AFTER, \p Index. + /// If no such set bit exists, return end(). This is like std::lower_bound. + /// This has worst-case logarithmic performance (roughly O(log(gaps between + /// contiguous ranges))). + const_iterator find(IndexT Index) const { + auto UnderlyingIt = Intervals.find(Index); + if (UnderlyingIt == Intervals.end()) + return end(); + auto It = const_iterator(UnderlyingIt); + It.advanceTo(Index); + return It; + } + + /// Return a range iterator which iterates over all of the set bits in the + /// half-open range [Start, End). + iterator_range half_open_range(IndexT Start, + IndexT End) const { + assert(Start < End && "Not a valid range"); + auto StartIt = find(Start); + if (StartIt == end() || *StartIt >= End) + return {end(), end()}; + auto EndIt = StartIt; + EndIt.advanceToLowerBound(End); + return {StartIt, EndIt}; + } + + void print(raw_ostream &OS) const { + OS << "{"; + for (auto It = Intervals.begin(), End = Intervals.end(); It != End; + ++It) { + OS << "[" << It.start(); + if (It.start() != It.stop()) + OS << ", " << It.stop(); + OS << "]"; + } + OS << "}"; + } + +#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) + LLVM_DUMP_METHOD void dump() const { + // LLDB swallows the first line of output after callling dump(). Add + // newlines before/after the braces to work around this. + dbgs() << "\n"; + print(dbgs()); + dbgs() << "\n"; + } +#endif + +private: + void insert(IndexT Start, IndexT End) { Intervals.insert(Start, End, 0); } + + /// Record the overlaps between \p this and \p Other in \p Overlaps. Return + /// true if there is any overlap. + bool getOverlaps(const ThisT &Other, + SmallVectorImpl &Overlaps) const { + for (IntervalMapOverlaps I(Intervals, Other.Intervals); + I.valid(); ++I) + Overlaps.emplace_back(I.start(), I.stop()); + assert(llvm::is_sorted(Overlaps, + [](IntervalT LHS, IntervalT RHS) { + return LHS.second < RHS.first; + }) && + "Overlaps must be sorted"); + return !Overlaps.empty(); + } + + /// Given the set of overlaps between this and some other bitvector, and an + /// interval [Start, Stop] from that bitvector, determine the portions of the + /// interval which do not overlap with this. + void getNonOverlappingParts(IndexT Start, IndexT Stop, + const SmallVectorImpl &Overlaps, + SmallVectorImpl &NonOverlappingParts) { + IndexT NextUncoveredBit = Start; + for (IntervalT Overlap : Overlaps) { + IndexT OlapStart, OlapStop; + std::tie(OlapStart, OlapStop) = Overlap; + + // [Start;Stop] and [OlapStart;OlapStop] overlap iff OlapStart <= Stop + // and Start <= OlapStop. + bool DoesOverlap = OlapStart <= Stop && Start <= OlapStop; + if (!DoesOverlap) + continue; + + // Cover the range [NextUncoveredBit, OlapStart). This puts the start of + // the next uncovered range at OlapStop+1. + if (NextUncoveredBit < OlapStart) + NonOverlappingParts.emplace_back(NextUncoveredBit, OlapStart - 1); + NextUncoveredBit = OlapStop + 1; + if (NextUncoveredBit > Stop) + break; + } + if (NextUncoveredBit <= Stop) + NonOverlappingParts.emplace_back(NextUncoveredBit, Stop); + } + + Allocator *Alloc; + MapT Intervals; +}; + +} // namespace llvm + +#endif // LLVM_ADT_COALESCINGBITVECTOR_H diff --git a/gnu/llvm/llvm/include/llvm/ADT/DAGDeltaAlgorithm.h b/gnu/llvm/llvm/include/llvm/ADT/DAGDeltaAlgorithm.h index d4cdc3c8604..c3872af2a0b 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/DAGDeltaAlgorithm.h +++ b/gnu/llvm/llvm/include/llvm/ADT/DAGDeltaAlgorithm.h @@ -29,7 +29,7 @@ namespace llvm { /// /// P(S) => P(S union pred(S)) /// -/// The minization algorithm uses this dependency information to attempt to +/// The minimization algorithm uses this dependency information to attempt to /// eagerly prune large subsets of changes. As with \see DeltaAlgorithm, the DAG /// is not required to satisfy this property, but the algorithm will run /// substantially fewer tests with appropriate dependencies. \see DeltaAlgorithm diff --git a/gnu/llvm/llvm/include/llvm/ADT/DeltaAlgorithm.h b/gnu/llvm/llvm/include/llvm/ADT/DeltaAlgorithm.h index 114b9549953..e1743fd0019 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/DeltaAlgorithm.h +++ b/gnu/llvm/llvm/include/llvm/ADT/DeltaAlgorithm.h @@ -54,7 +54,7 @@ private: /// Split - Partition a set of changes \p S into one or two subsets. void Split(const changeset_ty &S, changesetlist_ty &Res); - /// Delta - Minimize a set of \p Changes which has been partioned into + /// Delta - Minimize a set of \p Changes which has been partitioned into /// smaller sets, by attempting to remove individual subsets. changeset_ty Delta(const changeset_ty &Changes, const changesetlist_ty &Sets); diff --git a/gnu/llvm/llvm/include/llvm/ADT/DenseMap.h b/gnu/llvm/llvm/include/llvm/ADT/DenseMap.h index 148d319c860..34d397cc979 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/DenseMap.h +++ b/gnu/llvm/llvm/include/llvm/ADT/DenseMap.h @@ -18,6 +18,7 @@ #include "llvm/Support/AlignOf.h" #include "llvm/Support/Compiler.h" #include "llvm/Support/MathExtras.h" +#include "llvm/Support/MemAlloc.h" #include "llvm/Support/ReverseIteration.h" #include "llvm/Support/type_traits.h" #include @@ -119,9 +120,8 @@ public: } const KeyT EmptyKey = getEmptyKey(), TombstoneKey = getTombstoneKey(); - if (is_trivially_copyable::value && - is_trivially_copyable::value) { - // Use a simpler loop when these are trivial types. + if (std::is_trivially_destructible::value) { + // Use a simpler loop when values don't need destruction. for (BucketT *P = getBuckets(), *E = getBucketsEnd(); P != E; ++P) P->getFirst() = EmptyKey; } else { @@ -150,13 +150,19 @@ public: iterator find(const_arg_type_t Val) { BucketT *TheBucket; if (LookupBucketFor(Val, TheBucket)) - return makeIterator(TheBucket, getBucketsEnd(), *this, true); + return makeIterator(TheBucket, + shouldReverseIterate() ? getBuckets() + : getBucketsEnd(), + *this, true); return end(); } const_iterator find(const_arg_type_t Val) const { const BucketT *TheBucket; if (LookupBucketFor(Val, TheBucket)) - return makeConstIterator(TheBucket, getBucketsEnd(), *this, true); + return makeConstIterator(TheBucket, + shouldReverseIterate() ? getBuckets() + : getBucketsEnd(), + *this, true); return end(); } @@ -169,14 +175,20 @@ public: iterator find_as(const LookupKeyT &Val) { BucketT *TheBucket; if (LookupBucketFor(Val, TheBucket)) - return makeIterator(TheBucket, getBucketsEnd(), *this, true); + return makeIterator(TheBucket, + shouldReverseIterate() ? getBuckets() + : getBucketsEnd(), + *this, true); return end(); } template const_iterator find_as(const LookupKeyT &Val) const { const BucketT *TheBucket; if (LookupBucketFor(Val, TheBucket)) - return makeConstIterator(TheBucket, getBucketsEnd(), *this, true); + return makeConstIterator(TheBucket, + shouldReverseIterate() ? getBuckets() + : getBucketsEnd(), + *this, true); return end(); } @@ -210,16 +222,22 @@ public: std::pair try_emplace(KeyT &&Key, Ts &&... Args) { BucketT *TheBucket; if (LookupBucketFor(Key, TheBucket)) - return std::make_pair( - makeIterator(TheBucket, getBucketsEnd(), *this, true), - false); // Already in map. + return std::make_pair(makeIterator(TheBucket, + shouldReverseIterate() + ? getBuckets() + : getBucketsEnd(), + *this, true), + false); // Already in map. // Otherwise, insert the new element. TheBucket = InsertIntoBucket(TheBucket, std::move(Key), std::forward(Args)...); - return std::make_pair( - makeIterator(TheBucket, getBucketsEnd(), *this, true), - true); + return std::make_pair(makeIterator(TheBucket, + shouldReverseIterate() + ? getBuckets() + : getBucketsEnd(), + *this, true), + true); } // Inserts key,value pair into the map if the key isn't already in the map. @@ -229,15 +247,21 @@ public: std::pair try_emplace(const KeyT &Key, Ts &&... Args) { BucketT *TheBucket; if (LookupBucketFor(Key, TheBucket)) - return std::make_pair( - makeIterator(TheBucket, getBucketsEnd(), *this, true), - false); // Already in map. + return std::make_pair(makeIterator(TheBucket, + shouldReverseIterate() + ? getBuckets() + : getBucketsEnd(), + *this, true), + false); // Already in map. // Otherwise, insert the new element. TheBucket = InsertIntoBucket(TheBucket, Key, std::forward(Args)...); - return std::make_pair( - makeIterator(TheBucket, getBucketsEnd(), *this, true), - true); + return std::make_pair(makeIterator(TheBucket, + shouldReverseIterate() + ? getBuckets() + : getBucketsEnd(), + *this, true), + true); } /// Alternate version of insert() which allows a different, and possibly @@ -250,16 +274,22 @@ public: const LookupKeyT &Val) { BucketT *TheBucket; if (LookupBucketFor(Val, TheBucket)) - return std::make_pair( - makeIterator(TheBucket, getBucketsEnd(), *this, true), - false); // Already in map. + return std::make_pair(makeIterator(TheBucket, + shouldReverseIterate() + ? getBuckets() + : getBucketsEnd(), + *this, true), + false); // Already in map. // Otherwise, insert the new element. TheBucket = InsertIntoBucketWithLookup(TheBucket, std::move(KV.first), std::move(KV.second), Val); - return std::make_pair( - makeIterator(TheBucket, getBucketsEnd(), *this, true), - true); + return std::make_pair(makeIterator(TheBucket, + shouldReverseIterate() + ? getBuckets() + : getBucketsEnd(), + *this, true), + true); } /// insert - Range insertion of pairs. @@ -695,7 +725,7 @@ class DenseMap : public DenseMapBase, unsigned NumBuckets; public: - /// Create a DenseMap wth an optional \p InitialReserve that guarantee that + /// Create a DenseMap with an optional \p InitialReserve that guarantee that /// this number of elements can be inserted in the map without grow() explicit DenseMap(unsigned InitialReserve = 0) { init(InitialReserve); } @@ -1194,19 +1224,21 @@ public: // for const iterator destinations so it doesn't end up as a user defined copy // constructor. template ::type> + typename = std::enable_if_t> DenseMapIterator( const DenseMapIterator &I) : DebugEpochBase::HandleBase(I), Ptr(I.Ptr), End(I.End) {} reference operator*() const { assert(isHandleInSync() && "invalid iterator access!"); + assert(Ptr != End && "dereferencing end() iterator"); if (shouldReverseIterate()) return Ptr[-1]; return *Ptr; } pointer operator->() const { assert(isHandleInSync() && "invalid iterator access!"); + assert(Ptr != End && "dereferencing end() iterator"); if (shouldReverseIterate()) return &(Ptr[-1]); return Ptr; @@ -1229,6 +1261,7 @@ public: inline DenseMapIterator& operator++() { // Preincrement assert(isHandleInSync() && "invalid iterator access!"); + assert(Ptr != End && "incrementing end() iterator"); if (shouldReverseIterate()) { --Ptr; RetreatPastEmptyBuckets(); diff --git a/gnu/llvm/llvm/include/llvm/ADT/DenseMapInfo.h b/gnu/llvm/llvm/include/llvm/ADT/DenseMapInfo.h index bd4c60c8f13..e465331ac6f 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/DenseMapInfo.h +++ b/gnu/llvm/llvm/include/llvm/ADT/DenseMapInfo.h @@ -16,8 +16,6 @@ #include "llvm/ADT/ArrayRef.h" #include "llvm/ADT/Hashing.h" #include "llvm/ADT/StringRef.h" -#include "llvm/Support/PointerLikeTypeTraits.h" -#include "llvm/Support/TypeSize.h" #include #include #include @@ -25,6 +23,24 @@ namespace llvm { +namespace detail { + +/// Simplistic combination of 32-bit hash values into 32-bit hash values. +static inline unsigned combineHashValue(unsigned a, unsigned b) { + uint64_t key = (uint64_t)a << 32 | (uint64_t)b; + key += ~(key << 32); + key ^= (key >> 22); + key += ~(key << 13); + key ^= (key >> 8); + key += (key << 3); + key ^= (key >> 15); + key += ~(key << 27); + key ^= (key >> 31); + return (unsigned)key; +} + +} // end namespace detail + template struct DenseMapInfo { //static inline T getEmptyKey(); @@ -33,18 +49,28 @@ struct DenseMapInfo { //static bool isEqual(const T &LHS, const T &RHS); }; -// Provide DenseMapInfo for all pointers. +// Provide DenseMapInfo for all pointers. Come up with sentinel pointer values +// that are aligned to alignof(T) bytes, but try to avoid requiring T to be +// complete. This allows clients to instantiate DenseMap with forward +// declared key types. Assume that no pointer key type requires more than 4096 +// bytes of alignment. template struct DenseMapInfo { + // The following should hold, but it would require T to be complete: + // static_assert(alignof(T) <= (1 << Log2MaxAlign), + // "DenseMap does not support pointer keys requiring more than " + // "Log2MaxAlign bits of alignment"); + static constexpr uintptr_t Log2MaxAlign = 12; + static inline T* getEmptyKey() { uintptr_t Val = static_cast(-1); - Val <<= PointerLikeTypeTraits::NumLowBitsAvailable; + Val <<= Log2MaxAlign; return reinterpret_cast(Val); } static inline T* getTombstoneKey() { uintptr_t Val = static_cast(-2); - Val <<= PointerLikeTypeTraits::NumLowBitsAvailable; + Val <<= Log2MaxAlign; return reinterpret_cast(Val); } @@ -198,17 +224,8 @@ struct DenseMapInfo> { } static unsigned getHashValue(const Pair& PairVal) { - uint64_t key = (uint64_t)FirstInfo::getHashValue(PairVal.first) << 32 - | (uint64_t)SecondInfo::getHashValue(PairVal.second); - key += ~(key << 32); - key ^= (key >> 22); - key += ~(key << 13); - key ^= (key >> 8); - key += (key << 3); - key ^= (key >> 15); - key += ~(key << 27); - key ^= (key >> 31); - return (unsigned)key; + return detail::combineHashValue(FirstInfo::getHashValue(PairVal.first), + SecondInfo::getHashValue(PairVal.second)); } static bool isEqual(const Pair &LHS, const Pair &RHS) { @@ -217,6 +234,56 @@ struct DenseMapInfo> { } }; +// Provide DenseMapInfo for all tuples whose members have info. +template struct DenseMapInfo> { + using Tuple = std::tuple; + + static inline Tuple getEmptyKey() { + return Tuple(DenseMapInfo::getEmptyKey()...); + } + + static inline Tuple getTombstoneKey() { + return Tuple(DenseMapInfo::getTombstoneKey()...); + } + + template + static unsigned getHashValueImpl(const Tuple &values, std::false_type) { + using EltType = typename std::tuple_element::type; + std::integral_constant atEnd; + return detail::combineHashValue( + DenseMapInfo::getHashValue(std::get(values)), + getHashValueImpl(values, atEnd)); + } + + template + static unsigned getHashValueImpl(const Tuple &values, std::true_type) { + return 0; + } + + static unsigned getHashValue(const std::tuple &values) { + std::integral_constant atEnd; + return getHashValueImpl<0>(values, atEnd); + } + + template + static bool isEqualImpl(const Tuple &lhs, const Tuple &rhs, std::false_type) { + using EltType = typename std::tuple_element::type; + std::integral_constant atEnd; + return DenseMapInfo::isEqual(std::get(lhs), std::get(rhs)) && + isEqualImpl(lhs, rhs, atEnd); + } + + template + static bool isEqualImpl(const Tuple &lhs, const Tuple &rhs, std::true_type) { + return true; + } + + static bool isEqual(const Tuple &lhs, const Tuple &rhs) { + std::integral_constant atEnd; + return isEqualImpl<0>(lhs, rhs, atEnd); + } +}; + // Provide DenseMapInfo for StringRefs. template <> struct DenseMapInfo { static inline StringRef getEmptyKey() { @@ -280,21 +347,6 @@ template <> struct DenseMapInfo { static bool isEqual(hash_code LHS, hash_code RHS) { return LHS == RHS; } }; -template <> struct DenseMapInfo { - static inline ElementCount getEmptyKey() { return {~0U, true}; } - static inline ElementCount getTombstoneKey() { return {~0U - 1, false}; } - static unsigned getHashValue(const ElementCount& EltCnt) { - if (EltCnt.Scalable) - return (EltCnt.Min * 37U) - 1U; - - return EltCnt.Min * 37U; - } - - static bool isEqual(const ElementCount& LHS, const ElementCount& RHS) { - return LHS == RHS; - } -}; - } // end namespace llvm #endif // LLVM_ADT_DENSEMAPINFO_H diff --git a/gnu/llvm/llvm/include/llvm/ADT/DenseSet.h b/gnu/llvm/llvm/include/llvm/ADT/DenseSet.h index 9afb715ae1d..07edc3d8e4e 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/DenseSet.h +++ b/gnu/llvm/llvm/include/llvm/ADT/DenseSet.h @@ -66,6 +66,12 @@ public: explicit DenseSetImpl(unsigned InitialReserve = 0) : TheMap(InitialReserve) {} + template + DenseSetImpl(const InputIt &I, const InputIt &E) + : DenseSetImpl(PowerOf2Ceil(std::distance(I, E))) { + insert(I, E); + } + DenseSetImpl(std::initializer_list Elems) : DenseSetImpl(PowerOf2Ceil(Elems.size())) { insert(Elems.begin(), Elems.end()); diff --git a/gnu/llvm/llvm/include/llvm/ADT/EnumeratedArray.h b/gnu/llvm/llvm/include/llvm/ADT/EnumeratedArray.h index a9528115618..a66ec9d08c3 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/EnumeratedArray.h +++ b/gnu/llvm/llvm/include/llvm/ADT/EnumeratedArray.h @@ -38,6 +38,7 @@ public: static_cast &>(*this)[Index]); } + inline IndexType size() { return Size; } private: ValueType Underlying[Size]; diff --git a/gnu/llvm/llvm/include/llvm/ADT/FloatingPointMode.h b/gnu/llvm/llvm/include/llvm/ADT/FloatingPointMode.h index 670b2368da9..3ba8ae1b285 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/FloatingPointMode.h +++ b/gnu/llvm/llvm/include/llvm/ADT/FloatingPointMode.h @@ -14,28 +14,123 @@ #define LLVM_FLOATINGPOINTMODE_H #include "llvm/ADT/StringSwitch.h" +#include "llvm/Support/raw_ostream.h" namespace llvm { -/// Represent handled modes for denormal (aka subnormal) modes in the floating -/// point environment. -enum class DenormalMode { - Invalid = -1, +/// Rounding mode. +/// +/// Enumerates supported rounding modes, as well as some special values. The set +/// of the modes must agree with IEEE-754, 4.3.1 and 4.3.2. The constants +/// assigned to the IEEE rounding modes must agree with the values used by +/// FLT_ROUNDS (C11, 5.2.4.2.2p8). +/// +/// This value is packed into bitfield in some cases, including \c FPOptions, so +/// the rounding mode values and the special value \c Dynamic must fit into the +/// the bit field (now - 3 bits). The value \c Invalid is used only in values +/// returned by intrinsics to indicate errors, it should never be stored as +/// rounding mode value, so it does not need to fit the bit fields. +/// +enum class RoundingMode : int8_t { + // Rounding mode defined in IEEE-754. + TowardZero = 0, ///< roundTowardZero. + NearestTiesToEven = 1, ///< roundTiesToEven. + TowardPositive = 2, ///< roundTowardPositive. + TowardNegative = 3, ///< roundTowardNegative. + NearestTiesToAway = 4, ///< roundTiesToAway. - /// IEEE-754 denormal numbers preserved. - IEEE, + // Special values. + Dynamic = 7, ///< Denotes mode unknown at compile time. + Invalid = -1 ///< Denotes invalid value. +}; + +/// Represent subnormal handling kind for floating point instruction inputs and +/// outputs. +struct DenormalMode { + /// Represent handled modes for denormal (aka subnormal) modes in the floating + /// point environment. + enum DenormalModeKind : int8_t { + Invalid = -1, + + /// IEEE-754 denormal numbers preserved. + IEEE, + + /// The sign of a flushed-to-zero number is preserved in the sign of 0 + PreserveSign, + + /// Denormals are flushed to positive zero. + PositiveZero + }; - /// The sign of a flushed-to-zero number is preserved in the sign of 0 - PreserveSign, + /// Denormal flushing mode for floating point instruction results in the + /// default floating point environment. + DenormalModeKind Output = DenormalModeKind::Invalid; + + /// Denormal treatment kind for floating point instruction inputs in the + /// default floating-point environment. If this is not DenormalModeKind::IEEE, + /// floating-point instructions implicitly treat the input value as 0. + DenormalModeKind Input = DenormalModeKind::Invalid; + + constexpr DenormalMode() = default; + constexpr DenormalMode(DenormalModeKind Out, DenormalModeKind In) : + Output(Out), Input(In) {} + + + static constexpr DenormalMode getInvalid() { + return DenormalMode(DenormalModeKind::Invalid, DenormalModeKind::Invalid); + } - /// Denormals are flushed to positive zero. - PositiveZero + static constexpr DenormalMode getIEEE() { + return DenormalMode(DenormalModeKind::IEEE, DenormalModeKind::IEEE); + } + + static constexpr DenormalMode getPreserveSign() { + return DenormalMode(DenormalModeKind::PreserveSign, + DenormalModeKind::PreserveSign); + } + + static constexpr DenormalMode getPositiveZero() { + return DenormalMode(DenormalModeKind::PositiveZero, + DenormalModeKind::PositiveZero); + } + + bool operator==(DenormalMode Other) const { + return Output == Other.Output && Input == Other.Input; + } + + bool operator!=(DenormalMode Other) const { + return !(*this == Other); + } + + bool isSimple() const { + return Input == Output; + } + + bool isValid() const { + return Output != DenormalModeKind::Invalid && + Input != DenormalModeKind::Invalid; + } + + inline void print(raw_ostream &OS) const; + + inline std::string str() const { + std::string storage; + raw_string_ostream OS(storage); + print(OS); + return OS.str(); + } }; +inline raw_ostream& operator<<(raw_ostream &OS, DenormalMode Mode) { + Mode.print(OS); + return OS; +} + /// Parse the expected names from the denormal-fp-math attribute. -inline DenormalMode parseDenormalFPAttribute(StringRef Str) { +inline DenormalMode::DenormalModeKind +parseDenormalFPAttributeComponent(StringRef Str) { // Assume ieee on unspecified attribute. - return StringSwitch(Str) + return StringSwitch(Str) .Cases("", "ieee", DenormalMode::IEEE) .Case("preserve-sign", DenormalMode::PreserveSign) .Case("positive-zero", DenormalMode::PositiveZero) @@ -44,7 +139,7 @@ inline DenormalMode parseDenormalFPAttribute(StringRef Str) { /// Return the name used for the denormal handling mode used by the the /// expected names from the denormal-fp-math attribute. -inline StringRef denormalModeName(DenormalMode Mode) { +inline StringRef denormalModeKindName(DenormalMode::DenormalModeKind Mode) { switch (Mode) { case DenormalMode::IEEE: return "ieee"; @@ -57,6 +152,26 @@ inline StringRef denormalModeName(DenormalMode Mode) { } } +/// Returns the denormal mode to use for inputs and outputs. +inline DenormalMode parseDenormalFPAttribute(StringRef Str) { + StringRef OutputStr, InputStr; + std::tie(OutputStr, InputStr) = Str.split(','); + + DenormalMode Mode; + Mode.Output = parseDenormalFPAttributeComponent(OutputStr); + + // Maintain compatability with old form of the attribute which only specified + // one component. + Mode.Input = InputStr.empty() ? Mode.Output : + parseDenormalFPAttributeComponent(InputStr); + + return Mode; +} + +void DenormalMode::print(raw_ostream &OS) const { + OS << denormalModeKindName(Output) << ',' << denormalModeKindName(Input); +} + } #endif // LLVM_FLOATINGPOINTMODE_H diff --git a/gnu/llvm/llvm/include/llvm/ADT/FoldingSet.h b/gnu/llvm/llvm/include/llvm/ADT/FoldingSet.h index 4968b1ea778..fb1cb03a4b5 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/FoldingSet.h +++ b/gnu/llvm/llvm/include/llvm/ADT/FoldingSet.h @@ -110,8 +110,6 @@ class StringRef; /// back to the bucket to facilitate node removal. /// class FoldingSetBase { - virtual void anchor(); // Out of line virtual method. - protected: /// Buckets - Array of bucket chains. void **Buckets; @@ -154,11 +152,6 @@ public: /// empty - Returns true if there are no nodes in the folding set. bool empty() const { return NumNodes == 0; } - /// reserve - Increase the number of buckets such that adding the - /// EltCount-th node won't cause a rebucket operation. reserve is permitted - /// to allocate more space than requested by EltCount. - void reserve(unsigned EltCount); - /// capacity - Returns the number of nodes permitted in the folding set /// before a rebucket operation is performed. unsigned capacity() { @@ -167,32 +160,46 @@ public: return NumBuckets * 2; } +protected: + /// Functions provided by the derived class to compute folding properties. + /// This is effectively a vtable for FoldingSetBase, except that we don't + /// actually store a pointer to it in the object. + struct FoldingSetInfo { + /// GetNodeProfile - Instantiations of the FoldingSet template implement + /// this function to gather data bits for the given node. + void (*GetNodeProfile)(const FoldingSetBase *Self, Node *N, + FoldingSetNodeID &ID); + + /// NodeEquals - Instantiations of the FoldingSet template implement + /// this function to compare the given node with the given ID. + bool (*NodeEquals)(const FoldingSetBase *Self, Node *N, + const FoldingSetNodeID &ID, unsigned IDHash, + FoldingSetNodeID &TempID); + + /// ComputeNodeHash - Instantiations of the FoldingSet template implement + /// this function to compute a hash value for the given node. + unsigned (*ComputeNodeHash)(const FoldingSetBase *Self, Node *N, + FoldingSetNodeID &TempID); + }; + private: /// GrowHashTable - Double the size of the hash table and rehash everything. - void GrowHashTable(); + void GrowHashTable(const FoldingSetInfo &Info); /// GrowBucketCount - resize the hash table and rehash everything. /// NewBucketCount must be a power of two, and must be greater than the old /// bucket count. - void GrowBucketCount(unsigned NewBucketCount); + void GrowBucketCount(unsigned NewBucketCount, const FoldingSetInfo &Info); protected: - /// GetNodeProfile - Instantiations of the FoldingSet template implement - /// this function to gather data bits for the given node. - virtual void GetNodeProfile(Node *N, FoldingSetNodeID &ID) const = 0; - - /// NodeEquals - Instantiations of the FoldingSet template implement - /// this function to compare the given node with the given ID. - virtual bool NodeEquals(Node *N, const FoldingSetNodeID &ID, unsigned IDHash, - FoldingSetNodeID &TempID) const=0; - - /// ComputeNodeHash - Instantiations of the FoldingSet template implement - /// this function to compute a hash value for the given node. - virtual unsigned ComputeNodeHash(Node *N, FoldingSetNodeID &TempID) const = 0; - // The below methods are protected to encourage subclasses to provide a more // type-safe API. + /// reserve - Increase the number of buckets such that adding the + /// EltCount-th node won't cause a rebucket operation. reserve is permitted + /// to allocate more space than requested by EltCount. + void reserve(unsigned EltCount, const FoldingSetInfo &Info); + /// RemoveNode - Remove a node from the folding set, returning true if one /// was removed or false if the node was not in the folding set. bool RemoveNode(Node *N); @@ -200,17 +207,18 @@ protected: /// GetOrInsertNode - If there is an existing simple Node exactly /// equal to the specified node, return it. Otherwise, insert 'N' and return /// it instead. - Node *GetOrInsertNode(Node *N); + Node *GetOrInsertNode(Node *N, const FoldingSetInfo &Info); /// FindNodeOrInsertPos - Look up the node specified by ID. If it exists, /// return it. If not, return the insertion token that will make insertion /// faster. - Node *FindNodeOrInsertPos(const FoldingSetNodeID &ID, void *&InsertPos); + Node *FindNodeOrInsertPos(const FoldingSetNodeID &ID, void *&InsertPos, + const FoldingSetInfo &Info); /// InsertNode - Insert the specified node into the folding set, knowing that /// it is not already in the folding set. InsertPos must be obtained from /// FindNodeOrInsertPos. - void InsertNode(Node *N, void *InsertPos); + void InsertNode(Node *N, void *InsertPos, const FoldingSetInfo &Info); }; //===----------------------------------------------------------------------===// @@ -397,7 +405,7 @@ DefaultContextualFoldingSetTrait::ComputeHash(T &X, //===----------------------------------------------------------------------===// /// FoldingSetImpl - An implementation detail that lets us share code between /// FoldingSet and ContextualFoldingSet. -template class FoldingSetImpl : public FoldingSetBase { +template class FoldingSetImpl : public FoldingSetBase { protected: explicit FoldingSetImpl(unsigned Log2InitSize) : FoldingSetBase(Log2InitSize) {} @@ -427,29 +435,40 @@ public: return bucket_iterator(Buckets + (hash & (NumBuckets-1)), true); } + /// reserve - Increase the number of buckets such that adding the + /// EltCount-th node won't cause a rebucket operation. reserve is permitted + /// to allocate more space than requested by EltCount. + void reserve(unsigned EltCount) { + return FoldingSetBase::reserve(EltCount, Derived::getFoldingSetInfo()); + } + /// RemoveNode - Remove a node from the folding set, returning true if one /// was removed or false if the node was not in the folding set. - bool RemoveNode(T *N) { return FoldingSetBase::RemoveNode(N); } + bool RemoveNode(T *N) { + return FoldingSetBase::RemoveNode(N); + } /// GetOrInsertNode - If there is an existing simple Node exactly /// equal to the specified node, return it. Otherwise, insert 'N' and /// return it instead. T *GetOrInsertNode(T *N) { - return static_cast(FoldingSetBase::GetOrInsertNode(N)); + return static_cast( + FoldingSetBase::GetOrInsertNode(N, Derived::getFoldingSetInfo())); } /// FindNodeOrInsertPos - Look up the node specified by ID. If it exists, /// return it. If not, return the insertion token that will make insertion /// faster. T *FindNodeOrInsertPos(const FoldingSetNodeID &ID, void *&InsertPos) { - return static_cast(FoldingSetBase::FindNodeOrInsertPos(ID, InsertPos)); + return static_cast(FoldingSetBase::FindNodeOrInsertPos( + ID, InsertPos, Derived::getFoldingSetInfo())); } /// InsertNode - Insert the specified node into the folding set, knowing that /// it is not already in the folding set. InsertPos must be obtained from /// FindNodeOrInsertPos. void InsertNode(T *N, void *InsertPos) { - FoldingSetBase::InsertNode(N, InsertPos); + FoldingSetBase::InsertNode(N, InsertPos, Derived::getFoldingSetInfo()); } /// InsertNode - Insert the specified node into the folding set, knowing that @@ -470,32 +489,43 @@ public: /// moved-from state is not a valid state for anything other than /// move-assigning and destroying. This is primarily to enable movable APIs /// that incorporate these objects. -template class FoldingSet final : public FoldingSetImpl { - using Super = FoldingSetImpl; +template +class FoldingSet : public FoldingSetImpl, T> { + using Super = FoldingSetImpl; using Node = typename Super::Node; - /// GetNodeProfile - Each instantiatation of the FoldingSet needs to provide a + /// GetNodeProfile - Each instantiation of the FoldingSet needs to provide a /// way to convert nodes into a unique specifier. - void GetNodeProfile(Node *N, FoldingSetNodeID &ID) const override { + static void GetNodeProfile(const FoldingSetBase *, Node *N, + FoldingSetNodeID &ID) { T *TN = static_cast(N); FoldingSetTrait::Profile(*TN, ID); } /// NodeEquals - Instantiations may optionally provide a way to compare a /// node with a specified ID. - bool NodeEquals(Node *N, const FoldingSetNodeID &ID, unsigned IDHash, - FoldingSetNodeID &TempID) const override { + static bool NodeEquals(const FoldingSetBase *, Node *N, + const FoldingSetNodeID &ID, unsigned IDHash, + FoldingSetNodeID &TempID) { T *TN = static_cast(N); return FoldingSetTrait::Equals(*TN, ID, IDHash, TempID); } /// ComputeNodeHash - Instantiations may optionally provide a way to compute a /// hash value directly from a node. - unsigned ComputeNodeHash(Node *N, FoldingSetNodeID &TempID) const override { + static unsigned ComputeNodeHash(const FoldingSetBase *, Node *N, + FoldingSetNodeID &TempID) { T *TN = static_cast(N); return FoldingSetTrait::ComputeHash(*TN, TempID); } + static const FoldingSetBase::FoldingSetInfo &getFoldingSetInfo() { + static constexpr FoldingSetBase::FoldingSetInfo Info = { + GetNodeProfile, NodeEquals, ComputeNodeHash}; + return Info; + } + friend Super; + public: explicit FoldingSet(unsigned Log2InitSize = 6) : Super(Log2InitSize) {} FoldingSet(FoldingSet &&Arg) = default; @@ -512,35 +542,51 @@ public: /// function with signature /// void Profile(FoldingSetNodeID &, Ctx); template -class ContextualFoldingSet final : public FoldingSetImpl { +class ContextualFoldingSet + : public FoldingSetImpl, T> { // Unfortunately, this can't derive from FoldingSet because the // construction of the vtable for FoldingSet requires // FoldingSet::GetNodeProfile to be instantiated, which in turn // requires a single-argument T::Profile(). - using Super = FoldingSetImpl; + using Super = FoldingSetImpl; using Node = typename Super::Node; Ctx Context; + static const Ctx &getContext(const FoldingSetBase *Base) { + return static_cast(Base)->Context; + } + /// GetNodeProfile - Each instantiatation of the FoldingSet needs to provide a /// way to convert nodes into a unique specifier. - void GetNodeProfile(Node *N, FoldingSetNodeID &ID) const override { + static void GetNodeProfile(const FoldingSetBase *Base, Node *N, + FoldingSetNodeID &ID) { T *TN = static_cast(N); - ContextualFoldingSetTrait::Profile(*TN, ID, Context); + ContextualFoldingSetTrait::Profile(*TN, ID, getContext(Base)); } - bool NodeEquals(Node *N, const FoldingSetNodeID &ID, unsigned IDHash, - FoldingSetNodeID &TempID) const override { + static bool NodeEquals(const FoldingSetBase *Base, Node *N, + const FoldingSetNodeID &ID, unsigned IDHash, + FoldingSetNodeID &TempID) { T *TN = static_cast(N); return ContextualFoldingSetTrait::Equals(*TN, ID, IDHash, TempID, - Context); + getContext(Base)); } - unsigned ComputeNodeHash(Node *N, FoldingSetNodeID &TempID) const override { + static unsigned ComputeNodeHash(const FoldingSetBase *Base, Node *N, + FoldingSetNodeID &TempID) { T *TN = static_cast(N); - return ContextualFoldingSetTrait::ComputeHash(*TN, TempID, Context); + return ContextualFoldingSetTrait::ComputeHash(*TN, TempID, + getContext(Base)); + } + + static const FoldingSetBase::FoldingSetInfo &getFoldingSetInfo() { + static constexpr FoldingSetBase::FoldingSetInfo Info = { + GetNodeProfile, NodeEquals, ComputeNodeHash}; + return Info; } + friend Super; public: explicit ContextualFoldingSet(Ctx Context, unsigned Log2InitSize = 6) diff --git a/gnu/llvm/llvm/include/llvm/ADT/FunctionExtras.h b/gnu/llvm/llvm/include/llvm/ADT/FunctionExtras.h index 121aa527a5d..4c75e4d2547 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/FunctionExtras.h +++ b/gnu/llvm/llvm/include/llvm/ADT/FunctionExtras.h @@ -11,11 +11,11 @@ /// in ``. /// /// It provides `unique_function`, which works like `std::function` but supports -/// move-only callable objects. +/// move-only callable objects and const-qualification. /// /// Future plans: -/// - Add a `function` that provides const, volatile, and ref-qualified support, -/// which doesn't work with `std::function`. +/// - Add a `function` that provides ref-qualified support, which doesn't work +/// with `std::function`. /// - Provide support for specifying multiple signatures to type erase callable /// objects with an overload set, such as those produced by generic lambdas. /// - Expand to include a copyable utility that directly replaces std::function @@ -34,15 +34,34 @@ #include "llvm/ADT/PointerIntPair.h" #include "llvm/ADT/PointerUnion.h" +#include "llvm/Support/MemAlloc.h" #include "llvm/Support/type_traits.h" #include +#include namespace llvm { +/// unique_function is a type-erasing functor similar to std::function. +/// +/// It can hold move-only function objects, like lambdas capturing unique_ptrs. +/// Accordingly, it is movable but not copyable. +/// +/// It supports const-qualification: +/// - unique_function has a const operator(). +/// It can only hold functions which themselves have a const operator(). +/// - unique_function has a non-const operator(). +/// It can hold functions with a non-const operator(), like mutable lambdas. template class unique_function; -template -class unique_function { +namespace detail { + +template +using EnableIfTrivial = + std::enable_if_t::value && + std::is_trivially_destructible::value>; + +template class UniqueFunctionBase { +protected: static constexpr size_t InlineStorageSize = sizeof(void *) * 3; // MSVC has a bug and ICEs if we give it a particular dependent value @@ -112,8 +131,11 @@ class unique_function { // For in-line storage, we just provide an aligned character buffer. We // provide three pointers worth of storage here. - typename std::aligned_storage::type - InlineStorage; + // This is mutable as an inlined `const unique_function` may + // still modify its own mutable members. + mutable + typename std::aligned_storage::type + InlineStorage; } StorageUnion; // A compressed pointer to either our dispatching callback or our table of @@ -136,11 +158,25 @@ class unique_function { .template get(); } - void *getInlineStorage() { return &StorageUnion.InlineStorage; } + CallPtrT getCallPtr() const { + return isTrivialCallback() ? getTrivialCallback() + : getNonTrivialCallbacks()->CallPtr; + } - void *getOutOfLineStorage() { + // These three functions are only const in the narrow sense. They return + // mutable pointers to function state. + // This allows unique_function::operator() to be const, even if the + // underlying functor may be internally mutable. + // + // const callers must ensure they're only used in const-correct ways. + void *getCalleePtr() const { + return isInlineStorage() ? getInlineStorage() : getOutOfLineStorage(); + } + void *getInlineStorage() const { return &StorageUnion.InlineStorage; } + void *getOutOfLineStorage() const { return StorageUnion.OutOfLineStorage.StoragePtr; } + size_t getOutOfLineStorageSize() const { return StorageUnion.OutOfLineStorage.Size; } @@ -152,10 +188,11 @@ class unique_function { StorageUnion.OutOfLineStorage = {Ptr, Size, Alignment}; } - template - static ReturnT CallImpl(void *CallableAddr, AdjustedParamT... Params) { - return (*reinterpret_cast(CallableAddr))( - std::forward(Params)...); + template + static ReturnT CallImpl(void *CallableAddr, + AdjustedParamT... Params) { + auto &Func = *reinterpret_cast(CallableAddr); + return Func(std::forward(Params)...); } template @@ -169,11 +206,54 @@ class unique_function { reinterpret_cast(CallableAddr)->~CallableT(); } -public: - unique_function() = default; - unique_function(std::nullptr_t /*null_callable*/) {} + // The pointers to call/move/destroy functions are determined for each + // callable type (and called-as type, which determines the overload chosen). + // (definitions are out-of-line). + + // By default, we need an object that contains all the different + // type erased behaviors needed. Create a static instance of the struct type + // here and each instance will contain a pointer to it. + // Wrap in a struct to avoid https://gcc.gnu.org/PR71954 + template + struct CallbacksHolder { + static NonTrivialCallbacks Callbacks; + }; + // See if we can create a trivial callback. We need the callable to be + // trivially moved and trivially destroyed so that we don't have to store + // type erased callbacks for those operations. + template + struct CallbacksHolder> { + static TrivialCallback Callbacks; + }; + + // A simple tag type so the call-as type to be passed to the constructor. + template struct CalledAs {}; + + // Essentially the "main" unique_function constructor, but subclasses + // provide the qualified type to be used for the call. + // (We always store a T, even if the call will use a pointer to const T). + template + UniqueFunctionBase(CallableT Callable, CalledAs) { + bool IsInlineStorage = true; + void *CallableAddr = getInlineStorage(); + if (sizeof(CallableT) > InlineStorageSize || + alignof(CallableT) > alignof(decltype(StorageUnion.InlineStorage))) { + IsInlineStorage = false; + // Allocate out-of-line storage. FIXME: Use an explicit alignment + // parameter in C++17 mode. + auto Size = sizeof(CallableT); + auto Alignment = alignof(CallableT); + CallableAddr = allocate_buffer(Size, Alignment); + setOutOfLineStorage(CallableAddr, Size, Alignment); + } + + // Now move into the storage. + new (CallableAddr) CallableT(std::move(Callable)); + CallbackAndInlineFlag.setPointerAndInt( + &CallbacksHolder::Callbacks, IsInlineStorage); + } - ~unique_function() { + ~UniqueFunctionBase() { if (!CallbackAndInlineFlag.getPointer()) return; @@ -189,7 +269,7 @@ public: getOutOfLineStorageAlignment()); } - unique_function(unique_function &&RHS) noexcept { + UniqueFunctionBase(UniqueFunctionBase &&RHS) noexcept { // Copy the callback and inline flag. CallbackAndInlineFlag = RHS.CallbackAndInlineFlag; @@ -218,72 +298,83 @@ public: #endif } - unique_function &operator=(unique_function &&RHS) noexcept { + UniqueFunctionBase &operator=(UniqueFunctionBase &&RHS) noexcept { if (this == &RHS) return *this; // Because we don't try to provide any exception safety guarantees we can // implement move assignment very simply by first destroying the current // object and then move-constructing over top of it. - this->~unique_function(); - new (this) unique_function(std::move(RHS)); + this->~UniqueFunctionBase(); + new (this) UniqueFunctionBase(std::move(RHS)); return *this; } - template unique_function(CallableT Callable) { - bool IsInlineStorage = true; - void *CallableAddr = getInlineStorage(); - if (sizeof(CallableT) > InlineStorageSize || - alignof(CallableT) > alignof(decltype(StorageUnion.InlineStorage))) { - IsInlineStorage = false; - // Allocate out-of-line storage. FIXME: Use an explicit alignment - // parameter in C++17 mode. - auto Size = sizeof(CallableT); - auto Alignment = alignof(CallableT); - CallableAddr = allocate_buffer(Size, Alignment); - setOutOfLineStorage(CallableAddr, Size, Alignment); - } + UniqueFunctionBase() = default; - // Now move into the storage. - new (CallableAddr) CallableT(std::move(Callable)); +public: + explicit operator bool() const { + return (bool)CallbackAndInlineFlag.getPointer(); + } +}; - // See if we can create a trivial callback. We need the callable to be - // trivially moved and trivially destroyed so that we don't have to store - // type erased callbacks for those operations. - // - // FIXME: We should use constexpr if here and below to avoid instantiating - // the non-trivial static objects when unnecessary. While the linker should - // remove them, it is still wasteful. - if (llvm::is_trivially_move_constructible::value && - std::is_trivially_destructible::value) { - // We need to create a nicely aligned object. We use a static variable - // for this because it is a trivial struct. - static TrivialCallback Callback = { &CallImpl }; - - CallbackAndInlineFlag = {&Callback, IsInlineStorage}; - return; - } +template +template +typename UniqueFunctionBase::NonTrivialCallbacks UniqueFunctionBase< + R, P...>::CallbacksHolder::Callbacks = { + &CallImpl, &MoveImpl, &DestroyImpl}; - // Otherwise, we need to point at an object that contains all the different - // type erased behaviors needed. Create a static instance of the struct type - // here and then use a pointer to that. - static NonTrivialCallbacks Callbacks = { - &CallImpl, &MoveImpl, &DestroyImpl}; +template +template +typename UniqueFunctionBase::TrivialCallback + UniqueFunctionBase::CallbacksHolder< + CallableT, CalledAsT, EnableIfTrivial>::Callbacks{ + &CallImpl}; - CallbackAndInlineFlag = {&Callbacks, IsInlineStorage}; - } +} // namespace detail + +template +class unique_function : public detail::UniqueFunctionBase { + using Base = detail::UniqueFunctionBase; + +public: + unique_function() = default; + unique_function(std::nullptr_t) {} + unique_function(unique_function &&) = default; + unique_function(const unique_function &) = delete; + unique_function &operator=(unique_function &&) = default; + unique_function &operator=(const unique_function &) = delete; - ReturnT operator()(ParamTs... Params) { - void *CallableAddr = - isInlineStorage() ? getInlineStorage() : getOutOfLineStorage(); + template + unique_function(CallableT Callable) + : Base(std::forward(Callable), + typename Base::template CalledAs{}) {} - return (isTrivialCallback() - ? getTrivialCallback() - : getNonTrivialCallbacks()->CallPtr)(CallableAddr, Params...); + R operator()(P... Params) { + return this->getCallPtr()(this->getCalleePtr(), Params...); } +}; - explicit operator bool() const { - return (bool)CallbackAndInlineFlag.getPointer(); +template +class unique_function + : public detail::UniqueFunctionBase { + using Base = detail::UniqueFunctionBase; + +public: + unique_function() = default; + unique_function(std::nullptr_t) {} + unique_function(unique_function &&) = default; + unique_function(const unique_function &) = delete; + unique_function &operator=(unique_function &&) = default; + unique_function &operator=(const unique_function &) = delete; + + template + unique_function(CallableT Callable) + : Base(std::forward(Callable), + typename Base::template CalledAs{}) {} + + R operator()(P... Params) const { + return this->getCallPtr()(this->getCalleePtr(), Params...); } }; diff --git a/gnu/llvm/llvm/include/llvm/ADT/Hashing.h b/gnu/llvm/llvm/include/llvm/ADT/Hashing.h index adcc5cf54da..9ee310c879f 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/Hashing.h +++ b/gnu/llvm/llvm/include/llvm/ADT/Hashing.h @@ -101,8 +101,7 @@ public: /// differing argument types even if they would implicit promote to a common /// type without changing the value. template -typename std::enable_if::value, hash_code>::type -hash_value(T value); +std::enable_if_t::value, hash_code> hash_value(T value); /// Compute a hash_code for a pointer's address. /// @@ -158,10 +157,10 @@ inline uint32_t fetch32(const char *p) { } /// Some primes between 2^63 and 2^64 for various uses. -static const uint64_t k0 = 0xc3a5c85c97cb3127ULL; -static const uint64_t k1 = 0xb492b66fbe98f273ULL; -static const uint64_t k2 = 0x9ae16a3b2f90404fULL; -static const uint64_t k3 = 0xc949d7c7509e6557ULL; +static constexpr uint64_t k0 = 0xc3a5c85c97cb3127ULL; +static constexpr uint64_t k1 = 0xb492b66fbe98f273ULL; +static constexpr uint64_t k2 = 0x9ae16a3b2f90404fULL; +static constexpr uint64_t k3 = 0xc949d7c7509e6557ULL; /// Bitwise right rotate. /// Normally this will compile to a single instruction, especially if the @@ -360,7 +359,7 @@ template struct is_hashable_data > /// Helper to get the hashable data representation for a type. /// This variant is enabled when the type itself can be used. template -typename std::enable_if::value, T>::type +std::enable_if_t::value, T> get_hashable_data(const T &value) { return value; } @@ -368,7 +367,7 @@ get_hashable_data(const T &value) { /// This variant is enabled when we must first call hash_value and use the /// result as our data. template -typename std::enable_if::value, size_t>::type +std::enable_if_t::value, size_t> get_hashable_data(const T &value) { using ::llvm::hash_value; return hash_value(value); @@ -442,7 +441,7 @@ hash_code hash_combine_range_impl(InputIteratorT first, InputIteratorT last) { /// are stored in contiguous memory, this routine avoids copying each value /// and directly reads from the underlying memory. template -typename std::enable_if::value, hash_code>::type +std::enable_if_t::value, hash_code> hash_combine_range_impl(ValueT *first, ValueT *last) { const uint64_t seed = get_execution_seed(); const char *s_begin = reinterpret_cast(first); @@ -627,8 +626,7 @@ inline hash_code hash_integer_value(uint64_t value) { // Declared and documented above, but defined here so that any of the hashing // infrastructure is available. template -typename std::enable_if::value, hash_code>::type -hash_value(T value) { +std::enable_if_t::value, hash_code> hash_value(T value) { return ::llvm::hashing::detail::hash_integer_value( static_cast(value)); } diff --git a/gnu/llvm/llvm/include/llvm/ADT/ImmutableMap.h b/gnu/llvm/llvm/include/llvm/ADT/ImmutableMap.h index 86fd7fefaec..81b21a7319a 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/ImmutableMap.h +++ b/gnu/llvm/llvm/include/llvm/ADT/ImmutableMap.h @@ -70,33 +70,14 @@ public: using TreeTy = ImutAVLTree; protected: - TreeTy* Root; + IntrusiveRefCntPtr Root; public: /// Constructs a map from a pointer to a tree root. In general one /// should use a Factory object to create maps instead of directly /// invoking the constructor, but there are cases where make this /// constructor public is useful. - explicit ImmutableMap(const TreeTy* R) : Root(const_cast(R)) { - if (Root) { Root->retain(); } - } - - ImmutableMap(const ImmutableMap &X) : Root(X.Root) { - if (Root) { Root->retain(); } - } - - ~ImmutableMap() { - if (Root) { Root->release(); } - } - - ImmutableMap &operator=(const ImmutableMap &X) { - if (Root != X.Root) { - if (X.Root) { X.Root->retain(); } - if (Root) { Root->release(); } - Root = X.Root; - } - return *this; - } + explicit ImmutableMap(const TreeTy *R) : Root(const_cast(R)) {} class Factory { typename TreeTy::Factory F; @@ -115,12 +96,12 @@ public: LLVM_NODISCARD ImmutableMap add(ImmutableMap Old, key_type_ref K, data_type_ref D) { - TreeTy *T = F.add(Old.Root, std::pair(K,D)); + TreeTy *T = F.add(Old.Root.get(), std::pair(K, D)); return ImmutableMap(Canonicalize ? F.getCanonicalTree(T): T); } LLVM_NODISCARD ImmutableMap remove(ImmutableMap Old, key_type_ref K) { - TreeTy *T = F.remove(Old.Root,K); + TreeTy *T = F.remove(Old.Root.get(), K); return ImmutableMap(Canonicalize ? F.getCanonicalTree(T): T); } @@ -134,19 +115,20 @@ public: } bool operator==(const ImmutableMap &RHS) const { - return Root && RHS.Root ? Root->isEqual(*RHS.Root) : Root == RHS.Root; + return Root && RHS.Root ? Root->isEqual(*RHS.Root.get()) : Root == RHS.Root; } bool operator!=(const ImmutableMap &RHS) const { - return Root && RHS.Root ? Root->isNotEqual(*RHS.Root) : Root != RHS.Root; + return Root && RHS.Root ? Root->isNotEqual(*RHS.Root.get()) + : Root != RHS.Root; } TreeTy *getRoot() const { if (Root) { Root->retain(); } - return Root; + return Root.get(); } - TreeTy *getRootWithoutRetain() const { return Root; } + TreeTy *getRootWithoutRetain() const { return Root.get(); } void manualRetain() { if (Root) Root->retain(); @@ -217,7 +199,7 @@ public: data_type_ref getData() const { return (*this)->second; } }; - iterator begin() const { return iterator(Root); } + iterator begin() const { return iterator(Root.get()); } iterator end() const { return iterator(); } data_type* lookup(key_type_ref K) const { @@ -243,7 +225,7 @@ public: unsigned getHeight() const { return Root ? Root->getHeight() : 0; } static inline void Profile(FoldingSetNodeID& ID, const ImmutableMap& M) { - ID.AddPointer(M.Root); + ID.AddPointer(M.Root.get()); } inline void Profile(FoldingSetNodeID& ID) const { @@ -266,7 +248,7 @@ public: using FactoryTy = typename TreeTy::Factory; protected: - TreeTy *Root; + IntrusiveRefCntPtr Root; FactoryTy *Factory; public: @@ -274,44 +256,12 @@ public: /// should use a Factory object to create maps instead of directly /// invoking the constructor, but there are cases where make this /// constructor public is useful. - explicit ImmutableMapRef(const TreeTy *R, FactoryTy *F) - : Root(const_cast(R)), Factory(F) { - if (Root) { - Root->retain(); - } - } + ImmutableMapRef(const TreeTy *R, FactoryTy *F) + : Root(const_cast(R)), Factory(F) {} - explicit ImmutableMapRef(const ImmutableMap &X, - typename ImmutableMap::Factory &F) - : Root(X.getRootWithoutRetain()), - Factory(F.getTreeFactory()) { - if (Root) { Root->retain(); } - } - - ImmutableMapRef(const ImmutableMapRef &X) : Root(X.Root), Factory(X.Factory) { - if (Root) { - Root->retain(); - } - } - - ~ImmutableMapRef() { - if (Root) - Root->release(); - } - - ImmutableMapRef &operator=(const ImmutableMapRef &X) { - if (Root != X.Root) { - if (X.Root) - X.Root->retain(); - - if (Root) - Root->release(); - - Root = X.Root; - Factory = X.Factory; - } - return *this; - } + ImmutableMapRef(const ImmutableMap &X, + typename ImmutableMap::Factory &F) + : Root(X.getRootWithoutRetain()), Factory(F.getTreeFactory()) {} static inline ImmutableMapRef getEmptyMap(FactoryTy *F) { return ImmutableMapRef(0, F); @@ -326,12 +276,13 @@ public: } ImmutableMapRef add(key_type_ref K, data_type_ref D) const { - TreeTy *NewT = Factory->add(Root, std::pair(K, D)); + TreeTy *NewT = + Factory->add(Root.get(), std::pair(K, D)); return ImmutableMapRef(NewT, Factory); } ImmutableMapRef remove(key_type_ref K) const { - TreeTy *NewT = Factory->remove(Root, K); + TreeTy *NewT = Factory->remove(Root.get(), K); return ImmutableMapRef(NewT, Factory); } @@ -340,15 +291,16 @@ public: } ImmutableMap asImmutableMap() const { - return ImmutableMap(Factory->getCanonicalTree(Root)); + return ImmutableMap(Factory->getCanonicalTree(Root.get())); } bool operator==(const ImmutableMapRef &RHS) const { - return Root && RHS.Root ? Root->isEqual(*RHS.Root) : Root == RHS.Root; + return Root && RHS.Root ? Root->isEqual(*RHS.Root.get()) : Root == RHS.Root; } bool operator!=(const ImmutableMapRef &RHS) const { - return Root && RHS.Root ? Root->isNotEqual(*RHS.Root) : Root != RHS.Root; + return Root && RHS.Root ? Root->isNotEqual(*RHS.Root.get()) + : Root != RHS.Root; } bool isEmpty() const { return !Root; } @@ -377,7 +329,7 @@ public: data_type_ref getData() const { return (*this)->second; } }; - iterator begin() const { return iterator(Root); } + iterator begin() const { return iterator(Root.get()); } iterator end() const { return iterator(); } data_type *lookup(key_type_ref K) const { @@ -403,7 +355,7 @@ public: unsigned getHeight() const { return Root ? Root->getHeight() : 0; } static inline void Profile(FoldingSetNodeID &ID, const ImmutableMapRef &M) { - ID.AddPointer(M.Root); + ID.AddPointer(M.Root.get()); } inline void Profile(FoldingSetNodeID &ID) const { return Profile(ID, *this); } diff --git a/gnu/llvm/llvm/include/llvm/ADT/ImmutableSet.h b/gnu/llvm/llvm/include/llvm/ADT/ImmutableSet.h index a6a6abfd960..f19913f8dcd 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/ImmutableSet.h +++ b/gnu/llvm/llvm/include/llvm/ADT/ImmutableSet.h @@ -15,6 +15,7 @@ #include "llvm/ADT/DenseMap.h" #include "llvm/ADT/FoldingSet.h" +#include "llvm/ADT/IntrusiveRefCntPtr.h" #include "llvm/ADT/SmallVector.h" #include "llvm/ADT/iterator.h" #include "llvm/Support/Allocator.h" @@ -169,7 +170,7 @@ public: bool contains(key_type_ref K) { return (bool) find(K); } /// foreach - A member template the accepts invokes operator() on a functor - /// object (specifed by Callback) for every node/subtree in the tree. + /// object (specified by Callback) for every node/subtree in the tree. /// Nodes are visited using an inorder traversal. template void foreach(Callback& C) { @@ -183,7 +184,7 @@ public: } /// validateTree - A utility method that checks that the balancing and - /// ordering invariants of the tree are satisifed. It is a recursive + /// ordering invariants of the tree are satisfied. It is a recursive /// method that returns the height of the tree, which is then consumed /// by the enclosing validateTree call. External callers should ignore the /// return value. An invalid tree will cause an assertion to fire in @@ -357,6 +358,12 @@ public: } }; +template +struct IntrusiveRefCntPtrInfo> { + static void retain(ImutAVLTree *Tree) { Tree->retain(); } + static void release(ImutAVLTree *Tree) { Tree->release(); } +}; + //===----------------------------------------------------------------------===// // Immutable AVL-Tree Factory class. //===----------------------------------------------------------------------===// @@ -450,7 +457,7 @@ protected: //===--------------------------------------------------===// // "createNode" is used to generate new tree roots that link - // to other trees. The functon may also simply move links + // to other trees. The function may also simply move links // in an existing root if that root is still marked mutable. // This is necessary because otherwise our balancing code // would leak memory as it would create nodes that are @@ -961,33 +968,14 @@ public: using TreeTy = ImutAVLTree; private: - TreeTy *Root; + IntrusiveRefCntPtr Root; public: /// Constructs a set from a pointer to a tree root. In general one /// should use a Factory object to create sets instead of directly /// invoking the constructor, but there are cases where make this /// constructor public is useful. - explicit ImmutableSet(TreeTy* R) : Root(R) { - if (Root) { Root->retain(); } - } - - ImmutableSet(const ImmutableSet &X) : Root(X.Root) { - if (Root) { Root->retain(); } - } - - ~ImmutableSet() { - if (Root) { Root->release(); } - } - - ImmutableSet &operator=(const ImmutableSet &X) { - if (Root != X.Root) { - if (X.Root) { X.Root->retain(); } - if (Root) { Root->release(); } - Root = X.Root; - } - return *this; - } + explicit ImmutableSet(TreeTy *R) : Root(R) {} class Factory { typename TreeTy::Factory F; @@ -1016,7 +1004,7 @@ public: /// The memory allocated to represent the set is released when the /// factory object that created the set is destroyed. LLVM_NODISCARD ImmutableSet add(ImmutableSet Old, value_type_ref V) { - TreeTy *NewT = F.add(Old.Root, V); + TreeTy *NewT = F.add(Old.Root.get(), V); return ImmutableSet(Canonicalize ? F.getCanonicalTree(NewT) : NewT); } @@ -1028,7 +1016,7 @@ public: /// The memory allocated to represent the set is released when the /// factory object that created the set is destroyed. LLVM_NODISCARD ImmutableSet remove(ImmutableSet Old, value_type_ref V) { - TreeTy *NewT = F.remove(Old.Root, V); + TreeTy *NewT = F.remove(Old.Root.get(), V); return ImmutableSet(Canonicalize ? F.getCanonicalTree(NewT) : NewT); } @@ -1047,21 +1035,20 @@ public: } bool operator==(const ImmutableSet &RHS) const { - return Root && RHS.Root ? Root->isEqual(*RHS.Root) : Root == RHS.Root; + return Root && RHS.Root ? Root->isEqual(*RHS.Root.get()) : Root == RHS.Root; } bool operator!=(const ImmutableSet &RHS) const { - return Root && RHS.Root ? Root->isNotEqual(*RHS.Root) : Root != RHS.Root; + return Root && RHS.Root ? Root->isNotEqual(*RHS.Root.get()) + : Root != RHS.Root; } TreeTy *getRoot() { if (Root) { Root->retain(); } - return Root; + return Root.get(); } - TreeTy *getRootWithoutRetain() const { - return Root; - } + TreeTy *getRootWithoutRetain() const { return Root.get(); } /// isEmpty - Return true if the set contains no elements. bool isEmpty() const { return !Root; } @@ -1082,7 +1069,7 @@ public: using iterator = ImutAVLValueIterator; - iterator begin() const { return iterator(Root); } + iterator begin() const { return iterator(Root.get()); } iterator end() const { return iterator(); } //===--------------------------------------------------===// @@ -1092,7 +1079,7 @@ public: unsigned getHeight() const { return Root ? Root->getHeight() : 0; } static void Profile(FoldingSetNodeID &ID, const ImmutableSet &S) { - ID.AddPointer(S.Root); + ID.AddPointer(S.Root.get()); } void Profile(FoldingSetNodeID &ID) const { return Profile(ID, *this); } @@ -1114,7 +1101,7 @@ public: using FactoryTy = typename TreeTy::Factory; private: - TreeTy *Root; + IntrusiveRefCntPtr Root; FactoryTy *Factory; public: @@ -1122,42 +1109,18 @@ public: /// should use a Factory object to create sets instead of directly /// invoking the constructor, but there are cases where make this /// constructor public is useful. - explicit ImmutableSetRef(TreeTy* R, FactoryTy *F) - : Root(R), - Factory(F) { - if (Root) { Root->retain(); } - } - - ImmutableSetRef(const ImmutableSetRef &X) - : Root(X.Root), - Factory(X.Factory) { - if (Root) { Root->retain(); } - } - - ~ImmutableSetRef() { - if (Root) { Root->release(); } - } - - ImmutableSetRef &operator=(const ImmutableSetRef &X) { - if (Root != X.Root) { - if (X.Root) { X.Root->retain(); } - if (Root) { Root->release(); } - Root = X.Root; - Factory = X.Factory; - } - return *this; - } + ImmutableSetRef(TreeTy *R, FactoryTy *F) : Root(R), Factory(F) {} static ImmutableSetRef getEmptySet(FactoryTy *F) { return ImmutableSetRef(0, F); } ImmutableSetRef add(value_type_ref V) { - return ImmutableSetRef(Factory->add(Root, V), Factory); + return ImmutableSetRef(Factory->add(Root.get(), V), Factory); } ImmutableSetRef remove(value_type_ref V) { - return ImmutableSetRef(Factory->remove(Root, V), Factory); + return ImmutableSetRef(Factory->remove(Root.get(), V), Factory); } /// Returns true if the set contains the specified value. @@ -1166,20 +1129,19 @@ public: } ImmutableSet asImmutableSet(bool canonicalize = true) const { - return ImmutableSet(canonicalize ? - Factory->getCanonicalTree(Root) : Root); + return ImmutableSet( + canonicalize ? Factory->getCanonicalTree(Root.get()) : Root.get()); } - TreeTy *getRootWithoutRetain() const { - return Root; - } + TreeTy *getRootWithoutRetain() const { return Root.get(); } bool operator==(const ImmutableSetRef &RHS) const { - return Root && RHS.Root ? Root->isEqual(*RHS.Root) : Root == RHS.Root; + return Root && RHS.Root ? Root->isEqual(*RHS.Root.get()) : Root == RHS.Root; } bool operator!=(const ImmutableSetRef &RHS) const { - return Root && RHS.Root ? Root->isNotEqual(*RHS.Root) : Root != RHS.Root; + return Root && RHS.Root ? Root->isNotEqual(*RHS.Root.get()) + : Root != RHS.Root; } /// isEmpty - Return true if the set contains no elements. @@ -1195,7 +1157,7 @@ public: using iterator = ImutAVLValueIterator; - iterator begin() const { return iterator(Root); } + iterator begin() const { return iterator(Root.get()); } iterator end() const { return iterator(); } //===--------------------------------------------------===// @@ -1205,7 +1167,7 @@ public: unsigned getHeight() const { return Root ? Root->getHeight() : 0; } static void Profile(FoldingSetNodeID &ID, const ImmutableSetRef &S) { - ID.AddPointer(S.Root); + ID.AddPointer(S.Root.get()); } void Profile(FoldingSetNodeID &ID) const { return Profile(ID, *this); } diff --git a/gnu/llvm/llvm/include/llvm/ADT/IntervalMap.h b/gnu/llvm/llvm/include/llvm/ADT/IntervalMap.h index a02876ee77f..db7804d0a55 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/IntervalMap.h +++ b/gnu/llvm/llvm/include/llvm/ADT/IntervalMap.h @@ -491,7 +491,7 @@ class NodeRef { struct CacheAlignedPointerTraits { static inline void *getAsVoidPointer(void *P) { return P; } static inline void *getFromVoidPointer(void *P) { return P; } - enum { NumLowBitsAvailable = Log2CacheLine }; + static constexpr int NumLowBitsAvailable = Log2CacheLine; }; PointerIntPair pip; @@ -823,7 +823,7 @@ public: } /// reset - Reset cached information about node(Level) from subtree(Level -1). - /// @param Level 1..height. THe node to update after parent node changed. + /// @param Level 1..height. The node to update after parent node changed. void reset(unsigned Level) { path[Level] = Entry(subtree(Level - 1), offset(Level)); } @@ -884,7 +884,7 @@ public: } /// getLeftSibling - Get the left sibling node at Level, or a null NodeRef. - /// @param Level Get the sinbling to node(Level). + /// @param Level Get the sibling to node(Level). /// @return Left sibling, or NodeRef(). NodeRef getRightSibling(unsigned Level) const; @@ -1396,7 +1396,7 @@ public: setRoot(map->rootSize); } - /// preincrement - move to the next interval. + /// preincrement - Move to the next interval. const_iterator &operator++() { assert(valid() && "Cannot increment end()"); if (++path.leafOffset() == path.leafSize() && branched()) @@ -1404,14 +1404,14 @@ public: return *this; } - /// postincrement - Dont do that! + /// postincrement - Don't do that! const_iterator operator++(int) { const_iterator tmp = *this; operator++(); return tmp; } - /// predecrement - move to the previous interval. + /// predecrement - Move to the previous interval. const_iterator &operator--() { if (path.leafOffset() && (valid() || !branched())) --path.leafOffset(); @@ -1420,7 +1420,7 @@ public: return *this; } - /// postdecrement - Dont do that! + /// postdecrement - Don't do that! const_iterator operator--(int) { const_iterator tmp = *this; operator--(); diff --git a/gnu/llvm/llvm/include/llvm/ADT/Optional.h b/gnu/llvm/llvm/include/llvm/ADT/Optional.h index c84f9aa8b34..c64b8235239 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/Optional.h +++ b/gnu/llvm/llvm/include/llvm/ADT/Optional.h @@ -269,7 +269,7 @@ public: /// Apply a function to the value if present; otherwise return None. template - auto map(const Function &F) const + auto map(const Function &F) const LLVM_LVALUE_FUNCTION -> Optional { if (*this) return F(getValue()); return None; diff --git a/gnu/llvm/llvm/include/llvm/ADT/PointerEmbeddedInt.h b/gnu/llvm/llvm/include/llvm/ADT/PointerEmbeddedInt.h index 3eb6edb0343..fbc48af79da 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/PointerEmbeddedInt.h +++ b/gnu/llvm/llvm/include/llvm/ADT/PointerEmbeddedInt.h @@ -94,7 +94,7 @@ struct PointerLikeTypeTraits> { return T(reinterpret_cast(P), typename T::RawValueTag()); } - enum { NumLowBitsAvailable = T::Shift }; + static constexpr int NumLowBitsAvailable = T::Shift; }; // Teach DenseMap how to use PointerEmbeddedInt objects as keys if the Int type diff --git a/gnu/llvm/llvm/include/llvm/ADT/PointerIntPair.h b/gnu/llvm/llvm/include/llvm/ADT/PointerIntPair.h index fa6bf150446..cb8b202c48b 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/PointerIntPair.h +++ b/gnu/llvm/llvm/include/llvm/ADT/PointerIntPair.h @@ -147,7 +147,7 @@ struct PointerIntPairInfo { "cannot use a pointer type that has all bits free"); static_assert(IntBits <= PtrTraits::NumLowBitsAvailable, "PointerIntPair with integer size too large for pointer"); - enum : uintptr_t { + enum MaskAndShiftConstants : uintptr_t { /// PointerBitMask - The bits that come from the pointer. PointerBitMask = ~(uintptr_t)(((intptr_t)1 << PtrTraits::NumLowBitsAvailable) - 1), @@ -235,7 +235,8 @@ struct PointerLikeTypeTraits< return PointerIntPair::getFromOpaqueValue(P); } - enum { NumLowBitsAvailable = PtrTraits::NumLowBitsAvailable - IntBits }; + static constexpr int NumLowBitsAvailable = + PtrTraits::NumLowBitsAvailable - IntBits; }; } // end namespace llvm diff --git a/gnu/llvm/llvm/include/llvm/ADT/PointerSumType.h b/gnu/llvm/llvm/include/llvm/ADT/PointerSumType.h index d467f83f58a..a7ef774e205 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/PointerSumType.h +++ b/gnu/llvm/llvm/include/llvm/ADT/PointerSumType.h @@ -214,7 +214,7 @@ struct PointerSumTypeHelper : MemberTs... { LookupOverload(PointerSumTypeMember *); template static void LookupOverload(...); template struct Lookup { - // Compute a particular member type by resolving the lookup helper ovorload. + // Compute a particular member type by resolving the lookup helper overload. using MemberT = decltype( LookupOverload(static_cast(nullptr))); diff --git a/gnu/llvm/llvm/include/llvm/ADT/PointerUnion.h b/gnu/llvm/llvm/include/llvm/ADT/PointerUnion.h index 40b7b000da4..6fecff8d756 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/PointerUnion.h +++ b/gnu/llvm/llvm/include/llvm/ADT/PointerUnion.h @@ -181,7 +181,7 @@ public: explicit operator bool() const { return !isNull(); } /// Test if the Union currently holds the type matching T. - template int is() const { + template bool is() const { constexpr int Index = pointer_union_detail::TypeIndex::Index; static_assert(Index < sizeof...(PTs), "PointerUnion::is given type not in the union"); @@ -197,7 +197,7 @@ public: } /// Returns the current pointer if it is of the specified pointer type, - /// otherwises returns null. + /// otherwise returns null. template T dyn_cast() const { if (is()) return get(); diff --git a/gnu/llvm/llvm/include/llvm/ADT/PostOrderIterator.h b/gnu/llvm/llvm/include/llvm/ADT/PostOrderIterator.h index 2fe7447a8e7..bb413a956d9 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/PostOrderIterator.h +++ b/gnu/llvm/llvm/include/llvm/ADT/PostOrderIterator.h @@ -18,6 +18,7 @@ #include "llvm/ADT/GraphTraits.h" #include "llvm/ADT/Optional.h" #include "llvm/ADT/SmallPtrSet.h" +#include "llvm/ADT/SmallVector.h" #include "llvm/ADT/iterator_range.h" #include #include @@ -101,7 +102,7 @@ class po_iterator // VisitStack - Used to maintain the ordering. Top = current block // First element is basic block pointer, second is the 'next child' to visit - std::vector> VisitStack; + SmallVector, 8> VisitStack; po_iterator(NodeRef BB) { this->insertEdge(Optional(), BB); diff --git a/gnu/llvm/llvm/include/llvm/ADT/PriorityWorklist.h b/gnu/llvm/llvm/include/llvm/ADT/PriorityWorklist.h index 96d22c87557..01dd59a2e71 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/PriorityWorklist.h +++ b/gnu/llvm/llvm/include/llvm/ADT/PriorityWorklist.h @@ -110,7 +110,7 @@ public: /// Insert a sequence of new elements into the PriorityWorklist. template - typename std::enable_if::value>::type + std::enable_if_t::value> insert(SequenceT &&Input) { if (std::begin(Input) == std::end(Input)) // Nothing to do for an empty input sequence. diff --git a/gnu/llvm/llvm/include/llvm/ADT/SCCIterator.h b/gnu/llvm/llvm/include/llvm/ADT/SCCIterator.h index 1e642b9f75d..8a7c0a78a0f 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/SCCIterator.h +++ b/gnu/llvm/llvm/include/llvm/ADT/SCCIterator.h @@ -124,11 +124,11 @@ public: return CurrentSCC; } - /// Test if the current SCC has a loop. + /// Test if the current SCC has a cycle. /// /// If the SCC has more than one node, this is trivially true. If not, it may - /// still contain a loop if the node has an edge back to itself. - bool hasLoop() const; + /// still contain a cycle if the node has an edge back to itself. + bool hasCycle() const; /// This informs the \c scc_iterator that the specified \c Old node /// has been deleted, and \c New is to be used in its place. @@ -212,7 +212,7 @@ template void scc_iterator::GetNextSCC() { } template -bool scc_iterator::hasLoop() const { +bool scc_iterator::hasCycle() const { assert(!CurrentSCC.empty() && "Dereferencing END SCC iterator!"); if (CurrentSCC.size() > 1) return true; diff --git a/gnu/llvm/llvm/include/llvm/ADT/STLExtras.h b/gnu/llvm/llvm/include/llvm/ADT/STLExtras.h index b61dab2459d..50b688b3664 100644 --- a/gnu/llvm/llvm/include/llvm/ADT/STLExtras.h +++ b/gnu/llvm/llvm/include/llvm/ADT/STLExtras.h @@ -50,6 +50,10 @@ namespace detail { template using IterOfRange = decltype(std::begin(std::declval())); +template +using ValueOfRange = typename std::remove_reference()))>::type; + } // end namespace detail //===----------------------------------------------------------------------===// @@ -75,6 +79,79 @@ template struct make_const_ref { typename std::add_const::type>::type; }; +/// Utilities for detecting if a given trait holds for some set of arguments +/// 'Args'. For example, the given trait could be used to detect if a given type +/// has a copy assignment operator: +/// template +/// using has_copy_assign_t = decltype(std::declval() +/// = std::declval()); +/// bool fooHasCopyAssign = is_detected::value; +namespace detail { +template using void_t = void; +template class Op, class... Args> struct detector { + using value_t = std::false_type; +}; +template