summaryrefslogtreecommitdiffstats
path: root/llvm/docs/HistoricalNotes
diff options
context:
space:
mode:
authorChris Lattner <sabre@nondot.org>2011-04-15 05:18:47 +0000
committerChris Lattner <sabre@nondot.org>2011-04-15 05:18:47 +0000
commit0ab5e2cdedba59b4f81152d72d70e1796f796834 (patch)
tree2b0d5d1a27ca9c3a382b2c0ed091fd7aebc857cc /llvm/docs/HistoricalNotes
parentb5e3e9dd27dce1b3bb10c4f453cea84a0b35bbca (diff)
downloadbcm5719-llvm-0ab5e2cdedba59b4f81152d72d70e1796f796834.tar.gz
bcm5719-llvm-0ab5e2cdedba59b4f81152d72d70e1796f796834.zip
Fix a ton of comment typos found by codespell. Patch by
Luis Felipe Strano Moraes! llvm-svn: 129558
Diffstat (limited to 'llvm/docs/HistoricalNotes')
-rw-r--r--llvm/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt4
-rw-r--r--llvm/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt2
-rw-r--r--llvm/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt2
-rw-r--r--llvm/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt6
-rw-r--r--llvm/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt2
-rw-r--r--llvm/docs/HistoricalNotes/2002-05-12-InstListChange.txt2
6 files changed, 9 insertions, 9 deletions
diff --git a/llvm/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt b/llvm/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt
index 1c725f5aa71..81ca53919d4 100644
--- a/llvm/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt
+++ b/llvm/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt
@@ -60,11 +60,11 @@ Understood. :)
Yup, I think that this makes a lot of sense. I am still intrigued,
however, by the prospect of a minimally allocated VM representation... I
-think that it could have definate advantages for certain applications
+think that it could have definite advantages for certain applications
(think very small machines, like PDAs). I don't, however, think that our
initial implementations should focus on this. :)
-Here are some other auxilliary goals that I think we should consider:
+Here are some other auxiliary goals that I think we should consider:
1. Primary goal: Support a high performance dynamic compilation
system. This means that we have an "ideal" division of labor between
diff --git a/llvm/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt b/llvm/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt
index b66e18556f5..01b644b3517 100644
--- a/llvm/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt
+++ b/llvm/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt
@@ -40,7 +40,7 @@ IDEAS TO CONSIDER
packaged with the bytecodes themselves. As a conceptual implementation
idea, we could include an immediate dominator number for each basic block
in the LLVM bytecode program. Basic blocks could be numbered according
- to the order of occurance in the bytecode representation.
+ to the order of occurrence in the bytecode representation.
2. Including loop header and body information. This would facilitate
detection of intervals and natural loops.
diff --git a/llvm/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt b/llvm/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt
index 7b9032742a2..839732444f9 100644
--- a/llvm/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt
+++ b/llvm/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt
@@ -39,7 +39,7 @@ declaration and calling syntax.
Very true. If you're implementing an object oriented language, however,
remember that you have to do all the pointer to member function stuff
-yourself.... so everytime you invoke a virtual method one is involved
+yourself.... so every time you invoke a virtual method one is involved
(instead of having C++ hide it for you behind "syntactic sugar").
> And the old array syntax:
diff --git a/llvm/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt b/llvm/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt
index 5c87330fb7e..da502636653 100644
--- a/llvm/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt
+++ b/llvm/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt
@@ -18,7 +18,7 @@ suggested, as specified below:
Very true. We should discuss this more, but my reasoning is more of a
consistency argument. There are VERY few instructions that can have all
-of the types eliminated, and doing so when available unnecesarily makes
+of the types eliminated, and doing so when available unnecessarily makes
the language more difficult to handle. Especially when you see 'int
%this' and 'bool %that' all over the place, I think it would be
disorienting to see:
@@ -44,7 +44,7 @@ branches).
No. This was something I was debating for a while, and didn't really feel
strongly about either way. It is common to switch on other types in HLL's
-(for example signed int's are particually common), but in this case, all
+(for example signed int's are particularly common), but in this case, all
that will be added is an additional 'cast' instruction. I removed that
from the spec.
@@ -160,7 +160,7 @@ that can be trivally translated into a conditional move...
> I agree that we need a static data space. Otherwise, emulating global
> data gets unnecessarily complex.
-Definately. Also a later item though. :)
+Definitely. Also a later item though. :)
> We once talked about adding a symbolic thread-id field to each
> ..
diff --git a/llvm/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt b/llvm/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt
index 6c9e0971a04..e61042fd657 100644
--- a/llvm/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt
+++ b/llvm/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt
@@ -42,7 +42,7 @@ Does using GCC's backend buy us anything?
> optimization (step 16 in your list). Do you have a breakdown of that?
Not really. The irritating part of GCC is that it mixes it all up and
-doesn't have a clean seperation of concerns. A lot of the "back end
+doesn't have a clean separation of concerns. A lot of the "back end
optimization" happens right along with other data optimizations (ie, CSE
of machine specific things).
diff --git a/llvm/docs/HistoricalNotes/2002-05-12-InstListChange.txt b/llvm/docs/HistoricalNotes/2002-05-12-InstListChange.txt
index 004edb068d7..638682b49fd 100644
--- a/llvm/docs/HistoricalNotes/2002-05-12-InstListChange.txt
+++ b/llvm/docs/HistoricalNotes/2002-05-12-InstListChange.txt
@@ -17,7 +17,7 @@ iterator to an instruction, which, given just an Instruction*, requires a
linear search of the basic block the instruction is contained in... just
to insert an instruction before another instruction, or to delete an
instruction! This complicates algorithms that should be very simple (like
-simple constant propogation), because they aren't actually sparse anymore,
+simple constant propagation), because they aren't actually sparse anymore,
they have to traverse basic blocks to remove constant propogated
instructions.
OpenPOWER on IntegriCloud