Path: utzoo!attcan!uunet!husc6!mailrus!ames!zodiac!joyce!sri-unix!garth!smryan From: smryan@garth.UUCP (Steven Ryan) Newsgroups: comp.arch Subject: Re: getting rid of branches Message-ID: <880@garth.UUCP> Date: 5 Jul 88 22:18:38 GMT References: <28200173@urbsdc> <53161@ti-csl.CSNET> <18830@cornell.UUCP> Reply-To: smryan@garth.UUCP (Steven Ryan) Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 30 > ex1 = .true. > do 100 i = 1, 100 > if (ex1) statement1 <-----(1) > if (ex1) ex1 = .not. x(i) <-----(2) > if (ex1) statement2 > 100 continue > if (.not. ex1) goto 200 > statement3 > 200 statement4 > >the do loop can now be vectorized. Actually, I don't think so: the reference to ex1 in (1) is before a definition in (2), ex1 is recursive. I worked on something like, provided the control statements were forward jumps only and did not exit the loop. The forward jump restriction was to ensure the flow was acyclic and to ensure guards were computed before their use without having to rearrange the loop. Each transfer of control had an associated guard bit vector. The transfer predicate was vectorised and anded with the guard on the transfer of control. Labels orred together all guard vectors leading to them. Guards were associated with assignment statement sequences. (Rather a guard was establised by control statements and labels and was retained until the next.) The control structures can form an loop within the do loop, but this requires a bit of cleverness and is of limited utility. Multiexit loops either have recursive guards are must buffer assignments and discard the results of the excess iterations.