This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH 0/3] Fixing expansion of misaligned MEM_REFs on strict-alignment targets
- From: Martin Jambor <mjambor at suse dot cz>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Richard Guenther <rguenther at suse dot de>
- Date: Mon, 12 Mar 2012 15:09:01 +0100
- Subject: [PATCH 0/3] Fixing expansion of misaligned MEM_REFs on strict-alignment targets
Hi,
this is another iteration of my effort to fix expansion of misaligned
memory accesses on strict-alignment platforms (which was suggested by
Richi in http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00931.html, my
previous attempt was posted as
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01378.html).
Most importantly, I realized that the previous second patch was wrong
because store_field, which is called in the same code path, itself
calls store_bit_field just as I would. This then lead to unnecessary
tripling of the code handling misalignment in some cases. The only
problem with removing it was that this code path calls expand_normal
to expand the base of the MEM_REF and that means the third patch to
expand_expr_real_1 kicks in, extracts the value into a register which
is returned to expand_assignment, the existing code then writes the
value to a register but never stores it into memory.
I came to conclusion that in this case expand_assignment should expand
the MEM_REF itself rather passing it to expand_normal, just as it
already does when expanding naked MEM_REF and introduced a new second
patch doing just that. Because very similar code would now be twice
in expand_assignment and once in expand_expr_real_1, I introduced a
new function expanding it in all of these three cases (more details on
that in the email with the actual patch).
I have successfully bootstrapped the first patch and all three patches
combined patch on x86_64-linux, i686-linux, ia64-linux (without Ada)
and sparc64-linux (without Java). I will test the second on its own
too, I have just not done that yet.
Thanks in advance for any comments,
Martin