diff --git a/llvm/docs/InstCombineContributorGuide.md b/llvm/docs/InstCombineContributorGuide.md index 12567fc36f1d1..1c432b9b7446c 100644 --- a/llvm/docs/InstCombineContributorGuide.md +++ b/llvm/docs/InstCombineContributorGuide.md @@ -338,7 +338,7 @@ complexity and increasing compile-time overhead. We do not require explicit proof of real-world usefulness for every transform -- in most cases the usefulness is fairly "obvious". However, the question may -come up for complex or unusual folds. Keep this in mind when chosing what you +come up for complex or unusual folds. Keep this in mind when choosing what you work on. In particular, fixes for fuzzer-generated missed optimization reports will diff --git a/llvm/docs/KeyInstructionsDebugInfo.md b/llvm/docs/KeyInstructionsDebugInfo.md index 305740554c0fe..d93151a236680 100644 --- a/llvm/docs/KeyInstructionsDebugInfo.md +++ b/llvm/docs/KeyInstructionsDebugInfo.md @@ -82,7 +82,7 @@ int c = ``` In the current implementation an `is_stmt` won't be generated for the `a + b` instruction, meaning debuggers will likely step over the `add` and stop at the `store` of the result into `c` (which does get `is_stmt`). A user might have wished to edit `a` or `b` on the previous line in order to alter the result stored to `c`, which they now won't have the chance to do (they'd need to edit the variables on a previous line instead). If the expression was all on one line then they would be able to edit the values before the `add`. For these reasons we're choosing to recommend that the feature should not be enabled at O0. -It should be possible to fix this case if we make a few changes: add all the instructions in the statement (i.e., including the loads) to the atom, and tweak the DwarfEmission code to understand this situation (same atom, different line). So there is room to persue this in the future. Though that gets tricky in some cases due to the [other limitation mentioned above](#lack-of-multiple-atom-membership), e.g.: +It should be possible to fix this case if we make a few changes: add all the instructions in the statement (i.e., including the loads) to the atom, and tweak the DwarfEmission code to understand this situation (same atom, different line). So there is room to pursue this in the future. Though that gets tricky in some cases due to the [other limitation mentioned above](#lack-of-multiple-atom-membership), e.g.: ```c int e = // atom 1 (a + b) // atom 1 diff --git a/llvm/docs/Telemetry.rst b/llvm/docs/Telemetry.rst index 4f30ae82b5628..c36105c99709f 100644 --- a/llvm/docs/Telemetry.rst +++ b/llvm/docs/Telemetry.rst @@ -32,7 +32,7 @@ Important notes * There is no concrete implementation of a Telemetry library in upstream LLVM. We only provide the abstract API here. Any tool that wants telemetry will implement one. - + The rationale for this is that all the tools in LLVM are very different in what they care about (what/where/when to instrument data). Hence, it might not be practical to have a single implementation. @@ -41,16 +41,16 @@ Important notes * No implementation of Telemetry in upstream LLVM shall store any of the collected data due to privacy and security reasons: - + * Different organizations have different privacy models: - + * Which data is sensitive, which is not? * Whether it is acceptable for instrumented data to be stored anywhere? (to a local file, what not?) - + * Data ownership and data collection consents are hard to accommodate from LLVM developers' point of view: - + * E.g., data collected by Telemetry is not necessarily owned by the user of an LLVM tool with Telemetry enabled, hence the user's consent to data collection is not meaningful. On the other hand, LLVM developers have no @@ -75,7 +75,7 @@ The framework consists of four important classes: It is up to the vendor to decide which pieces of data to forward and where to forward them to for their final storage. * ``llvm::telemetry::Config``: Configurations for the ``Manager``. - + .. image:: llvm_telemetry_design.png How to implement and interact with the API @@ -123,7 +123,7 @@ To use Telemetry in your tool, you need to provide a concrete implementation of void write(StringRef KeyName, unsigned long Value) override { writeHelper(KeyName, Value); } - + void write(StringRef KeyName, unsigned long long Value) override { writeHelper(KeyName, Value); } @@ -131,12 +131,12 @@ To use Telemetry in your tool, you need to provide a concrete implementation of void write(StringRef KeyName, StringRef Value) override { writeHelper(KeyName, Value); } - + void beginObject(StringRef KeyName) override { Children.push_back(json::Object()); ChildrenNames.push_back(KeyName.str()); } - + void endObject() override { assert(!Children.empty() && !ChildrenNames.empty()); json::Value Val = json::Value(std::move(Children.back())); @@ -146,7 +146,7 @@ To use Telemetry in your tool, you need to provide a concrete implementation of ChildrenNames.pop_back(); writeHelper(Name, std::move(Val)); } - + Error finalize() override { if (!Started) return createStringError("Serializer not currently in use"); @@ -167,10 +167,10 @@ To use Telemetry in your tool, you need to provide a concrete implementation of std::vector Children; std::vector ChildrenNames; }; - - class MyManager : public telemery::Manager { + + class MyManager : public telemetry::Manager { public: - static std::unique_ptr createInstatnce(telemetry::Config *Config) { + static std::unique_ptr createInstance(telemetry::Config *Config) { // If Telemetry is not enabled, then just return null; if (!Config->EnableTelemetry) return nullptr; @@ -182,19 +182,19 @@ To use Telemetry in your tool, you need to provide a concrete implementation of Entry->SessionId = SessionId; return Error::success(); } - + // You can also define additional instrumentation points. void logStartup(TelemetryInfo *Entry) { // Add some additional data to entry. Entry->Msg = "Some message"; dispatch(Entry); } - + void logAdditionalPoint(TelemetryInfo *Entry) { // .... code here } - - private: + + private: const std::string SessionId; }; @@ -203,11 +203,11 @@ To use Telemetry in your tool, you need to provide a concrete implementation of Error receiveEntry(const TelemetryInfo *Entry) override { if (Error Err = Serializer.init()) return Err; - + Entry->serialize(Serializer); if (Error Err = Serializer.finalize()) return Err; - + json::Object Copied = *Serializer.getOutputObject(); // Send the `Copied` object to wherever. return Error::success(); @@ -220,16 +220,16 @@ To use Telemetry in your tool, you need to provide a concrete implementation of // This defines a custom TelemetryInfo that has an additional Msg field. struct MyTelemetryInfo : public telemetry::TelemetryInfo { std::string Msg; - + Error serialize(Serializer &Serializer) const override { TelemetryInfo::serialize(serializer); Serializer.writeString("MyMsg", Msg); } - + // Note: implement getKind() and classof() to support dyn_cast operations. }; - + 2) Use the library in your tool. Logging the tool init-process: @@ -241,10 +241,10 @@ Logging the tool init-process: telemetry::Config MyConfig = makeConfig(); // Build up the appropriate Config struct here. auto Manager = MyManager::createInstance(&MyConfig); - + // Any other tool's init code can go here. // ... - + // Finally, take a snapshot of the time now so we know how long it took the // init process to finish. auto EndTime = std::chrono::time_point::now();