Skip to content

Commit d3762ed

Browse files
authored
[docs] Fix typos and remove redundant whitespace (llvm#169981)
As the title says, I fixed some spelling mistakes I found in the docs.
1 parent 66d33ce commit d3762ed

File tree

3 files changed

+26
-26
lines changed

3 files changed

+26
-26
lines changed

llvm/docs/InstCombineContributorGuide.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -338,7 +338,7 @@ complexity and increasing compile-time overhead.
338338

339339
We do not require explicit proof of real-world usefulness for every transform
340340
-- in most cases the usefulness is fairly "obvious". However, the question may
341-
come up for complex or unusual folds. Keep this in mind when chosing what you
341+
come up for complex or unusual folds. Keep this in mind when choosing what you
342342
work on.
343343

344344
In particular, fixes for fuzzer-generated missed optimization reports will

llvm/docs/KeyInstructionsDebugInfo.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -82,7 +82,7 @@ int c =
8282
```
8383
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.
8484

85-
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.:
85+
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.:
8686
```c
8787
int e = // atom 1
8888
(a + b) // atom 1

llvm/docs/Telemetry.rst

Lines changed: 24 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -32,7 +32,7 @@ Important notes
3232
* There is no concrete implementation of a Telemetry library in upstream LLVM.
3333
We only provide the abstract API here. Any tool that wants telemetry will
3434
implement one.
35-
35+
3636
The rationale for this is that all the tools in LLVM are very different in
3737
what they care about (what/where/when to instrument data). Hence, it might not
3838
be practical to have a single implementation.
@@ -41,16 +41,16 @@ Important notes
4141

4242
* No implementation of Telemetry in upstream LLVM shall store any of the
4343
collected data due to privacy and security reasons:
44-
44+
4545
* Different organizations have different privacy models:
46-
46+
4747
* Which data is sensitive, which is not?
4848
* Whether it is acceptable for instrumented data to be stored anywhere?
4949
(to a local file, what not?)
50-
50+
5151
* Data ownership and data collection consents are hard to accommodate from
5252
LLVM developers' point of view:
53-
53+
5454
* E.g., data collected by Telemetry is not necessarily owned by the user
5555
of an LLVM tool with Telemetry enabled, hence the user's consent to data
5656
collection is not meaningful. On the other hand, LLVM developers have no
@@ -75,7 +75,7 @@ The framework consists of four important classes:
7575
It is up to the vendor to decide which pieces of data to forward and where
7676
to forward them to for their final storage.
7777
* ``llvm::telemetry::Config``: Configurations for the ``Manager``.
78-
78+
7979
.. image:: llvm_telemetry_design.png
8080

8181
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
123123
void write(StringRef KeyName, unsigned long Value) override {
124124
writeHelper(KeyName, Value);
125125
}
126-
126+
127127
void write(StringRef KeyName, unsigned long long Value) override {
128128
writeHelper(KeyName, Value);
129129
}
130130

131131
void write(StringRef KeyName, StringRef Value) override {
132132
writeHelper(KeyName, Value);
133133
}
134-
134+
135135
void beginObject(StringRef KeyName) override {
136136
Children.push_back(json::Object());
137137
ChildrenNames.push_back(KeyName.str());
138138
}
139-
139+
140140
void endObject() override {
141141
assert(!Children.empty() && !ChildrenNames.empty());
142142
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
146146
ChildrenNames.pop_back();
147147
writeHelper(Name, std::move(Val));
148148
}
149-
149+
150150
Error finalize() override {
151151
if (!Started)
152152
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
167167
std::vector<json::Object> Children;
168168
std::vector<std::string> ChildrenNames;
169169
};
170-
171-
class MyManager : public telemery::Manager {
170+
171+
class MyManager : public telemetry::Manager {
172172
public:
173-
static std::unique_ptr<MyManager> createInstatnce(telemetry::Config *Config) {
173+
static std::unique_ptr<MyManager> createInstance(telemetry::Config *Config) {
174174
// If Telemetry is not enabled, then just return null;
175175
if (!Config->EnableTelemetry)
176176
return nullptr;
@@ -182,19 +182,19 @@ To use Telemetry in your tool, you need to provide a concrete implementation of
182182
Entry->SessionId = SessionId;
183183
return Error::success();
184184
}
185-
185+
186186
// You can also define additional instrumentation points.
187187
void logStartup(TelemetryInfo *Entry) {
188188
// Add some additional data to entry.
189189
Entry->Msg = "Some message";
190190
dispatch(Entry);
191191
}
192-
192+
193193
void logAdditionalPoint(TelemetryInfo *Entry) {
194194
// .... code here
195195
}
196-
197-
private:
196+
197+
private:
198198
const std::string SessionId;
199199
};
200200

@@ -203,11 +203,11 @@ To use Telemetry in your tool, you need to provide a concrete implementation of
203203
Error receiveEntry(const TelemetryInfo *Entry) override {
204204
if (Error Err = Serializer.init())
205205
return Err;
206-
206+
207207
Entry->serialize(Serializer);
208208
if (Error Err = Serializer.finalize())
209209
return Err;
210-
210+
211211
json::Object Copied = *Serializer.getOutputObject();
212212
// Send the `Copied` object to wherever.
213213
return Error::success();
@@ -220,16 +220,16 @@ To use Telemetry in your tool, you need to provide a concrete implementation of
220220
// This defines a custom TelemetryInfo that has an additional Msg field.
221221
struct MyTelemetryInfo : public telemetry::TelemetryInfo {
222222
std::string Msg;
223-
223+
224224
Error serialize(Serializer &Serializer) const override {
225225
TelemetryInfo::serialize(serializer);
226226
Serializer.writeString("MyMsg", Msg);
227227
}
228-
228+
229229
// Note: implement getKind() and classof() to support dyn_cast operations.
230230
};
231231

232-
232+
233233
2) Use the library in your tool.
234234

235235
Logging the tool init-process:
@@ -241,10 +241,10 @@ Logging the tool init-process:
241241
telemetry::Config MyConfig = makeConfig(); // Build up the appropriate Config struct here.
242242
auto Manager = MyManager::createInstance(&MyConfig);
243243

244-
244+
245245
// Any other tool's init code can go here.
246246
// ...
247-
247+
248248
// Finally, take a snapshot of the time now so we know how long it took the
249249
// init process to finish.
250250
auto EndTime = std::chrono::time_point<std::chrono::steady_clock>::now();

0 commit comments

Comments
 (0)