[docs] Fix typos and remove redundant whitespace

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

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

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,20 +123,20 @@ 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);
     }
 
     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<json::Object> Children;
     std::vector<std::string> ChildrenNames;
   };
-       
-  class MyManager : public telemery::Manager {
+
+  class MyManager : public telemetry::Manager {
   public:
-  static std::unique_ptr<MyManager> createInstatnce(telemetry::Config *Config) {
+  static std::unique_ptr<MyManager> 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<std::chrono::steady_clock>::now();