This is the mail archive of the
mailing list for the GCC project.
Re: expand_expr tweaks to fix PR57134
- From: Alan Modra <amodra at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 13 Sep 2013 12:37:20 +0930
- Subject: Re: expand_expr tweaks to fix PR57134
- Authentication-results: sourceware.org; auth=none
- References: <20130612024834 dot GY6878 at bubble dot grove dot modra dot org> <CAFiYyc243r-89eAsAJtNwm3wX=_F4UFL2Y0DHBgopxVh1tuLrA at mail dot gmail dot com> <20130614083832 dot GK21523 at bubble dot grove dot modra dot org> <CAFiYyc026=xvHRJJPyNu9aZKdhPF0psTRDYNhfEkTUAMf+87Jg at mail dot gmail dot com>
This is a followup to
which is still lacking an OK. Apologies for dropping this patch on
* stmt.c (expand_asm_operands): Call expand_expr with
EXPAND_MEMORY for output operands that disallow regs. Don't
use EXPAND_WRITE on inout operands.
--- gcc/stmt.c (revision 202428)
+++ gcc/stmt.c (working copy)
@@ -806,7 +806,10 @@ expand_asm_operands (tree string, tree outputs, tr
|| ! allows_reg
- op = expand_expr (val, NULL_RTX, VOIDmode, EXPAND_WRITE);
+ op = expand_expr (val, NULL_RTX, VOIDmode,
+ !allows_reg ? EXPAND_MEMORY
+ : !is_inout ? EXPAND_WRITE
+ : EXPAND_NORMAL);
if (MEM_P (op))
op = validize_mem (op);
On Fri, Jun 14, 2013 at 11:38:58AM +0200, Richard Biener wrote:
> On Fri, Jun 14, 2013 at 10:38 AM, Alan Modra <firstname.lastname@example.org> wrote:
> > On Thu, Jun 13, 2013 at 10:45:38AM +0200, Richard Biener wrote:
> >> On Wed, Jun 12, 2013 at 4:48 AM, Alan Modra <email@example.com> wrote:
> >> > The following patch fixes PR57134 by
> >> > a) excluding bitfield expansion when EXPAND_MEMORY, and
> >> > b) passing down the EXPAND_MEMORY modifier in a couple of places where
> >> > this does not currently happen on recursive calls to expand_expr().
> >> I suppose it also fixes PR57586 which looks similar?
> > Not completely. It cures the ICE, but you still get "output number 0
> > not directly addressable". The reason being that expand_asm_operands
> > isn't asking for a mem. It should I guess, and also not specify
> > EXPAND_WRITE on an inout parameter. Bootstrapped and regression
> > tested powerpc64-linux.
> It looks reasonable to me, but I'm not too familiar with EXPAND_MEMORY
> vs. EXPAND_WRITE.
For the expr.h comment
"EXPAND_WRITE means we are only going to write to the resulting rtx."
So fairly obviously we shouldn't use that with inout asm args.
> Btw, I wonder if for strict-alignment targets asm()s can expect "aligned"
> memory if they request an asm input with "m"? Thus, do we eventually
> have to copy a known unaligned mem to aligned scratch memory before
> passing it to a "m" input? Do we maybe have to do the same even for
> "m" outputs? Or is this all simply undefined and asm()s have to handle
> arbitrary alignment of memory operands (well, those that appear
> at runtime, of course).
I'm sure the kernel people would rather *not* have copies to scratch
memory. The testcase in pr57586 was derived from kernel code that
munges pointers. A testcase that better shows what is going on,
probably from the same kernel code, is here
(The pointer munging is what causes gcc to lose track of alignment.)
Australia Development Lab, IBM