This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR 49094] Refrain from creating misaligned accesses in SRA
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: richard dot guenther at gmail dot com (Richard Guenther)
- Cc: mjambor at suse dot cz (Martin Jambor), gcc-patches at gcc dot gnu dot org (GCC Patches), rguenther at suse dot de
- Date: Wed, 20 Jul 2011 20:11:06 +0200 (CEST)
- Subject: Re: [PATCH, PR 49094] Refrain from creating misaligned accesses in SRA
Richard Guenther wrote:
> On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> > The problem is that in this expression
> > disappear = VIEW_CONVERT_EXPR<struct VecClass>(x_8);
> > the rhs is considered unaligned and blocks the SRA transformation.
> >
> > The check you added for SSA_NAMEs doesn't hit, because the SSA_NAME is
> > encapsulated in a VIEW_CONVERT_EXPR. When get_object_alignment is called,
> > the VIEW_CONVERT_EXPR is stripped off by get_inner_reference and the
> > SSA_NAME appears, but then get_object_alignment doesn't handle it
> > and just returns the default alignment of 8 bits.
> >
> > Maybe get_object_alignment should itself handle SSA_NAMEs?
>
> But what should it return for a rvalue? There is no "alignment" here.
> I think SRA should avoid asking for rvalues.
I must admit I do not fully understand what the SRA code is attempting
to achieve here ... Could you elaborate on what you mean by "avoid
asking for rvalues"? Should the SRA code never check the RHS of an
assignment for alignment, only the LHS? Or should it classify the RHS
tree according to whether the access is rvalue or lvalue (how would
that work?)?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com