[WIP] Build assume from call

[Tyker]

Summary

this is part of the implementation of http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html

this patch gives the basis of building an assume to preserve all information from an instruction and add support for building an assume that preserve the information from a call.

[jdoerfert]

Some high-level comments, haven't gone through it in detail

llvm/include/llvm/Transforms/Utils/AssumeBuilder.h

31

We need to add documentation and probably change the variable/function names to match the convention.

llvm/lib/IR/Attributes.cpp

201

This can probably go in the other patch, right?

llvm/lib/Transforms/Utils/AssumeBuilder.cpp

19

Why do we need the detail_assume_builder namespace at all?

25

Since this is not always sound I am unsure what it would be used for.
Instead, you can look for assumes in the vicinity, probably always prior to the current position, but with consideration of willreturn and nounwind.

llvm/test/Transforms/Util/assume-builder.ll

56

Why is the address space explicit here?

---

I'm unsure if we need to preserve function (scope) attributes, at least until we get scoped assumes that actually scope the information, e.g. after inlining.

[Tyker]

llvm/include/llvm/Transforms/Utils/AssumeBuilder.h

31

yeah. i will fix that.

llvm/lib/IR/Attributes.cpp

201

getNameFromAttrKind is used in the to build the assume. but it could be moved in the previous patch.

llvm/lib/Transforms/Utils/AssumeBuilder.cpp

19

it can be probably be removed. but i consider builderState a "common" name and the builderState shouldn't be used outside of AssumeBuilder.*

25

it is just intended to be used for testing of the range version of the function.
the pass doesn't insert instruction it just output what it would look like if it did.

i made it look the same so i can use python scripts to update tests. but instruction are not inserted.

llvm/test/Transforms/Util/assume-builder.ll

56

Why is the address space explicit here?

i think it is because the llvm.assume are not inserted but printed as if they where. so the printing option may be different.

I'm unsure if we need to preserve function (scope) attributes, at least until we get scoped assumes that actually scope the information, e.g. after inlining.

by function (scope) attributes do you mean attributes on the argument of the declaration of a function ?
if so i think they can give us information about the call site. but if we can assume they are always propagated to the callsite we can skip them.

[jdoerfert]

llvm/lib/Transforms/Utils/AssumeBuilder.cpp

19

Then move it into the cpp file and only declare functions that deal with its members in the header.

25

Oh, why do we need a printer if we could actually do the tranformation? We can use unit tests to test this.

llvm/test/Transforms/Util/assume-builder.ll

56

Yes the function declaration attributes, e.g., nounwind.

The use case I have in mind would be to create an llvm.assume if you are about to move/delete/modify the call.
Having information about the arguments helps then, having information about the function does not, except if we would have a scope in which we know the information is good. I mean, if you inline a call site with an attribute XYZ but these attributes are all "scoped". Knowing XYZ holds at a single location is not helpful, at least I can't think of many function attributes for which this would be helpful in a non-scoped case.

[Tyker]

i changed the pass and the test to actually perform the transformation. it is less confusing this way.

llvm/test/Transforms/Util/assume-builder.ll

56

i think most function attributes aren't useful. but some are for example cold if we hit a call to a function marked cold, this is useful.
and we can't differentiate between useful and useless ones.

[jdoerfert]

llvm/include/llvm/Transforms/Utils/AssumeBuilder.h

24

Mention that the instruction is not inserted into a basic block.

31

all but the run method don't seem to be needed (if this is a struct).

llvm/lib/Transforms/Utils/AssumeBuilder.cpp

25

I usually favor structs with named members over tuples. It makes especially the uses way more readable, e.g., it says Elem.Name not Elem.get<0>().

29

No need for Builder, this is a member. Same elsewhere.

44

getCalledFunction might be null.

45

don't use these constants but AttributeList::ReturnIndex, AttributeList::FunctionIndex, AttributeList::FirstArgIndex.

55

Early exist are preferred:

if (XXX.empty())
  return nullptr;
/// other code

59

I'd prefer the type instead of auto, which is simple if we make it a struct, but either way it should be const XXXX & whenever possible.

77

Formatting: The methods should start with a lower case letter.

Maybe add a TODO mentioning that we should look in the vicinity for other assumes we can merge the information with.

85

I'd just get the module from the instruction. I->getModule()

llvm/test/Transforms/Util/assume-builder.ll

56

Sure, let's keep them for now.

---

We need a test in which a property holds for multiple arguments.

[Tyker]

fixed comments.

llvm/lib/Transforms/Utils/AssumeBuilder.cpp

77

Maybe add a TODO mentioning that we should look in the vicinity for other assumes we can merge the information with.

to do this the BuildAssumeFromInst will have to change and insert the assume. i don't know if it is preferable.

85

the module can't be const because of Intrinsic::getDeclaration requires a non-const Module.

[jdoerfert]

Only minor points are left. including:
Can we make string attributes and function scope attributes optional (under a command line flag)? Especially the uses created for the latter could easily confuse the call graph and similar passes. That said, we need to teach them to ignore llvm.assume uses (see below).

Next steps (in no particular order):

• Teach passes sensitive to uses, especially instcombine, to ignore uses in an llvm.assume.
• Teach passes, e.g., the Attributor, to use the information provided this way.
• Emit llvm.assume when we move/delete call instructions.
• Perform some experiments.
• Revisit the list to get agreement.

llvm/lib/Transforms/Utils/AssumeBuilder.cpp

43

Documentation for the class and members is missing.

Nit: Maybe KnowledgeSet or sth. similar is a better name, BundlSet implies these are "already" operand bundles.

71

You can directly capture the result:
if (Function *Fn = Call->getCalledFunction())

77

to do this the BuildAssumeFromInst will have to change and insert the assume. i don't know if it is preferable.

Fair point. We can investigate that in the future. Maybe a method to locate an existing assume, one to combine the information, one to create the new one and replace the old. Or a dedicated pass that moves them around and combines them. I think less assumes is "generally speaking" better but we don't need this now.

84

Should we reverse the order here? That way the first argument is always the "WasOn" one.

114

Nit: one can use for (Instruction &I : instructions(F)) to save one loop level here

[Tyker]

fixed comments.

Next steps (in no particular order):

• Teach passes sensitive to uses, especially instcombine, to ignore uses in an llvm.assume.
• Teach passes, e.g., the Attributor, to use the information provided this way.
• Emit llvm.assume when we move/delete call instructions.
• Perform some experiments.
• Revisit the list to get agreement.

I agree with the tasks.
But i think that we also need to build an API to query those new assumes before using them. First to have "good names" instead of indexes in the operand bundle and also because we don't want users to directly depend on the representation. If at some point we want to group knowledge by attributes.
example: for

call void @func(i32* nonnull %P1, i32* nonnull %P)

build

call void @llvm.assume(i1 true) [ "nonnull"(i32* %P1, i32* %P)]

instead of

call void @llvm.assume(i1 true) [ "nonnull"(i32* %P1), "nonnull"(i32* %P)]

this change will be harder if passes access the operand bundle element directly.

[jdoerfert]

In D72475#1816055, @Tyker wrote:

But i think that we also need to build an API to query those new assumes before using them. First to have "good names" instead of indexes in the operand bundle and also because we don't want users to directly depend on the representation. If at some point we want to group knowledge by attributes.
example: for

call void @func(i32* nonnull %P1, i32* nonnull %P)

build

call void @llvm.assume(i1 true) [ "nonnull"(i32* %P1, i32* %P)]

instead of

call void @llvm.assume(i1 true) [ "nonnull"(i32* %P1), "nonnull"(i32* %P)]

this change will be harder if passes access the operand bundle element directly.

I agree that an API is useful, Since this is attribute-based it should be as well. Maybe something like

`bool getAttributeFromAssume(Value &Base, CallInst &AssumeCI, Attribute::Kind Kind, int &Value)`

and similar for string attributes. Alternatively we could return a map from WhatOn values to attributes.

I don't understand. What do you mean by "good names"? We have the operand bundle strings, right?
Agreed that an API should hide the actual encoding, thus the above grouping is something we should be able to do easily.

[Tyker]

In D72475#1817423, @jdoerfert wrote:

`bool getAttributeFromAssume(Value &Base, CallInst &AssumeCI, Attribute::Kind Kind, int &Value)`

and similar for string attributes. Alternatively we could return a map from WhatOn values to attributes.

something like that seem fine.

I don't understand. What do you mean by "good names"? We have the operand bundle strings, right?

I meant that in the operand bundle the first argument is the WasOn and the second is optionally the attributes value.
but users shouldn't have to use magic numbers to access those fields.

Agreed that an API should hide the actual encoding, thus the above grouping is something we should be able to do easily.

i don't know if the grouping is desirable it makes arguments in the bundle more confusing when there is the attribute has an optional argument.
but i wanted to have the opportunity to tweak the representation later.

is there any comment left on this patch ?

[jdoerfert]

In D72475#1817585, @Tyker wrote:

In D72475#1817423, @jdoerfert wrote:

`bool getAttributeFromAssume(Value &Base, CallInst &AssumeCI, Attribute::Kind Kind, int &Value)`

and similar for string attributes. Alternatively we could return a map from WhatOn values to attributes.

something like that seem fine.

I don't understand. What do you mean by "good names"? We have the operand bundle strings, right?

I meant that in the operand bundle the first argument is the WasOn and the second is optionally the attributes value.
but users shouldn't have to use magic numbers to access those fields.

Oh, right, agreed!

Agreed that an API should hide the actual encoding, thus the above grouping is something we should be able to do easily.

i don't know if the grouping is desirable it makes arguments in the bundle more confusing when there is the attribute has an optional argument.
but i wanted to have the opportunity to tweak the representation later.

is there any comment left on this patch ?

I added some minor ones but I think this patch is otherwise fine. We should not land it right away though. If you write the API next, either of us can make use of it in the Attributor. Lastly we need to generate the calls in the first place and we can try this out on benchmarks.

llvm/include/llvm/Transforms/Utils/AssumeBuilder.h

21

Nit: Maybe say we return an assume call instead of just "instruction"?

The sentence is broken I think, the end should be something like derived from \p I.

26

Arguably, you only need to expose one version, e.g., the single instruction one (with const). In the impl. we can query the module.

llvm/lib/Transforms/Utils/AssumeBuilder.cpp

8

Here and in the header we should add a short file comment describing what functionality is in here.

18

Nit: We might not need all of these anymore.

[Tyker]

i renamed the files to KnowledgeRetention.* to be more general. we can put other related utilities like the query API in the same files. i had a hard time finding a good name and i am not sure i succeeded what do you think ?

i also fixed an issue were the order of bundles was non-deterministic. to do so i had to add a sort, but this sort can be used later to find bundles by binary search in the API.

In D72475#1818682, @jdoerfert wrote:

We should not land it right away though

is it because the creation of the clang-10 release branch is happening soon or because we need to benchmarks first ?

If you write the API next, either of us can make use of it in the Attributor.

we can make the API and the first user of the API come at the same time so we can test the API transitively ? or this would make the patch too big ? I haven't taken a detailed enough look at the Attributor but i need to get to know it anyway.

Lastly we need to generate the calls in the first place and we can try this out on benchmarks.

agreed

llvm/include/llvm/Transforms/Utils/AssumeBuilder.h

26

the module can't be const because of Intrinsic::getDeclaration requires a non-const Module. so it can't be optained from a const Instruction.
the other solution is const_cast, but i don't like it so much.

[jdoerfert]

In D72475#1820962, @Tyker wrote:

i renamed the files to KnowledgeRetention.* to be more general. we can put other related utilities like the query API in the same files. i had a hard time finding a good name and i am not sure i succeeded what do you think ?

OK with me.

i also fixed an issue were the order of bundles was non-deterministic. to do so i had to add a sort, but this sort can be used later to find bundles by binary search in the API.

Sounds good.

In D72475#1818682, @jdoerfert wrote:

We should not land it right away though

is it because the creation of the clang-10 release branch is happening soon or because we need to benchmarks first ?

Also because of that, and we do not have settled on this scheme in the RFC thread.

If you write the API next, either of us can make use of it in the Attributor.

we can make the API and the first user of the API come at the same time so we can test the API transitively ? or this would make the patch too big ? I haven't taken a detailed enough look at the Attributor but i need to get to know it anyway.

So we can have a user right away. Any location that looks for attributes right now is an opportunity to look at attributes retained in an llvm.assume. The final Attributor design will probably become a little involved because we want to cache
results, use the API to get all attribute mappings right away, ... A nice first use case could be isKnownNonZeroFromAssume in ValueTracking.cpp or the pass that does load/store alignment from assume.

Lastly we need to generate the calls in the first place and we can try this out on benchmarks.

agreed

[Tyker]

minor improvements.

[jdoerfert]

llvm/lib/Transforms/Utils/KnowledgeRetention.cpp

68 ↗

(On Diff #238628)

I don't think we should use the name here. We can use the pointer value, if that makes sense, but not the name as it can be changed which would break the invariant.

[Tyker]

fixed.

llvm/lib/Transforms/Utils/KnowledgeRetention.cpp

68 ↗

(On Diff #238628)

I reordered element in the tuple. so that names comes last because this is what enabled the best algorithm for query.

Regarding ordering by pointer or not ordering at all. i think that this will make the output non-deterministic or relying on the allocator. if it is fine to for it to be non-deterministic. we could fix the printing to prevent spurious test failures. query function can deal with any order.

[jdoerfert]

llvm/lib/Transforms/Utils/KnowledgeRetention.cpp

68 ↗

(On Diff #238628)

I can see why we do not want the non-deterministic order so no sorting by pointer. Now the name thing is still an issue. We should not rely on names whatsoever, if changing a name influences the result of a query is not what we want because it leads to hard to debug interactions of things that are unrelated.

[Tyker]

llvm/lib/Transforms/Utils/KnowledgeRetention.cpp

68 ↗

(On Diff #238628)

with the current query API the order by name doesn't affect the results. it is just used as a way to prevent non-determinism.

[MaskRay]

It'd be nice if the description of 8ebe001553d0c204cc41f3dbc595031828b1f140 could mention what is different from previous attempts... Two previous reverts did not say why this patch was reverted.

Also, you can strip Subscribers: and Tags: #llvm lines from the description. They are not useful. I am using this script:

arcfilter () {
        git log -1 --pretty=%B | awk '/Reviewers:|Subscribers:/{p=1} /Reviewed By:|Differential Revision:/{p=0} !p && !/^Summary:/' | git commit --amend -F -
}

[jdoerfert]

In D72475#1853612, @MaskRay wrote:

It'd be nice if the description of 8ebe001553d0c204cc41f3dbc595031828b1f140 could mention what is different from previous attempts... Two previous reverts did not say why this patch was reverted.

Edit: Now I see.

Btw. We should also remove the [WIP] tag.

[Tyker]

In D72475#1853612, @MaskRay wrote:

It'd be nice if the description of 8ebe001553d0c204cc41f3dbc595031828b1f140 could mention what is different from previous attempts... Two previous reverts did not say why this patch was reverted.

Also, you can strip Subscribers: and Tags: #llvm lines from the description. They are not useful. I am using this script:

arcfilter () {
        git log -1 --pretty=%B | awk '/Reviewers:|Subscribers:/{p=1} /Reviewed By:|Differential Revision:/{p=0} !p && !/^Summary:/' | git commit --amend -F -
}

sorry for all the commit and revert. some build bot have a compile error under gcc that I can't reproduce locally. so commits and reverts are kind of trial and error. if there is a better way do deal with this kind of issue please let me know.
I will strip the auto-generated parts of the comments from phab. thanks for the script.

[jdoerfert]

In D72475#1853681, @Tyker wrote:

In D72475#1853612, @MaskRay wrote:

It'd be nice if the description of 8ebe001553d0c204cc41f3dbc595031828b1f140 could mention what is different from previous attempts... Two previous reverts did not say why this patch was reverted.

Also, you can strip Subscribers: and Tags: #llvm lines from the description. They are not useful. I am using this script:

arcfilter () {
        git log -1 --pretty=%B | awk '/Reviewers:|Subscribers:/{p=1} /Reviewed By:|Differential Revision:/{p=0} !p && !/^Summary:/' | git commit --amend -F -
}

sorry for all the commit and revert. some build bot have a compile error under gcc that I can't reproduce locally. so commits and reverts are kind of trial and error. if there is a better way do deal with this kind of issue please let me know.
I will strip the auto-generated parts of the comments from phab. thanks for the script.

I usually ask on IRC if anyone knows / can reproduce the error.

[Tyker]

In D72475#1853688, @jdoerfert wrote:

In D72475#1853681, @Tyker wrote:

In D72475#1853612, @MaskRay wrote:

It'd be nice if the description of 8ebe001553d0c204cc41f3dbc595031828b1f140 could mention what is different from previous attempts... Two previous reverts did not say why this patch was reverted.

Also, you can strip Subscribers: and Tags: #llvm lines from the description. They are not useful. I am using this script:

arcfilter () {
        git log -1 --pretty=%B | awk '/Reviewers:|Subscribers:/{p=1} /Reviewed By:|Differential Revision:/{p=0} !p && !/^Summary:/' | git commit --amend -F -
}

sorry for all the commit and revert. some build bot have a compile error under gcc that I can't reproduce locally. so commits and reverts are kind of trial and error. if there is a better way do deal with this kind of issue please let me know.
I will strip the auto-generated parts of the comments from phab. thanks for the script.

I usually ask on IRC if anyone knows / can reproduce the error.

i found a version of gcc on which i have the same error as the build bot. i should be fine from here.

[fhahn]

Is this approach documented somewhere in-tree? I think it would be good to document it, rather than just having a link to the mailing list.

llvm/include/llvm/Transforms/Utils/KnowledgeRetention.h

9 ↗

(On Diff #241919)

I think it would be good to describe what kinds of information are preserved.

llvm/lib/Transforms/Utils/KnowledgeRetention.cpp

25 ↗

(On Diff #241919)

It would probably be good to document the members here.

26 ↗

(On Diff #241919)

Is this only used with attributes? If so, wouldn't it be better to use an Attribute*?

34 ↗

(On Diff #241919)

What is the use case for retaining an attribute without argument? Would also be good to mention.

[jdoerfert]

In D72475#1853751, @fhahn wrote:

Is this approach documented somewhere in-tree? I think it would be good to document it, rather than just having a link to the mailing list.

Lang Ref needs to be updated now. Agreed. @Tyker do you want to do that or should I?

llvm/include/llvm/Transforms/Utils/KnowledgeRetention.h

9 ↗

(On Diff #241919)

That is always hard to keep in sync. I would prefer a generic file comment and alternatively more details on the BuildAssumeFromInst description below.

[fhahn]

llvm/include/llvm/Transforms/Utils/KnowledgeRetention.h

9 ↗

(On Diff #241919)

Sure, a reference to the langref or something like that is fine. But as it reads now it does not give any kind of indication of what this can/should be used for.

[jdoerfert]

llvm/include/llvm/Transforms/Utils/KnowledgeRetention.h

9 ↗

(On Diff #241919)

The lang ref change was on my list anyway. Basically as part of the first in-tree use, which is the alignment assumption. We'll prioritize the lang ref patch now.

In addition we could add that some information to BuildAssumeFromInst that it retains llvm::Attribute information for now.

[Tyker]

In D72475#1853787, @jdoerfert wrote:

In D72475#1853751, @fhahn wrote:

Is this approach documented somewhere in-tree? I think it would be good to document it, rather than just having a link to the mailing list.

Lang Ref needs to be updated now. Agreed. @Tyker do you want to do that or should I?

this is needed. if you want i can do it.

llvm/include/llvm/Transforms/Utils/KnowledgeRetention.h

9 ↗

(On Diff #241919)

In addition we could add that some information to BuildAssumeFromInst that it retains llvm::Attribute information for now.

this restriction should be lifted at some point.

llvm/include/llvm/IR/Attributes.h

static Attribute getWithDereferenceableBytes(LLVMContext &Context,
                                               uint64_t Bytes);
   static Attribute getWithDereferenceableOrNullBytes(LLVMContext &Context,
                                                      uint64_t Bytes);
   static Attribute getWithAllocSizeArgs(LLVMContext &Context,
                                         unsigned ElemSizeArg,
                                         const Optional<unsigned> &NumElemsArg);
   static Attribute getWithByValType(LLVMContext &Context, Type *Ty);
 
+  static Attribute::AttrKind getAttrKindFromName(StringRef AttrName);
+
+  static StringRef getNameFromAttrKind(Attribute::AttrKind AttrKind);
+
   //===--------------------------------------------------------------------===//
   // Attribute Accessors
   //===--------------------------------------------------------------------===//
 
   /// Return true if the attribute is an Attribute::AttrKind type.
   bool isEnumAttribute() const;
 
   /// Return true if the attribute is an integer attribute.

llvm/include/llvm/Transforms/Utils/AssumeBuilder.h

+//===- AssumeBuilder.h - Build assume to preserve informations---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_TRANSFORMS_UTILS_ASSUMEBUILDER_H
+#define LLVM_TRANSFORMS_UTILS_ASSUMEBUILDER_H
+
+#include "llvm/ADT/SmallSet.h"
+#include "llvm/IR/InstrTypes.h"
+#include "llvm/IR/Instruction.h"
+#include "llvm/IR/PassManager.h"
+
+namespace llvm {
+
+/// Build an instruction to preserve informations that can be derived from
+/// this call. if no information was found, returns null.
+Instruction *BuildAssumeFromInst(const Instruction *I, Module *M);
+Instruction *BuildAssumeFromInst(Instruction *I) {
+  return BuildAssumeFromInst(I, I->getModule());
+}
+
+/// This pass will try to build an llvm.assume for every instruction in the
+/// function.
+class AssumeBuilderPass : public PassInfoMixin<AssumeBuilderPass> {
+
+public:
+  explicit AssumeBuilderPass() {}
+
+  PreservedAnalyses run(Function &F, FunctionAnalysisManager &AM);
+};
+
+} // namespace llvm
+
+#endif

llvm/lib/IR/Attributes.cpp

 Attribute
 Attribute::getWithAllocSizeArgs(LLVMContext &Context, unsigned ElemSizeArg,
                                 const Optional<unsigned> &NumElemsArg) {
   assert(!(ElemSizeArg == 0 && NumElemsArg && *NumElemsArg == 0) &&
          "Invalid allocsize arguments -- given allocsize(0, 0)");
   return get(Context, AllocSize, packAllocSizeArgs(ElemSizeArg, NumElemsArg));
 }
 
+Attribute::AttrKind Attribute::getAttrKindFromName(StringRef AttrName) {
+  return StringSwitch<Attribute::AttrKind>(AttrName)
+#define GET_ATTR_NAMES
+#define ATTRIBUTE_ENUM(ENUM_NAME, DISPLAY_NAME)                                \
+  .Case(#DISPLAY_NAME, Attribute::ENUM_NAME)
+#include "llvm/IR/Attributes.inc"
+      .Default(Attribute::None);
+}
+
+StringRef Attribute::getNameFromAttrKind(Attribute::AttrKind AttrKind) {
+  switch (AttrKind) {
+#define GET_ATTR_NAMES
+#define ATTRIBUTE_ENUM(ENUM_NAME, DISPLAY_NAME)                                \
+  case AttrKind::ENUM_NAME:                                                    \
+    return #DISPLAY_NAME;
+#include "llvm/IR/Attributes.inc"
+  case AttrKind::None:
+    return "none";
+  default:
+    llvm_unreachable("invalid Kind");
+  }
+}
+
 //===----------------------------------------------------------------------===//
 // Attribute Accessor Methods
 //===----------------------------------------------------------------------===//
 
 bool Attribute::isEnumAttribute() const {
   return pImpl && pImpl->isEnumAttribute();
 }
 

llvm/lib/IR/Core.cpp

unsigned LLVMGetMDKindIDInContext(LLVMContextRef C, const char *Name,
                                   unsigned SLen) {
   return unwrap(C)->getMDKindID(StringRef(Name, SLen));
 }
 
 unsigned LLVMGetMDKindID(const char *Name, unsigned SLen) {
   return LLVMGetMDKindIDInContext(LLVMGetGlobalContext(), Name, SLen);
 }
 
-static Attribute::AttrKind getAttrKindFromName(StringRef AttrName) {
-  return StringSwitch<Attribute::AttrKind>(AttrName)
-#define GET_ATTR_NAMES
-#define ATTRIBUTE_ENUM(ENUM_NAME, DISPLAY_NAME)                                \
-  .Case(#DISPLAY_NAME, Attribute::ENUM_NAME)
-#include "llvm/IR/Attributes.inc"
-      .Default(Attribute::None);
-}
-
 unsigned LLVMGetEnumAttributeKindForName(const char *Name, size_t SLen) {
-  return getAttrKindFromName(StringRef(Name, SLen));
+  return Attribute::getAttrKindFromName(StringRef(Name, SLen));
 }
 
 unsigned LLVMGetLastEnumAttributeKind(void) {
   return Attribute::AttrKind::EndAttrKinds;
 }
 
 LLVMAttributeRef LLVMCreateEnumAttribute(LLVMContextRef C, unsigned KindID,
                                          uint64_t Val) {

llvm/lib/Passes/PassBuilder.cpp

 #include "llvm/Transforms/Scalar/SimpleLoopUnswitch.h"
 #include "llvm/Transforms/Scalar/SimplifyCFG.h"
 #include "llvm/Transforms/Scalar/Sink.h"
 #include "llvm/Transforms/Scalar/SpeculateAroundPHIs.h"
 #include "llvm/Transforms/Scalar/SpeculativeExecution.h"
 #include "llvm/Transforms/Scalar/TailRecursionElimination.h"
 #include "llvm/Transforms/Scalar/WarnMissedTransforms.h"
 #include "llvm/Transforms/Utils/AddDiscriminators.h"
+#include "llvm/Transforms/Utils/AssumeBuilder.h"
 #include "llvm/Transforms/Utils/BreakCriticalEdges.h"
 #include "llvm/Transforms/Utils/CanonicalizeAliases.h"
 #include "llvm/Transforms/Utils/EntryExitInstrumenter.h"
 #include "llvm/Transforms/Utils/InjectTLIMappings.h"
 #include "llvm/Transforms/Utils/LCSSA.h"
 #include "llvm/Transforms/Utils/LibCallsShrinkWrap.h"
 #include "llvm/Transforms/Utils/LoopSimplify.h"
 #include "llvm/Transforms/Utils/LowerInvoke.h"

llvm/lib/Passes/PassRegistry.def

 
 #ifndef FUNCTION_PASS
 #define FUNCTION_PASS(NAME, CREATE_PASS)
 #endif
 FUNCTION_PASS("aa-eval", AAEvaluator())
 FUNCTION_PASS("adce", ADCEPass())
 FUNCTION_PASS("add-discriminators", AddDiscriminatorsPass())
 FUNCTION_PASS("aggressive-instcombine", AggressiveInstCombinePass())
+FUNCTION_PASS("assume-builder", AssumeBuilderPass())
 FUNCTION_PASS("alignment-from-assumptions", AlignmentFromAssumptionsPass())
 FUNCTION_PASS("bdce", BDCEPass())
 FUNCTION_PASS("bounds-checking", BoundsCheckingPass())
 FUNCTION_PASS("break-crit-edges", BreakCriticalEdgesPass())
 FUNCTION_PASS("callsite-splitting", CallSiteSplittingPass())
 FUNCTION_PASS("consthoist", ConstantHoistingPass())
 FUNCTION_PASS("chr", ControlHeightReductionPass())
 FUNCTION_PASS("correlated-propagation", CorrelatedValuePropagationPass())

llvm/lib/Transforms/Utils/AssumeBuilder.cpp

+//===- AssumeBuilder.h - Build assume to preserve informations --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "llvm/Transforms/Utils/AssumeBuilder.h"
+#include "llvm/IR/AssemblyAnnotationWriter.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/InstrTypes.h"
+#include "llvm/IR/IntrinsicInst.h"
+#include "llvm/IR/Module.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FormattedStream.h"
+
+using namespace llvm;
+
+namespace {
+
+struct AssumeBuilderState {
+  Module *M;
+
+  SmallSet<std::tuple<const char *, Value *, Value *>, 8> BundleSet;
+
+  AssumeBuilderState(Module *M) : M(M) {}
+
+  void AddAttribute(AssumeBuilderState &Builder, Attribute Attr, Value *WasOn) {
+    StringRef Name;
+    Value *AttrArg = nullptr;
+    if (Attr.isStringAttribute())
+      Name = Attr.getKindAsString();
+    else
+      Name = Attribute::getNameFromAttrKind(Attr.getKindAsEnum());
+    if (Attr.isIntAttribute())
+      AttrArg = ConstantInt::get(Type::getInt64Ty(Builder.M->getContext()),
+                                 Attr.getValueAsInt());
+    Builder.BundleSet.insert(std::make_tuple(Name.data(), AttrArg, WasOn));
+  }
+
+  void AddCall(AssumeBuilderState &Builder, const CallBase *Call) {
+    for (AttributeList AttrList :
+         {Call->getAttributes(), Call->getCalledFunction()->getAttributes()}) {
+      /// the start Index is at 1 because 0 is the return value.
+      for (unsigned Idx = 1; Idx < AttrList.getNumAttrSets(); Idx++)
+        for (Attribute Attr : AttrList.getAttributes(Idx))
+          AddAttribute(Builder, Attr, Call->getArgOperand(Idx - 1));
+      for (Attribute Attr : AttrList.getFnAttributes())
+        AddAttribute(Builder, Attr, Call->getCalledFunction());
+    }
+  }
+
+  Instruction *Build() {
+    if (!BundleSet.empty()) {
+      Function *FnAssume = Intrinsic::getDeclaration(M, Intrinsic::assume);
+      LLVMContext &C = M->getContext();
+      SmallVector<OperandBundleDef, 8> OpBundle;
+      for (auto Elem : BundleSet) {
+        SmallVector<Value *, 2> Args;
+        if (std::get<1>(Elem))
+          Args.push_back(std::get<1>(Elem));
+        Args.push_back(std::get<2>(Elem));
+        OpBundle.push_back(OperandBundleDefT<Value *>(std::get<0>(Elem), Args));
+      }
+      return CallInst::Create(
+          FnAssume, ArrayRef<Value *>({ConstantInt::getTrue(C)}), OpBundle);
+    }
+    return nullptr;
+  }
+
+  void AddInstruction(const Instruction *I) {
+    if (auto *Call = dyn_cast<CallBase>(I))
+      AddCall(*this, Call);
+    // TODO: Add support for the other Instruction.
+  }
+};
+
+} // namespace
+
+Instruction *llvm::BuildAssumeFromInst(const Instruction *I, Module *M) {
+  AssumeBuilderState Builder(M);
+  Builder.AddInstruction(I);
+  return Builder.Build();
+}
+
+PreservedAnalyses AssumeBuilderPass::run(Function &F,
+                                         FunctionAnalysisManager &AM) {
+  for (BasicBlock &BB : F)
+    for (Instruction &I : BB)
+      if (Instruction *Assume = BuildAssumeFromInst(&I))
+        Assume->insertBefore(&I);
+  return PreservedAnalyses::all();
+}

llvm/lib/Transforms/Utils/CMakeLists.txt

 add_llvm_component_library(LLVMTransformUtils
   ASanStackFrameLayout.cpp
   AddDiscriminators.cpp
+  AssumeBuilder.cpp
   BasicBlockUtils.cpp
   BreakCriticalEdges.cpp
   BuildLibCalls.cpp
   BypassSlowDivision.cpp
   CallPromotionUtils.cpp
   CanonicalizeAliases.cpp
   CloneFunction.cpp
   CloneModule.cpp

llvm/test/Transforms/Util/assume-builder.ll

+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -passes='assume-builder' -S %s | FileCheck %s
+
+declare void @func(i32*, i32*)
+declare void @func_cold(i32*) cold
+declare void @func_strbool(i32*) "no-jump-tables"
+declare void @func_many(i32*) "no-jump-tables" nounwind "less-precise-fpmad" willreturn norecurse
+declare void @func_argattr(i32* align 8, i32* nonnull) nounwind
+
+define void @test(i32* %P, i32* %P1, i32* %P2, i32* %P3) {
+; CHECK-LABEL: @test(
+; CHECK-NEXT:    call void @llvm.assume(i1 true) [ "nonnull"(i32* [[P:%.*]]), "dereferenceable"(i64 16, i32* [[P]]) ]
+; CHECK-NEXT:    call void @func(i32* nonnull dereferenceable(16) [[P]], i32* null)
+; CHECK-NEXT:    call void @llvm.assume(i1 true) [ "dereferenceable"(i64 12, i32* [[P1:%.*]]), "nonnull"(i32* [[P]]) ]
+; CHECK-NEXT:    call void @func(i32* dereferenceable(12) [[P1]], i32* nonnull [[P]])
+; CHECK-NEXT:    call void @llvm.assume(i1 true) [ "dereferenceable"(i64 12, i32* [[P1]]), "cold"(void (i32*)* @func_cold) ]
+; CHECK-NEXT:    call void @func_cold(i32* dereferenceable(12) [[P1]]) #0
+; CHECK-NEXT:    call void @llvm.assume(i1 true) [ "dereferenceable"(i64 12, i32* [[P1]]), "cold"(void (i32*)* @func_cold) ]
+; CHECK-NEXT:    call void @func_cold(i32* dereferenceable(12) [[P1]])
+; CHECK-NEXT:    call void @func(i32* [[P1]], i32* [[P]])
+; CHECK-NEXT:    call void @llvm.assume(i1 true) [ "no-jump-tables"(void (i32*)* @func_strbool) ]
+; CHECK-NEXT:    call void @func_strbool(i32* [[P1]])
+; CHECK-NEXT:    call void @llvm.assume(i1 true) [ "dereferenceable"(i64 16, i32* [[P]]), "dereferenceable"(i64 8, i32* [[P]]) ]
+; CHECK-NEXT:    call void @func(i32* dereferenceable(16) [[P]], i32* dereferenceable(8) [[P]])
+; CHECK-NEXT:    call void @llvm.assume(i1 true) [ "align"(i64 8, i32* [[P1]]), "norecurse"(void (i32*)* @func_many), "nounwind"(void (i32*)* @func_many), "willreturn"(void (i32*)* @func_many), "less-precise-fpmad"(void (i32*)* @func_many), "no-jump-tables"(void (i32*)* @func_many) ]
+; CHECK-NEXT:    call void @func_many(i32* align 8 [[P1]])
+; CHECK-NEXT:    call void @llvm.assume(i1 true) [ "align"(i64 8, i32* [[P2:%.*]]), "nonnull"(i32* [[P3:%.*]]), "nounwind"(void (i32*, i32*)* @func_argattr) ]
+; CHECK-NEXT:    call void @func_argattr(i32* [[P2]], i32* [[P3]])
+; CHECK-NEXT:    ret void
+;
+  call void @func(i32* nonnull dereferenceable(16) %P, i32* null)
+  call void @func(i32* dereferenceable(12) %P1, i32* nonnull %P)
+  call void @func_cold(i32* dereferenceable(12) %P1) cold
+  call void @func_cold(i32* dereferenceable(12) %P1)
+  call void @func(i32* %P1, i32* %P)
+  call void @func_strbool(i32* %P1)
+  call void @func(i32* dereferenceable(16) %P, i32* dereferenceable(8) %P)
+  call void @func_many(i32* align 8 %P1)
+  call void @func_argattr(i32* %P2, i32* %P3)
+  ret void
+}