[llvm-dev] [RFC] Enforcing immediate operands for intrinsics

[Eli Friedman via llvm-dev]

Adding an "immarg" attribute makes sense; thanks for working on this.


-Eli


________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Arsenault, Matthew via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Tuesday, February 5, 2019 5:58 AM
To: llvm-dev
Subject: [EXT] [llvm-dev] [RFC] Enforcing immediate operands for intrinsics

Hi,

I would like to solve the longstanding need for a way to indicate which parameters to an intrinsic are required to be immediates. It should be possible to declare in tablegen which parameters must be a trivial constant, or else the IR is invalid.

The verifier could then reject invalid intrinsic calls, so code handling the intrinsics doesn't need to worry about invalid arguments. Currently any code that deals with such intrinsics needs to do type checks on the argument to avoid crashing on valid IR. This isn't done particularly consistently (e.g. see r352904, or the follow-up r353097 for a recent example fix). From the codegen side, we do things like folding invalid intrinsic calls to undef during custom lowering, which is more boilerplate which shouldn't be necessary.

It's also necessary in a few some passes to know it's illegal to replace an argument with a constant. llvm::canReplaceOperandWithVariable currently has to conservatively assume any intrinsic arguments can't be touched.

I have 2 versions of partial implementations of this.

  1.  Uses a new intrinsic query table to return a bitmask of which operands need to be constant
  2.  Introduces a new parameter attribute

My current preference is for option 2. I initially expected to create the table, but then I was creating an uglier way of tracking parameter properties that exactly tracked alongside the attribute handling. It seems cleaner to just put it there, even though it seems a bit overkill and looks slightly strange.

The rules for the attribute will look like:

  *   Only allowed on intrinsics declarations. It is not allowed on an arbitrary function
  *   Not allowed on individual call sites
  *   The parameter must be a trivial constant leaf (i.e. ConstantInt, ConstantFP, or Undef). No aggregates or vectors are allowed
  *   It will be incompatible with all other parameter attributes such as sret or returned

For bikeshedding the name, I'm currently calling the attribute "constant", but I think this is a bad name. It doesn't allow arbitrary constants (such as ConstantExprs), so I think something more like "immarg" 'or "immediate" would be better.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190205/02eb11a3/attachment-0001.html>