From: Bill Wendling Date: Wed, 27 Oct 2010 01:07:41 +0000 (+0000) Subject: Random cleanups and format changes. X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=1b383ba6ae47498ea80250a0369e10e2bf3c6331;p=oota-llvm.git Random cleanups and format changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117428 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/LangRef.html b/docs/LangRef.html index eb09de7e63c..f15f139aeb3 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -2162,8 +2162,8 @@ Classifications

The string 'undef' can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. - Undefined values may be of any type (other than label or void) and be used - anywhere a constant is permitted.

+ 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 they indicate to the compiler that the program is well defined no matter what value is used. This gives the @@ -2182,7 +2182,7 @@ Safe:

This is safe because all of the output bits are affected by the undef bits. -Any output bit can have a zero or one depending on the input bits.

+ Any output bit can have a zero or one depending on the input bits.

   %A = or %X, undef
@@ -2196,13 +2196,14 @@ 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 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.

+ For example, if %X has a zero bit, then the output of the + 'and' operation will always be a zero for that bit, no matter what + the corresponding bit from the 'undef' is. As 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.

   %A = select undef, %X, %Y
@@ -2218,13 +2219,14 @@ Unsafe:
   %C = undef
-

This set of examples show that undefined select (and conditional branch) -conditions can go "either way" but they have to come from one of the two -operands. In the %A example, if %X and %Y were both known to have a clear low -bit, then %A would have to have a cleared low bit. However, in the %C example, -the optimizer is allowed to assume that the undef operand could be the same as -%Y, allowing the whole select to be eliminated.

- +

This set of examples shows that undefined 'select' (and conditional + branch) conditions can go either way, but they have to come from one + of the two operands. In the %A example, if %X and + %Y were both known to have a clear low bit, then %A would + have to have a cleared low bit. However, in the %C example, the + optimizer is allowed to assume that the 'undef' operand could be the + same as %Y, allowing the whole 'select' to be + eliminated.

   %A = xor undef, undef
@@ -2245,16 +2247,17 @@ Safe:
   %F = undef
-

This example points out that two undef operands are not necessarily the same. -This can be surprising to people (and also matches C semantics) where they -assume that "X^X" is always zero, even if X is undef. This isn't true for a -number of reasons, but the short answer is that an undef "variable" can -arbitrarily change its value over its "live range". This is true because the -"variable" doesn't actually have a live range. Instead, the value is -logically read from arbitrary registers that happen to be around when needed, -so the value is not necessarily consistent over time. In fact, %A and %C need -to have the same semantics or the core LLVM "replace all uses with" concept -would not hold.

+

This example points out that two 'undef' operands are not + necessarily the same. This can be surprising to people (and also matches C + semantics) where they assume that "X^X" is always zero, even + if X is undefined. This isn't true for a number of reasons, but the + short answer is that an 'undef' "variable" can arbitrarily change + its value over its "live range". This is true because the variable doesn't + actually have a live range. Instead, the value is logically read + from arbitrary registers that happen to be around when needed, so the value + is not necessarily consistent over time. In fact, %A and %C + need to have the same semantics or the core LLVM "replace all uses with" + concept would not hold.

   %A = fdiv undef, %X
@@ -2265,17 +2268,17 @@ b: unreachable

These examples show the crucial difference between an undefined -value and undefined behavior. An undefined value (like undef) is -allowed to have an arbitrary bit-pattern. This means that the %A operation -can be constant folded to undef because the undef could be an SNaN, and fdiv is -not (currently) defined on SNaN's. However, in the second example, we can make -a more aggressive assumption: because the undef is allowed to be an arbitrary -value, we are allowed to assume that it could be zero. Since a divide by zero -has undefined behavior, we are allowed to assume that the operation -does not execute at all. This allows us to delete the divide and all code after -it: since the undefined operation "can't happen", the optimizer can assume that -it occurs in dead code. -

+ value and undefined behavior. An undefined value (like + 'undef') is allowed to have an arbitrary bit-pattern. This means that + the %A operation can be constant folded to 'undef', because + the 'undef' could be an SNaN, and fdiv is not (currently) + defined on SNaN's. However, in the second example, we can make a more + aggressive assumption: because the undef is allowed to be an + arbitrary value, we are allowed to assume that it could be zero. Since a + divide by zero has undefined behavior, we are allowed to assume that + the operation does not execute at all. This allows us to delete the divide and + all code after it. Because the undefined operation "can't happen", the + optimizer can assume that it occurs in dead code.

 a:  store undef -> %X
@@ -2285,11 +2288,11 @@ a: <deleted>
 b: unreachable
-

These examples reiterate the fdiv example: a store "of" an undefined value -can be assumed to not have any effect: we can assume that the value is -overwritten with bits that happen to match what was already there. However, a -store "to" an undefined location could clobber arbitrary memory, therefore, it -has undefined behavior.

+

These examples reiterate the fdiv example: a store of an + undefined value can be assumed to not have any effect; we can assume that the + value is overwritten with bits that happen to match what was already there. + However, a store to an undefined location could clobber arbitrary + memory, therefore, it has undefined behavior.

@@ -2410,18 +2413,17 @@ end: the address of the entry block is illegal.

This value only has defined behavior when used as an operand to the - 'indirectbr' instruction or for comparisons - against null. Pointer equality tests between labels addresses is undefined - behavior - though, again, comparison against null is ok, and no label is - equal to the null pointer. This may also be passed around as an opaque - pointer sized value as long as the bits are not inspected. This allows - ptrtoint and arithmetic to be performed on these values so long as - the original value is reconstituted before the indirectbr.

+ 'indirectbr' instruction, or for + comparisons against null. Pointer equality tests between labels addresses + results in undefined behavior — though, again, comparison against null + is ok, and no label is equal to the null pointer. This may be passed around + as an opaque pointer sized value as long as the bits are not inspected. This + allows ptrtoint and arithmetic to be performed on these values so + long as the original value is reconstituted before the indirectbr + instruction.

-

Finally, some targets may provide defined semantics when - using the value as the operand to an inline assembly, but that is target - specific. -

+

Finally, some targets may provide defined semantics when using the value as + the operand to an inline assembly, but that is target specific.

@@ -2436,7 +2438,7 @@ end: to be used as constants. Constant expressions may be of any first class type and may involve any LLVM operation that does not have side effects (e.g. load and call are not - supported). The following is the syntax for constant expressions:

+ supported). The following is the syntax for constant expressions:

trunc (CST to TYPE)
@@ -7674,7 +7676,7 @@ LLVM.

the AllocaInst stack slot to be before local variables on the stack. This is to ensure that if a local variable on the stack is overwritten, it will destroy the value of the guard. When the function exits, - the guard on the stack is checked against the original guard. If they're + the guard on the stack is checked against the original guard. If they are different, then the program aborts by calling the __stack_chk_fail() function.

@@ -7694,25 +7696,24 @@ LLVM.

Overview:
-

The llvm.objectsize intrinsic is designed to provide information - to the optimizers to discover at compile time either a) when an - operation like memcpy will either overflow a buffer that corresponds to - an object, or b) to determine that a runtime check for overflow isn't - necessary. An object in this context means an allocation of a - specific class, structure, array, or other object.

+

The llvm.objectsize intrinsic is designed to provide information to + the optimizers to determine at compile time whether a) an operation (like + memcpy) will overflow a buffer that corresponds to an object, or b) that a + runtime check for overflow isn't necessary. An object in this context means + an allocation of a specific class, structure, array, or other object.

Arguments:
-

The llvm.objectsize intrinsic takes two arguments. The first +

The llvm.objectsize intrinsic takes two arguments. The first argument is a pointer to or into the object. The second argument - is a boolean 0 or 1. This argument determines whether you want the - maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or + is a boolean 0 or 1. This argument determines whether you want the + maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or 1, variables are not allowed.

Semantics:

The llvm.objectsize intrinsic is lowered to either a constant - representing the size of the object concerned or i32/i64 -1 or 0 - (depending on the type argument if the size cannot be determined - at compile time.

+ representing the size of the object concerned, or i32/i64 -1 or 0, + depending on the type argument, if the size cannot be determined at + compile time.