Switch-case synthesis about souper

[fvrmatteo]

I used an ugly trick to convert the switch into a cascade of icmp + select instructions and now Souper is able to synthesize the provided example (I also successfully tested the same example with the full i8 condition range 0-255):

define i8 @src(i8 %0) {
entry:
  %icmp_0 = icmp eq i8 %0, 0
  %sele_0 = select i1 %icmp_0, i8 1, i8 0
  %icmp_1 = icmp eq i8 %0, 1
  %sele_1 = select i1 %icmp_1, i8 0, i8 %sele_0
  %icmp_2 = icmp eq i8 %0, 2
  %sele_2 = select i1 %icmp_2, i8 0, i8 %sele_1
  %icmp_3 = icmp eq i8 %0, 3
  %sele_3 = select i1 %icmp_3, i8 0, i8 %sele_2
  %icmp_4 = icmp eq i8 %0, 4
  %sele_4 = select i1 %icmp_4, i8 0, i8 %sele_3
  %icmp_5 = icmp eq i8 %0, 5
  %sele_5 = select i1 %icmp_5, i8 0, i8 %sele_4
  %icmp_6 = icmp eq i8 %0, 6
  %sele_6 = select i1 %icmp_6, i8 0, i8 %sele_5
  %icmp_7 = icmp eq i8 %0, 7
  %sele_7 = select i1 %icmp_7, i8 0, i8 %sele_6
  %icmp_8 = icmp eq i8 %0, 8
  %sele_8 = select i1 %icmp_8, i8 0, i8 %sele_7
  %icmp_9 = icmp eq i8 %0, 9
  %sele_9 = select i1 %icmp_9, i8 0, i8 %sele_8
  ret i8 %sele_9
}

This is theoretically doable for any switch, but it creates a dependency chain on the instructions that wasn't original there. The result is the following:

define i8 @src(i8 %0) {
entry:
  %icmp_0 = icmp eq i8 %0, 0
  %1 = zext i1 %icmp_0 to i8
  ret i8 %1
}

Obviously I'm still wondering if Souper can handle the switch without the need to convert it, but decided to post a solution if anyone is going to look into a similar example in the future.

[regehr]

hi! sorry none of us responded earlier. hopefully this issue is now fixed via #843

[fvrmatteo]

No hurry, glad to see Souper is still alive, I keep using it for many sub-tasks!

I tested it today and I can confirm the patch solves the issue if the enumerative synthesis is used, even though it's mandatory to specify --souper-enumerative-synthesis-ignore-cost, which is suboptimal, but it's my understanding the phi cost will need to be reworked somehow.

Is there any plan to support the same with the --souper-infer-inst option? I still find the component-based synthesis to beat the enumerative synthesis in many synthesis tasks, but I also noticed all the improvements are more enumerative-synthesis related.

[regehr]

hi Matteo, just a quick heads up that I just changed -souper-infer-inst to -souper-use-cegis since the old option was pretty confusing.

I'd be interested to hear more about your experience comparing these two algotihms. my experience is that CEGIS indeed performs better on hand-written tests, but that the enunerator greatly wins in real applications where the left-hand-sides being optimized are large and contain many instructions that are not really involved with the optimization. if you see examples where large LHSs are optimized better by CEGIS than by the enumerator, please let us know. I'll leave this PR open for a few days in case we want to chat more about this, then I'll close

[fvrmatteo]

Thanks John for the heads up!

I have some sliced IR files with quite big LHSs that are synthesized properly by CEGIS (given a possible set of feasible components as input) and I've never managed to get them to work with the enumerator. The root node is synthesized to approximately 5/6 instructions.

This evening I can collect them, retest them with the newest changes (even reducing the set of components used by the enumerator) and send them over to you if you'd like to give it a try. The only issue is that I'd like to keep them private for now. Can I send them somewhere safe? If not, I'll eventually come up with similar tests that show the same behaviour (if possible).

[regehr]

Hi Matteo, I'd love to look at these if you don't mind sharing. We won't share them outside of my group. If you want, email me at [email protected]. Thanks!