diff options
| author | Kazu Hirata <kazu@codesourcery.com> | 2006-12-02 02:26:04 +0000 |
|---|---|---|
| committer | Kazu Hirata <kazu@gcc.gnu.org> | 2006-12-02 02:26:04 +0000 |
| commit | 2f8e468bf32574acaa21dbb8409b579ff8f16b92 (patch) | |
| tree | dd382bd43e9be4352a80ae68890c6ba09ba0cad1 /gcc/tree-vectorizer.c | |
| parent | 5681c208fa990b5f827b3fc97ff33c076376e44d (diff) | |
| download | gcc-2f8e468bf32574acaa21dbb8409b579ff8f16b92.zip gcc-2f8e468bf32574acaa21dbb8409b579ff8f16b92.tar.gz gcc-2f8e468bf32574acaa21dbb8409b579ff8f16b92.tar.bz2 | |
builtins.c, [...]: Fix comment typos.
* builtins.c, cfgloop.h, cgraph.h, config/arm/arm.c,
config/i386/i386.c, config/i386/i386.h, config/mips/mips.h,
config/rs6000/cell.md, config/rs6000/rs6000.c, config/sh/sh.c,
config/sh/sh4-300.md, config/spu/spu-builtins.def,
config/spu/spu-c.c, config/spu/spu-modes.def,
config/spu/spu.c, config/spu/spu.md,
config/spu/spu_internals.h, config/spu/vmx2spu.h,
fold-const.c, fwprop.c, predict.c, tree-data-ref.h,
tree-flow.h, tree-ssa-loop-manip.c, tree-ssa-loop-niter.c,
tree-ssa-pre.c, tree-vect-analyze.c, tree-vect-transform.c,
tree-vectorizer.c, tree-vrp.c: Fix comment typos. Follow
spelling conventions.
From-SVN: r119442
Diffstat (limited to 'gcc/tree-vectorizer.c')
| -rw-r--r-- | gcc/tree-vectorizer.c | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c index ed37d5f..3e186a3 100644 --- a/gcc/tree-vectorizer.c +++ b/gcc/tree-vectorizer.c @@ -1762,7 +1762,7 @@ vect_is_simple_use (tree operand, loop_vec_info loop_vinfo, tree *def_stmt, vector form (i.e., when operating on arguments of type VECTYPE). The two kinds of widening operations we currently support are - NOP and WIDEN_MULT. This function checks if these oprations + NOP and WIDEN_MULT. This function checks if these operations are supported by the target platform either directly (via vector tree-codes), or via target builtins. @@ -1796,9 +1796,9 @@ supportable_widening_operation (enum tree_code code, tree stmt, tree vectype, vect1: [res1,res2,res3,res4], vect2: [res5,res6,res7,res8]. However, in the special case that the result of the widening operation is - used in a reduction copmutation only, the order doesn't matter (because + used in a reduction computation only, the order doesn't matter (because when vectorizing a reduction we change the order of the computation). - Some targets can take advatage of this and generate more efficient code. + Some targets can take advantage of this and generate more efficient code. For example, targets like Altivec, that support widen_mult using a sequence of {mult_even,mult_odd} generate the following vectors: vect1: [res1,res3,res5,res7], vect2: [res2,res4,res6,res8]. */ |