Alias scopes bug post-ISEL

Code Generation
1

Hi,

I found that with latest clang version, this bug was fixed:
https://bugs.llvm.org/show_bug.cgi?id=39282
Later on some other passes got fixes to similar issues.

However, my problem is after instruction selection, when performing loop unrolling on the machine IR or other optimizations that may duplicate/move instructions.

Is there any way to avoid a similar bug in such passes?

Even for something simple like unrolling Machine-IR loops it doesn’t look like there is an easy solution, as the llvm.experimental.noalias.scope.decl is eliminated in ISEL, and nothing seems to be done to retain the lost information in any way.

This causes bugs in some of our Machine-IR optimizations that are very similar to bug 39282 linked above.

Any ideas?

Thanks!

Gal

2

You can always just throw away the aliasing metadata on the relevant MachineMemOperands. Or throw away the MachineMemOperands altogether.

If you really need to preserve the exact aliasing scopes after you unroll a MachineInstr loop, for the sake of later optimizations, I guess you’d need to introduce a pseudo-instruction to represent llvm.experimental.noalias.scope.decl().

3

Throwing away would hurt performance too badly on scenarios that didn’t have a bug to begin with. Even throwing it away specifically on scenarios that could cause wrong behavior (which isn’t trivial) might cause worse performance in some cases that were working fine before.

I thought about the pseudo instruction solution, but I suspect that in order to keep its information valid, many optimizations (mostly scheduling or anything that may re-order instructions) will need to be severely limited. Or am I missing something?

As the bug is very rare, I was hoping for a more focused solution that wouldn’t hurt the performance on the grand majority of scenarios that are working fine.

4

I don’t think you need to treat llvm.experimental.noalias.scope.decl as a scheduling barrier. The only semantics are the set of instructions associated with it using metadata. Like LangRef notes, the interesting thing is what happens when it’s duplicated.

You don’t necessarily have to represent it as a pseduo-instruction, though. That was the most convenient way in LLVM IR, but MIR representation is more flexible, so maybe you can do something else? Not sure what that would look like, though; you still need to associate it with control flow somehow.

1 Like