http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51254
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-14 09:38:51 UTC --- On Wed, 14 Dec 2011, duyuehai at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51254 > > --- Comment #5 from Yuehai Du <duyuehai at gmail dot com> 2011-12-14 02:29:07 > UTC --- > (In reply to comment #4) > > On Tue, 13 Dec 2011, duyuehai at gmail dot com wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51254 > > > > > > Yuehai Du <duyuehai at gmail dot com> changed: > > > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > > CC| |duyuehai at gmail dot > > > com, > > > | |rguenth at gcc dot > > > gnu.org > > > > > > --- Comment #2 from Yuehai Du <duyuehai at gmail dot com> 2011-12-13 > > > 04:15:12 UTC --- > > > Hi Richard > > > would it be ok if i submit a patch like this to fix this bug: > > > > > > Index: gcc/tree-ssa-loop-ivopts.c > > > =================================================================== > > > --- gcc/tree-ssa-loop-ivopts.c (版本 182270) > > > +++ gcc/tree-ssa-loop-ivopts.c (工作副本) > > > @@ -102,6 +102,7 @@ along with GCC; see the file COPYING3. If not see > > > cost of different addressing modes. This should be moved to a TBD > > > interface between the GIMPLE and RTL worlds. */ > > > #include "expr.h" > > > +#include "optabs.h" > > > > > > /* The infinite cost. */ > > > #define INFTY 10000000 > > > @@ -1771,6 +1772,7 @@ find_interesting_uses_address (struct ivopts_data > > > } > > > else > > > { > > > + enum machine_mode mem_mode; > > > ifs_ivopts_data.ivopts_data = data; > > > ifs_ivopts_data.stmt = stmt; > > > ifs_ivopts_data.step = size_zero_node; > > > @@ -1786,7 +1788,9 @@ find_interesting_uses_address (struct ivopts_data > > > > > > /* Moreover, on strict alignment platforms, check that it is > > > sufficiently aligned. */ > > > - if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step)) > > > + mem_mode = TYPE_MODE (TREE_TYPE (*op_p)); > > > + if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step) > > > + && optab_handler (movmisalign_optab, mem_mode) == > > > CODE_FOR_nothing) > > > goto fail; > > > > > > base = build_fold_addr_expr (base); > > > > This won't fix it - the movmisalign optab will not be used at expansion > > time as IVOPTs does not properly transfer the misalignment to the > > access type. > > sorry, i made a mistake here. > My initial target is to make IVOPTS work on vector type misaligned access. And > i see the misalignment information for unaligned vector type access is stored > in type and pointer. > tree-ssa-loop-ivopts.c: > else if (DR_MISALIGNMENT (first_dr) == -1) > { > TREE_TYPE (data_ref) > = build_aligned_type (TREE_TYPE (data_ref), > TYPE_ALIGN (elem_type)); > pi->align = TYPE_ALIGN_UNIT (elem_type); > pi->misalign = 0; > } > else > { > TREE_TYPE (data_ref) > = build_aligned_type (TREE_TYPE (data_ref), > TYPE_ALIGN (elem_type)); > pi->misalign = DR_MISALIGNMENT (first_dr); > } > > and IVOPTS will create same type mem_ref when it rewrite use for address. > > so do this work? > align = TYPE_ALIGN(TREE_TYPE(*op_p)); > if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step) > && !(mem_mode != BLK_MODE > && align < GET_MODE_ALIGNMENT (mem_mode) > && optab_handler (movmisalign_optab, mem_mode) != > CODE_FOR_nothing > ) > > ) > goto fail; I suppose this should work. > -- > Yuehai Du > > > > > > Richard. > >
