tree-vrp.c, [...]: Fix comment typos.
* tree-vrp.c, config/arm/arm.md, config/arm/arm1020e.md, config/rs6000/rs6000.md: Fix comment typos. Follow splling conventions. * doc/install.texi: Fix a typo. From-SVN: r100516
This commit is contained in:
parent
bc0f348e10
commit
8ab5f5c9fa
|
@ -1,3 +1,10 @@
|
|||
2005-06-02 Kazu Hirata <kazu@codesourcery.com>
|
||||
|
||||
* tree-vrp.c, config/arm/arm.md, config/arm/arm1020e.md,
|
||||
config/rs6000/rs6000.md: Fix comment typos. Follow splling
|
||||
conventions.
|
||||
* doc/install.texi: Fix a typo.
|
||||
|
||||
2005-06-02 Jan Hubicka <jh@suse.cz>
|
||||
|
||||
* cgraphunit.c (cgraph_function_and_variable_visibility): Extern
|
||||
|
|
|
@ -202,8 +202,8 @@
|
|||
; even on a machine with an fpa.
|
||||
; f_load a floating point load from memory
|
||||
; f_store a floating point store to memory
|
||||
; f_load[sd] single/double load from memeory
|
||||
; f_store[sd] single/double store to memeory
|
||||
; f_load[sd] single/double load from memory
|
||||
; f_store[sd] single/double store to memory
|
||||
; f_flag a transfer of co-processor flags to the CPSR
|
||||
; f_mem_r a transfer of a floating point register to a real reg via mem
|
||||
; r_mem_f the reverse of f_mem_r
|
||||
|
|
|
@ -189,8 +189,8 @@
|
|||
;; for loading 2k and 2k - 1 registers.
|
||||
;;
|
||||
;; The ALU pipeline is decoupled after the first cycle unless there is
|
||||
;; a register dependency; the depency is cleared as soon as the LDM/STM
|
||||
;; has dealt with the corresponding register. So for exmple,
|
||||
;; a register dependency; the dependency is cleared as soon as the LDM/STM
|
||||
;; has dealt with the corresponding register. So for example,
|
||||
;; stmia sp, {r0-r3}
|
||||
;; add r0, r0, #4
|
||||
;; will have one fewer stalls than
|
||||
|
|
|
@ -14870,8 +14870,8 @@
|
|||
|
||||
; This pattern could also take immediate values of operand 1,
|
||||
; since the non-NOT version of the operator is used; but this is not
|
||||
; very useful, since in practise operand 1 is a full 32-bit value.
|
||||
; Likewise, operand 5 is in practise either <= 2^16 or it is a register.
|
||||
; very useful, since in practice operand 1 is a full 32-bit value.
|
||||
; Likewise, operand 5 is in practice either <= 2^16 or it is a register.
|
||||
(define_insn "*sync_boolcshort_internal"
|
||||
[(set (match_operand:SI 2 "gpc_reg_operand" "=&r")
|
||||
(match_operator:SI 4 "boolean_operator"
|
||||
|
|
|
@ -1076,7 +1076,7 @@ use DWARF 2 debugging information as the default.
|
|||
@itemx --enable-targets=@var{target_list}
|
||||
Some GCC targets, e.g.@: powerpc64-linux, build bi-arch compilers.
|
||||
These are compilers that are able to generate either 64-bit or 32-bit
|
||||
code. Typicially, the corresponding 32-bit target, e.g.@:
|
||||
code. Typically, the corresponding 32-bit target, e.g.@:
|
||||
powerpc-linux for powerpc64-linux, only generates 32-bit code. This
|
||||
option enables the 32-bit target to be a bi-arch compiler, which is
|
||||
useful when you want a bi-arch compiler that defaults to 32-bit, and
|
||||
|
|
|
@ -666,7 +666,7 @@ value_ranges_intersect_p (value_range_t *vr0, value_range_t *vr1)
|
|||
}
|
||||
|
||||
|
||||
/* Return true if VR includes the value zero, false otheriwse. */
|
||||
/* Return true if VR includes the value zero, false otherwise. */
|
||||
|
||||
static inline bool
|
||||
range_includes_zero_p (value_range_t *vr)
|
||||
|
@ -2855,7 +2855,7 @@ compare_name_with_value (enum tree_code comp, tree var, tree val)
|
|||
|
||||
|
||||
/* Given a comparison code COMP and names N1 and N2, compare all the
|
||||
ranges equivalent to N1 against all the ranges equivalente to N2
|
||||
ranges equivalent to N1 against all the ranges equivalent to N2
|
||||
to determine the value of N1 COMP N2. Return the same value
|
||||
returned by compare_ranges. */
|
||||
|
||||
|
@ -3236,7 +3236,7 @@ vrp_meet (value_range_t *vr0, value_range_t *vr1)
|
|||
return;
|
||||
}
|
||||
|
||||
/* The resulting set of equivalencies is the intersection of
|
||||
/* The resulting set of equivalences is the intersection of
|
||||
the two sets. */
|
||||
if (vr0->equiv && vr1->equiv && vr0->equiv != vr1->equiv)
|
||||
bitmap_and_into (vr0->equiv, vr1->equiv);
|
||||
|
@ -3253,7 +3253,7 @@ vrp_meet (value_range_t *vr0, value_range_t *vr1)
|
|||
&& compare_values (vr0->max, vr1->max) == 0
|
||||
&& compare_values (vr0->min, vr0->max) == 0)
|
||||
{
|
||||
/* The resulting set of equivalencies is the intersection of
|
||||
/* The resulting set of equivalences is the intersection of
|
||||
the two sets. */
|
||||
if (vr0->equiv && vr1->equiv && vr0->equiv != vr1->equiv)
|
||||
bitmap_and_into (vr0->equiv, vr1->equiv);
|
||||
|
@ -3485,12 +3485,12 @@ vrp_finalize (void)
|
|||
code we can also determine that p_5 cannot be NULL and, if q_2 had
|
||||
a non-varying range, p_5's range should also be compatible with it.
|
||||
|
||||
These equivalencies are created by two expressions: ASSERT_EXPR and
|
||||
These equivalences are created by two expressions: ASSERT_EXPR and
|
||||
copy operations. Since p_5 is an assertion on p_4, and p_4 was the
|
||||
result of another assertion, then we can use the fact that p_5 and
|
||||
p_4 are equivalent when evaluating p_5's range.
|
||||
|
||||
Together with value ranges, we also propagate these equivalencies
|
||||
Together with value ranges, we also propagate these equivalences
|
||||
between names so that we can take advantage of information from
|
||||
multiple ranges when doing final replacement. Note that this
|
||||
equivalency relation is transitive but not symmetric.
|
||||
|
|
Loading…
Reference in New Issue