Don't taint relaxed loads that immediately comes before an AcqRel read-modify-write op

[oota-llvm.git] / docs / DeveloperPolicy.rst

diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst
index d4a681a8b313dc8723dde6b41b05d49edaaf0301..17baf2d27b134b2f7e15e8b97ad747f2996ca185 100644 (file)
--- a/docs/DeveloperPolicy.rst
+++ b/docs/DeveloperPolicy.rst
@@ -536,7 +536,7 @@ C API Changes
   less stable than "take this IR file and JIT it for my current machine".
 
 * Release stability: We won't break the C API on the release branch with patches
-  that go on that branch, with the exception that if we will fix an unintentional
+  that go on that branch, with the exception that we will fix an unintentional
   C API break that will keep the release consistent with both the previous and
   next release.
 
@@ -545,8 +545,8 @@ C API Changes
 
 * Including new things into the API: If an LLVM subcomponent has a C API already
   included, then expanding that C API is acceptable. Adding C API for
-  subcomponents that don't currently have one need to be discussed on the mailing
-  list for design and maintainability feedback prior to implementation.
+  subcomponents that don't currently have one needs to be discussed on the
+  mailing list for design and maintainability feedback prior to implementation.
 
 * Documentation: Any changes to the C API are required to be documented in the
   release notes so that it's clear to external users who do not follow the