Re: simplify_subreg issues

[Geoff Keating <geoffk at geoffk dot org>]

> Cc: gcc@gcc.gnu.org
> X-URL: http://www.codesourcery.com
> Organization: CodeSourcery, LLC
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Mon, 11 Jun 2001 19:09:07 -0700
> X-Dispatcher: imput version 990425(IM115)
> 
> 
> A patch of mine is triggering failures in builtin-complex-1.c on x86.
> The test code is:
> 
>   extern float _Complex conjf (float _Complex);
> 
>   int
>   main (void)
>   {
>     volatile float _Complex fc = 1.0F + 2.0iF;
>     if (conjf (fc) != 1.0F - 2.0iF)
>       abort ();
>   }
> 
> Before my patch, we did not mark the `MEM' for `fc' as MEM_VOLATILE_P.
> My patch corrected this bug.
> 
> However, we now generate:
> 
>   (insn 13 11 0 (set (subreg:SF (mem/v/f:SC (plus:SI (reg/f:SI 54 virtual-stack-vars)
> 		      (const_int -8 [0xfffffff8])) 0) 4)
> 	  (mem/u/f:SF (const:SI (plus:SI (symbol_ref:SI ("*.LC0"))
> 		      (const_int 4 [0x4]))) 0)) -1 (nil)
>       (nil))
> 
> Later we abort in disgust on the SUBREG of a MEM.
>  
> To reproduce this bug, look at the mainline -- not the branch.  Set a
> breakpoint here, in emit_move_insn_1:
> 
>       /* Don't split destination if it is a stack push.  */
>       int stack = push_operand (x, GET_MODE (x));
> 
> Look at how `imagpart_x' is computed a while down.  The call to
> gen_imagpart calls gen_highpart calls simplify_gen_subreg calls
> simplify_subreg.
> 
> This code in simplify_subreg:
> 
>   if (GET_CODE (op) == MEM
>       && ! mode_dependent_address_p (XEXP (op, 0))
>       && ! MEM_VOLATILE_P (op)
>       && GET_MODE_SIZE (outermode) <= GET_MODE_SIZE (GET_MODE (op)))
>     {
>       rtx new;
> 
>       new = gen_rtx_MEM (outermode, plus_constant (XEXP (op, 0), byte));
>       MEM_COPY_ATTRIBUTES (new, op);
>       return new;
>     }
> 
> no longer fires, due to the volatility.  So, we make a real SUBREG.
> 
> I don't know how to fix this.  We can revert my patch, but that will
> reintroduce the bugs it was trying to fix, so I would be happier if we
> could figure out to fix the real problem.

The underlying problem is that 'volatile' doesn't make sense in
conjunction with 'complex'.  We can't do complex loads or stores.  So,
actually in this case the optimisation would be correct, because what
we want to have is

(set (mem/v:SF ...) ...)

-- 
- Geoffrey Keating <geoffk@geoffk.org>