> 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
