[all-commits] [llvm/llvm-project] 2002bb: [LangRef] Revise semantics of intrinsic get.active...

[sjoerdmeijer via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 2002bb487898375d1fc6e43f56e542ecbbce79f8
      https://github.com/llvm/llvm-project/commit/2002bb487898375d1fc6e43f56e542ecbbce79f8
  Author: Sjoerd Meijer <sjoerd.meijer at arm.com>
  Date:   2020-08-25 (Tue, 25 Aug 2020)

  Changed paths:
    M llvm/docs/LangRef.rst

  Log Message:
  -----------
  [LangRef] Revise semantics of intrinsic get.active.lane.mask

A first version of get.active.lane.mask was committed in rG7fb8a40e5220. One of
the main purposes and uses of this intrinsic is to communicate information from
the middle-end to the back-end, but its current definition and semantics make
this actually very difficult. The intrinsic was defined as:

  @llvm.get.active.lane.mask(%IV, %BTC)

where %BTC is the Backedge-Taken Count (variable names are different in the
LangRef spec). This allows to implicitly communicate the loop tripcount, which
can be reconstructed by calculating BTC + 1. But it has been very difficult to
prove that calculating BTC + 1 is safe and doesn't overflow. We need
complicated range and SCEV analysis, and thus the problem is that this
intrinsic isn't really doing what it was supposed to solve. Examples of the
overflow checks that are required in the (ARM) back-end are D79175 and D86074,
which aren't even complete/correct yet.

To solve this problem, we are revising the definitions/semantics for
get.active.lane.mask to avoid all the complicated overflow analysis. This means
that instead of communicating the BTC, we are now using the loop tripcount. Now
using LangRef's variable names, its semantics is changed from:

  icmp ule (%base + i), %n

to:

  icmp ult (%base + i), %n

with %n > 0 and corresponding to the loop tripcount. The intrinsic signature
remains the same.

Differential Revision: https://reviews.llvm.org/D86147