[llvm-dev] Semi-automatically updating PHI Nodes

Marcin SÅ‚owik via llvm-dev llvm-dev at lists.llvm.org
Tue May 16 00:22:20 PDT 2017


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/20170516/3e7e7558/attachment-0001.html>


More information about the llvm-dev mailing list