From c608cb14a7e112901d44dce54f6128fe41d618c3 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Fri, 11 Sep 2009 01:49:31 +0000 Subject: [PATCH] more typos git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81499 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/LangRef.html | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/LangRef.html b/docs/LangRef.html index b3e58138918..bdc9e170642 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -2021,7 +2021,7 @@ Classifications Undefined values may be of any type (other than label or void) and be used anywhere a constant is permitted.

-

Undefined values are useful, because it indicates to the compiler that the +

Undefined values are useful because they indicate to the compiler that the program is well defined no matter what value is used. This gives the compiler more freedom to optimize. Here are some examples of (potentially surprising) transformations that are valid (in pseudo IR):

@@ -2058,10 +2058,11 @@ Unsafe:

These logical operations have bits that are not always affected by the input. For example, if "%X" has a zero bit, then the output of the 'and' operation will always be a zero, no matter what the corresponding bit from the undef is. As -such, it is unsafe to optimizer or assume that the result of the and is undef. -However, it is safe to assume that all bits of the undef are 0, and optimize the -and to 0. Likewise, it is safe to assume that all the bits of the undef operand -to the or could be set, allowing the or to be folded to -1.

+such, it is unsafe to optimize or assume that the result of the and is undef. +However, it is safe to assume that all bits of the undef could be 0, and +optimize the and to 0. Likewise, it is safe to assume that all the bits of +the undef operand to the or could be set, allowing the or to be folded to +-1.