[llvm-dev] Semi-automatically updating PHI Nodes

[Marcin Słowik via llvm-dev]

OK, I did some search, and the closest thing I could find was SSAUpdater,
which doesn't apparently have the functionality.
I'm thinking about putting

BasicBlock::updatePHIs(BasicBlock* OldIncoming, BasicBlock* NewIncoming)

function in BB (the other name that comes to my mind is fixPHIs).
While searching, another question came to my mind:
In BB, there is the getFirstNonPHI function. Is there some kind of
requirement for the PHINodes to be placed only at the beginning of BBs? I
had this impression while reading through some parts of SSAUpdater, but I
might have misunderstood that part of the code. IRBuilder seemed to not
care about their placement.

I also had a brief look at MBB and MI and I suppose they could get a
similar treatment, but I don't think there could be much direct code reuse
here, as PHIs are handled differently in both cases.

Cheers,
Marcin

2017-05-16 9:22 GMT+02:00 Marcin Słowik <me at marandil.pl>:

> Hi,
>
> while experimenting with various switch-instruction optimizations, I have
> stumbled upon a trivial task of updating PHI Nodes, when possible
> predecessors could have changed. A simple example would be splitting switch
> into two parts:
>
> switch (a) {
>   default: BB0;
>   case 0: BB0;
>   case 1: BB1;
>   case 2: BB2;
>   case 19: BB0;
>   case 20: BB1;
>   case 21: BB2;
> }
>
> changed into:
>
> if (0 <= a <=2) {
>   switch (a) {
>     default: unreachable;
>     case 0: BB0;
>     case 1: BB1;
>     case 2: BB2;
>   }
> } else {
>   switch (a-19) {
>     default: BB0;
>     case 0: BB0;
>     case 1: BB1;
>     case 2: BB2;
>   }
> }
>
> Now, if the blocks contained any PHI Nodes, their predecessors are no
> longer valid, since we had to include new BBs for the switch instructions
> inside the virtual if/else.
> I have a rather straightforward function that scans BB for PHINode
> instructions and given two additional BBs: OldIncoming and NewIncoming
> checks whether OldIncoming is still a possible predecessor (it may happen
> in many cases) and based on this either replaces all PHINode incomings from
> OldIncoming to NewIncoming, or adds NewIncoming with the same value as in
> case of OldIncoming.
>
> I currently have 3 questions:
> 1) Is this functionality already implemented somewhere in the LLVM (on IR
> level)?
> 2) If not 1), what would be the best place to put it? BasicBlock class?
> 3) If not 1), should I submit a patch?
>
> Ad. 2) I currently use it as a part of my pass, but I see other potential
> uses in other parts of the code.
>
> Best Regards,
> Marcin Slowik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170518/fdffaa8a/attachment.html>