Asm volatile causing performance regressions on ARM

[Eric Botcazou]

> I think part of the problem is that some parts of GCC (like the one you
> noted) are far more conservative than others.  E.g. take:
> 
>   void foo (int x, int *y)
>   {
>     y[0] = x + 1;
>     asm volatile ("# asm");
>     y[1] = x + 1;
>   }
> 
> The extra-paranoid check you pointed out means that we assume that
> x + 1 is no longer available after the asm for rtx-level CSE, but take
> the opposite view for tree-level CSE, which happily optimises away the
> second +.

Right, I think that it should be possible to (partially) achieve this for RTL 
CSE without totally gettting rid of the invalidation.

> One of the big grey areas is what should happen for floating-point ops
> that depend on the current rounding mode.  That isn't really modelled
> properly yet though.  Again, it affects calls as well as volatile asms.

There is an explicit comment about this in the scheduler:

    case ASM_OPERANDS:
    case ASM_INPUT:
      {
	/* Traditional and volatile asm instructions must be considered to use
	   and clobber all hard registers, all pseudo-registers and all of
	   memory.  So must TRAP_IF and UNSPEC_VOLATILE operations.

	   Consider for instance a volatile asm that changes the fpu rounding
	   mode.  An insn should not be moved across this even if it only uses
	   pseudo-regs because it might give an incorrectly rounded result.  */
	if (code != ASM_OPERANDS || MEM_VOLATILE_P (x))
	  reg_pending_barrier = TRUE_BARRIER;

-- 
Eric Botcazou