Change Details

In D79100, the vectoriser is taught to emit IR intrinsic @llvm.set.loop.elements if a loop is vectorised and tail-folding is applied. This value corresponds to the number of data elements processed by the loop, which is what we need in the tail-predication pass. Now we pick up this intrinsic the number of elements, which simplifies the pattern matching we were doing to find this value. I have not yet removed the pattern matching because that would require changing of a lot of tests. Thus, for now, the intrinsic and pattern matching coexist together, but as a follow up we probably want to remove this.

With D79100 we can rely on `@llvm.get.active.lane.mask()` that is generated by the vectoriser to get the number of elements processed by the loop, which is required to set up tail-predication. This intrinsic generates the predicate for the masked loads/stores, and consumes the Backedge Taken Count (BTC) as its second argument; we can now simply extract and use that to set up tail-predication.

In D79100, the vectoriser is taught to emit IR intrinsic @llvm.set.loop.elements if a loop is vectorised and tail-folding is applied. This value corresponds to the number of data elements processed by the loop, which is what we need in the tail-predication pass. Now we pick up this intrinsic the number of elements, which simplifies the pattern matching we were doing to find this value. I have not yet removed the pattern matching because that would require changing of a lot of tests.With D79100 we can rely on `@llvm.get.active.lane.mask()` that is generated by the vectoriser to get the number of elements processed by the loop, Thus,which is required to set up tail-predication. for nowThis intrinsic generates the predicate for the masked loads/stores, the intrinsic and pattern matching coexist together,and consumes the Backedge Taken Count (BTC) as its second argument; but as a follow up we probably wanwe can now simply extract and use that to remove thisset up tail-predication.