[PATCH] Trap values persist through memory and cause undefined switch behavior

Clarify that a trap value stored to memory stays a trap value after it's loaded back into a register, even though the side effect (for example, from a volatile store) is still undef.

Also extend trap values to cause undefined behavior when they control a conditional branch or switch. This is important for switches because it can allow the optimizer to change the default branch to unreachable. If a trap switch argument merely acted like undef, the optimizers couldn't introduce a branch to unreachable.  I'm less sure that br(trap) needs to be unreachable, but it seems nicely symmetric.

[chandlerc, 2010-04-25 07:32:25]

http://codereview.appspot.com/946042/diff/1/2
File docs/LangRef.html (right):

http://codereview.appspot.com/946042/diff/1/2#newcode2331
docs/LangRef.html:2331: <p>A <a href="#i_br">br</a> or <a
href="#i_switch">switch</a> instruction whose
This paragraph is now separating the "For example" in the next paragraph from
the statement for which it is providing an example. We also now have two "for
example" sequences for the previous paragraph.

http://codereview.appspot.com/946042/diff/1/2#newcode2332
docs/LangRef.html:2332: control operand is a trap value causes undefined
behavior.</p>
The next paragraph says 'produces undefined behavior', and the first 'results in
undefined behavior'. Perhaps I'm a pedant, but the inconsistency bothers me. ;]

[Jeffrey Yasskin, 2010-04-25 07:49:07]

We noticed this when designing the concurrency memory model, but I think it's a
needed refinement regardless.