Re: Should dead stores which could trap be deleted?

[Jeffrey A Law <law at cygnus dot com>]

  In message <199908070132.VAA24676@jwlab.FEITH.COM>you write:
  > Can a generalization be made that gcc is free to perform optimizations
  > which eliminates instructions that can trap so long that the resulting
  > code produces the right answer in any situation where the trap would
  > not have occurred?  Or is each situation unique and a healthy dose
  > of common sense required?
There are some generalities you can use.  You can always delete unreachable
code, no matter what that code might do, it can never be executed.

During CSE types of optimizations you can delete a redundant instruction which
might trap -- why?  Because if it is redundant, then the earlier instruction
would have trapped.

Things get a little more iffy when deleting dead code.  But I think we are 
OK deleting code which (according to ANSI/ISO) is undefined and the only
possible side effect of that code is to trap.  So removal of a divide whose
result is unused is (IMHO) OK; similarly removal of an load instruction whose
result is never used is OK.

Things get even more iffy when considering motion of insns which might trap.
Consider hoisting a loop invariant divide out of a loop.  I think GCC's
behavior in this case is rather inconsistent -- I *think* we disallow
hoisting of division out of loops, but allow hoisting of memory references.

Now consider something like lazy code motion which combines aspects of both
cse and loop optimizations.  It looks at loops as simply multiple paths to
the same location -- so if there is an instruction which would compute the
same value on the two paths, it is hoisted to an earlier location in the cfg
(but nothing should be moved before the point at which we know we will
eventually execute the loop for correctness purposes).  What do we do with
memory references, division, etc then???

jeff