[PATCH] D49144: [FunctionAttrs] Infer the speculatable attribute

[Hal Finkel via Phabricator via llvm-commits]

hfinkel created this revision.
hfinkel added reviewers: nlopes, efriedma.
Herald added subscribers: bollu, eraman, nhaehnle, mcrosier.

This patch adds support for inferring the speculatable attribute in the FunctionAttrs pass.

My assumption here is that we need to assume that any loads performed by the function, and any incoming arguments, might be poison. As a result, we can't have any branches, PHIs, or stores (even to local static allocas) - because doing any of these things with poison values is UB. Is that correct?

Given that the functions for which we can infer this must be structurally simple (and can have no stores), and thus likely to be inlined, it's fair to ask why we should do this at all. I have two reasons:

1. Especially when optimizing for code size, we do have large straight-line code functions, called from multiple call sites, which are large enough not to be inlined. It is nevertheless useful to hoist calls to these out of loops, etc.
2. My experience has been that the handling of attributes in LLVM that we don't infer tends to be buggier (because we just have less coverage of the relevant code paths). Thus, I'm in favor of inferring the attributes that we reasonably can.


Repository:
  rL LLVM

https://reviews.llvm.org/D49144

Files:
  lib/Transforms/IPO/FunctionAttrs.cpp
  test/CodeGen/AMDGPU/inline-attr.ll
  test/Transforms/FunctionAttrs/operand-bundles-scc.ll
  test/Transforms/FunctionAttrs/optnone.ll
  test/Transforms/Reassociate/reassociate-deadinst.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D49144.154824.patch
Type: text/x-patch
Size: 6307 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180710/e3d3f0f5/attachment.bin>