From: anton@mips.complang.tuwien.ac.at   
      
   Thomas Koenig writes:   
   >An extra feature: When using GOTO variable, you can also supply a   
   >list of labels that it should jump to; if the jump target is not   
   >in the list, the GOTO variable is illegal.   
      
   The benefit I see from that is that data-flow analysis must only   
   consider the control flows from the assigned goto to these targets and   
   not to all assigned labels (in contrast to labels-as-values), and   
   conversely, if every assigned goto has such a list, data-flow analysis   
   knows more precisely which gotos can actually jump to a given label.   
      
   This would make a small difference in Gforth since 0.6, which has   
   introduced hybrid direc/indirect-threaded code, and where some goto *   
   are for indirect-threaded dispatches, and some labels are only reached   
   from these goto * instances, and a certain variable is only alive   
   across these jumps. GNU C does not have this option, so what we did   
   instead is to kill the variable right before all the gotos that do not   
   jump to these labels.   
      
   It might also help with static stack caching: There are stack states   
   with 0-n stack items in registers, and a particular VM instruction   
   code snippet starts in a particular state (say, 2 stack items in a   
   register) and ends with another state S (say, 1 stack item in a   
   register). It will jump to code that expects the same state S. All   
   variables that contain stack items beyond what S has are dead at that   
   point. If we could tell that the goto * from state S only goes to   
   targets in state S, the data-flow analysis could determine that.   
   Instead, what we do is to kill these additional variables in a subset   
   of uses. When we tried to kill them at all uses, the quality of the   
   code produced by gcc deteriorated significantly.   
      
   This variable-killing happens by having empty asm statements that   
   claim to write to these variables, so if this is used incorrectly, the   
   produced code will be incorrect. So the benefit of this assigned-goto   
   feature would be to replace a dangerous feature with another dangerous   
   one: if you fail to list all the jumped-to labels, the data-flow   
   analysis would be wrong, too. It seems more elegant to describe the   
   actual control flow, and then let the data-flow analysis do its work   
   than the heavy-handed direct influence on the data-flow analysis that   
   our variable-killing does.   
      
   - anton   
   --   
   'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'   
    Mitch Alsup,    
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|