[BACKEND] Fix divisibility analysis for shift ops

[ThomasRaoux]

Divisibility does not ensure that a value is not 0 therefore we cannot use divisibility as a minimum shifted values.

[Jokeren]

I agree. Any value that's not a power of 2 was wrong...

[lezcano]

I think this is similar to the discussion above but doing 1 << max(log_div_lhs - log_div_rhs, 0) at the end

[Jokeren]

It's a bit different because rhs can be larger than the divisibility of rhs.
We want to get a pessimistic value of the possible divisibility

[Jokeren]

As I mentioned, I'm worried about its a bit too conservative since rhs is usually not 0.
It's indeed tricky...

[Jokeren]

For example, if you have %a << %b, where both a and b are unknown values but with divisibility 4 and 4, then we could estimate the divisibility of the result as 4 << 4.

[Jokeren]

FYI, 0's divisibility is usually the maximum possible power of 2 integer of its type. Maybe we could do special handling here.

[ThomasRaoux]

For example, if you have %a << %b, where both a and b are unknown values but with divisibility 4 and 4, then we could estimate the divisibility of the result as 4 << 4.

I don't understand how that is correct. if %b is 0 then this is not true?

FYI, 0's divisibility is usually the maximum possible power of 2 integer of its type. Maybe we could do special handling here.

I think we would have to fix a bunch of other cases. For instance when we calculate the divisibility of an unknown %a in %a << 1 we will assume divisibility by 2 however the value may still be 0.

[ThomasRaoux]

As I mentioned, I'm worried about its a bit too conservative since rhs is usually not 0.

I agree, I couldn't find a better way that would always be correct

[lezcano]

If I've understood well the definition of divisibility, you want to compute the largest power of two that divides a << b.
If there's no overflow, this is the same as a * 2^b.

int64_t log_div_lhs;
if (lhs.getConstantValue().has_value()) {
    auto lhs_v = *lhs.getConstantValue();
    // Or implement ctz manually or smth
    log_div_lhs = lhs_v ? __builtin_ctz(lhs_v) : 64;
} else {
    log_div_lhs = log2Int(lhs.getDivisibility(dim));
}
int64_t log_div_rhs;
if (rhs.getConstantValue().has_value()) {
    log_div_rhs = *rhs.getConstantValue();
} else {
    log_div_rhs = rhs.getDivisibility(dim);
}
auto shift = int64_t{1} << max(log_div_lhs + log_div_rhs, 64);

or something along this lines (not tested). If the result does not fit on 64 bits... then I guess this still gives you a lower bound I think, as we are just counting trailing zeros and then doing 2 ** # zeros.

[ThomasRaoux]

If I've understood well the definition of divisibility, you want to compute the largest power of two that divides a << b.

Correct

If there's no overflow, this is the same as a * 2^b.

yes

log_div_lhs = log2Int(lhs.getDivisibility(dim));

this assumes that lhs >= lhs.getDivisibility(dim) which I think is not always true as lhs can be 0.

[lezcano]

In that case, if lhs == 0, then I chose 1 << 64 as its divisibility, as @Jokeren proposed in the branch above that. If we have that, then this code would still be correct... but I guess we don't have it?

Edit. After talking with Thomas, the issue here is not the line pointeda bove, but

    log_div_rhs = rhs.getDivisibility(dim);

This breaks in the following example:

%a = call foo() : i32 // -> we know nothing divisibility = 1
%b = mul %a, 2 // ->  divisibility = 2
%c = shl %d, %b 

Here the divisibility of %c is 1 if %a is zero and 2 otherwise.

[ThomasRaoux]

if lhs == 0 then lhsDivisibility should already be MAX_INT, so I believe this case should already work.