[Bug tree-optimization/51254] Missed Optimization: IVOPTS don't handle unaligned memory access.

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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.
> 
>