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.