(original) (raw)


On 2/5/19 12:55 PM, Eli Friedman via llvm-dev wrote:

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


+1


-Hal



-Eli


From: llvm-dev on behalf of Arsenault, Matthew via llvm-dev
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


\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
LLVM Developers mailing list  
llvm-dev@lists.llvm.org  
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev  

--   
Hal Finkel  
Lead, Compiler Technology and Programming Languages  
Leadership Computing Facility  
Argonne National Laboratory