[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Sep 25 19:42:07 2003 
Subject:Re: bug in Pop-11/Poplog back-end compiler ? 
From:David Young 
Volume-ID:1030925.01 

Further information about the "not" problem, in case anyone is thinking
about it. Another manifestation is:

	procedure();
	    not(111 or 222); goto l;
	l: endprocedure() =>
	** 111

The relevant VM code is

     PUSHQ   111
     OR      label_664
     PUSHQ   222
  label_664:
     CALL    not
     GOTO    l
  l:

which is more or less shared with all the earlier examples, which all
generate a GOTO after the call to not.

> I have no idea what's going on. If anyone wants to investigate it
> is probably a bug in one of these files
>
> 	$popsrc/vm*
>
> Perhaps in
> 	$popsrc/vm_plant.p
>
> Maybe some interaction between sysIFSO and sysAND sysOR

My guess now is $popsrc/vm_conspdr.p, somewhere in Optimise_conditions
or Optimise_clist_tl. It could be, for example, that the GOTO is getting
treated as a conditional jump whose logic can be reversed if the "not"
is removed. However having looked at the code for some time I can't spot
exactly what's wrong, and I've no way of playing with system code to
debug it. It's complex since the bug needs the OR (or AND) before and
the GOTO after to manifest itself.

The view that optimisation of the call to "not" is central is supported
by the fact that you can turn the bug off by doing "lvars mynot = not;"
and then calling "mynot". That switches off the first stage of
optimisation, which is to replace the call to "not" with a specific
inline instruction, which is then open to further optimisation (e.g. by
removing it and reversing the sense of a following conditional jump).

Entirely incidentally, and rising to bait:

> Whatever the bug is, it must be very old and it's amazing that it
> was never previously discovered/reported, not even by people who
> like these optimising constructs....

I am certainly one of the people who like the optimising constructs, if
by that you mean that "true or foo(x)" doesn't actually call foo. In
fact I'd really hate it if that wasn't the case - Matlab has recently
switched to these semantics and I could barely tolerate it before it
did. The problem here is the attempt to further optimise logical
expressions and conditional constructions, which is a good thing as long
as it's all correct, and a disaster if there's an error like this one.

David