This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-4.3.0/ppc32 inline assembly produces bad code
- From: Daniel Jacobowitz <drow at false dot org>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Till Straumann <strauman at slac dot stanford dot edu>, gcc at gcc dot gnu dot org, RTEMS List <rtems-users at rtems dot com>
- Date: Mon, 31 Mar 2008 08:49:17 -0400
- Subject: Re: gcc-4.3.0/ppc32 inline assembly produces bad code
- References: <47EA78E1.2040100@slac.stanford.edu> <jeve33b68u.fsf@sykes.suse.de>
On Mon, Mar 31, 2008 at 11:19:29AM +0200, Andreas Schwab wrote:
> Till Straumann <strauman@slac.stanford.edu> writes:
>
> > /* Powerpc I/O barrier instruction */
> > #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); }
> > while (0)
>
> Looking closer, your asm statement has a bug. The "m" constraint can
> match memory addresses with side effects (auto inc/dec), but the insn
> does not carry out that side effect. On powerpc the side effect must be
> encoded through the update form of the load/store insns. If you don't
> use a load or store insn with the operand the you must use the "o"
> constraint to avoid the side effect.
Should asm "m" be required to carry out the side effect? It seems
like this would break every end-user use of inline assembly; you'd
never know whether a memory argument should be used for lwz or lwzu.
I think treating =m as generating the output address is unhelpful.
--
Daniel Jacobowitz
CodeSourcery