Google
 

Trailing-Edge - PDP-10 Archives - bb-jr93j-bb - 7,6/ap022/defpt.c22
There are 3 other files named defpt.c22 in the archive. Click here to see a list.
 REP 2/1	;22C1
	!COPYRIGHT (c) DIGITAL EQUIPMENT CORPORATION 1972, 1987
 WIT
	!COPYRIGHT (c) DIGITAL EQUIPMENT CORPORATION 1972, 1989
 REP 24/1	;22C2
	GLOBAL BIND DEFPTV = #11^24 + 0^18 + #4517;	! Version Date:	4-Oct-85
 WIT
	GLOBAL BIND DEFPTV = #11^24 + 0^18 + #4606;	! Version Date:	12-Jan-89
 INS 182/1	;22C3
	*****	Begin Version 11A *****

	4606	DCE	12-Jan-89
		In SETIT, if we are attempting to set a potential definition point
		on a statement that might move (like an optimizer generated assignment
		statement), then also set it on the next available statement which is
		known not to move (if any).  This prevents moving code too far back
		when the definition points move.

 REP 29/11	;22C4
				P[ACC]_SETBIT(.P[ACC],.I);
 WIT
	!**;[4606], SETIT @6154, DEC,12-Jan-89
	%4606%		BEGIN
				P[ACC]_SETBIT(.P[ACC],.I);
	%4606%			IF .P[SRCISN] EQL 0 THEN ! Possible problems
	%4606%			IF .P[SRCID] EQL ASGNID THEN ! Likely problems
	![4606]	If we have just marked an optimizer generated assignment
	![4606]	statement as the definition point for the variable, we may run into
	![4606]	problems later.  An expression may pick up this statement as the
	![4606]	definition point for a variable, then the whole assignment statement
	![4606]	may get moved backwards by the optimizer, and finally the expression
	![4606]	using this definition point may get selected to move.  If that happens,
	![4606]	then the expression potentially gets moved to the wrong place (back
	![4606]	with the moving assignment statement).  We need to prevent this.  So
	![4606]	the following code attempts to mark the next statement which is NOT
	![4606]	an optimizer generated assignment statement with the ACC bit as well.
	![4606]	This will trick the definition point algorithm into thinking that the
	![4606]	variable gets defined somewhat later.  This is OK, since the optimizer
	![4606]	generated assignment statement in no way conflicts with the variable
	![4606]	definition, so moving the definition point should not hurt.
	%[4606]%			BEGIN
	%[4606]%				LOCAL P2;
	%[4606]%				MAP PHAZ2 P2;
	%[4606]%
	%[4606]%				P2 = .P[SRCLINK];
	%[4606]%				WHILE .P2 NEQ 0 DO
	%[4606]%				IF .P2[SRCOPT] EQL 0 THEN P2 = .P2[SRCLINK]
	%[4606]%				ELSE	! Check for another problem statement
	%[4606]%				IF (.P2[SRCISN] EQL 0) AND (.P2[SRCID] EQL ASGNID)
	%[4606]%				THEN P2 = .P2[SRCLINK]
	%[4606]%				ELSE ! Mark variable as defined here too
	%[4606]%				BEGIN
	%[4606]%					P2[ACC] = SETBIT(.P[ACC],.I);
	%[4606]%					RETURN
	%[4606]%				END;
	%[4606]%			END;
	%[4606]%		END;
 SUM 232249