Feature request: support a conditional move expression in LLIL

[cfircohen]

In binja-hexagon I'm translating instruction semantics from C to LLIL, see design doc for details.

One thing that I've found frustrating is translating C's ternary expressions ("y = c ? a : b") without using LLIL's if-statements. For instance, this is how I ended up implementing MAX(A,B) (((A) > (B)) ? (A) : (B)):

max = (a >= b) * a + (a < b) * b

Or fABS(A) (((A) < 0) ? (-(A)) : (A)):

abs = (1 - 2*(a < 0)) * a

I think it would be really useful to have a conditional move ExprId in LLIL.

[plafosse]

Though this would be nice for those writing architecture plugins this would complicate backend analysis more than we'd like. So unfortunately we're not likely going to be implementing this. Thanks for the suggestion though :)

[cfircohen]

That's a fair trade-off.

Maybe we can come up with some syntactic sugar for cmove expressions - have a utility function in BN API that implements cmove expressions using if-statements, goto-s and scoped temporary registers. The language doesn't need to change.

[noopwafel]

Is the 'intended' way of implementing such semantics to use branches? I'm working on lifting for a similar architecture and some functions end up extremely branch-heavy in the absence of a ternary/select/cmov instruction.

[psifertex]

Have you looked at https://github.com/Vector35/arch-x86/blob/master/il.cpp#L441-L482 ?

[noopwafel]

yes, I asked on Slack about the double gotos, which I see are gone now :) What I mean is: as cfircohen said, a lot of these type of instructions can also be lifted as (convoluted) arithmetic. Is the intention that architecture plugins should lift these cmov-style (i.e. with branches) and BN's analysis will (someday) cope with the data flow, or is it perhaps better to just use the arithmetic, which tends to give much more readable results right now?