I am still working on this, tests will be added later.

Changed some function names.

• Cache the InternalizeCost for every function

For now the patch only contains the interface and is still WIP. I will update it with more detailed algorithm later.

remove the cast.

I uploaded this patch D84532 to fix it.

use C++ cast

• Changes as others suggests:
  • Updated description for the command line option
  • Fixed typos
  • Changed the copied function's name from "_copied" to ".internalized"
  • Remove the const qulifier
  • Added 4 run lines of tests
  • Removed the llvm:: for the clone function

Sorry, I will look into it and update soon.

Minor update to test

In previous diff, we use the address of the ID to sort the list of the AAs so that we can print them nicer.
But it seems that in different architectures, the address can be different, which can cause the sequence of
AAs are not deterministic and the test to fail.
So deleted the sorting part and I think now the sequence of AAs printed out should be deterministic, but I
am not sure.

Added classof function to allow cast from AbstractAttribute to specific AA

Take a look at this page: https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access , you need to send an email to Chris to ask for commit access.

Can we just merge the dependency graph and the "SchedulingGraph" because I think they are quite similar.

• Added tests for the dot file
• other style fixes

In D78861#2131573, @jdoerfert wrote:

This looks pretty good :). Nice active review :)

I have some minor comments below. We also should add a test for the print and dot output.

I need some help here:
Is there a way to test the dot output? I checked the .dot file and found it hard to write CHECK lines (see below) because we are interested in the link between different graph nodes (line 3 and line 4)

I think we can create a separate patch for the macro stuff.

Attributes are going to be decleared outside of the Attributor soon.

In D83172#2131745, @kuter wrote:

This seems like too much code duplication.
I think we can have a macro to declare getIdAddr and the getName function.
I am curious what other people think about this.

Directly declare the dependency graph inside the Attributor struct, instead of a pointer or reference

Move the synthetic node in to the dependency graph

• Use references instead of pointer for the synthetic node

• Added other 4 lines of test

1. Rebased patch
2. Replaced the AllAbstractAttributes with the syn node of the dependency graph
3. Moved getName() function to header file
4. The classof() function of the AbstractAttribute class simply returns true, because all nodes except for the syn node are of type AbstractAttribute (about classof function)

In D82305#2107512, @nikic wrote:

This overlaps with D82316. I believe the attribute defined there is more useful, because we generally need values to be non-poison *and* non-undef to make meaningful optimizations.

Added missing comments

• Use AADepGraphNode for dependence tracking and make AbstractAttribute inherent from it (thanks kuter for the advice)
• Updated testcase

• Added new printer function for abstract attribute
• Added getName() function to each abstract attribute which simply gets the name of the AA.
• Added print() function for dependency graph.

Hi I found out why. Your are dumping attributes after IR cleanup. IR Cleanup deletes the IR values that are no longer needed.
But they are still referenced by the Attributes.

if you look at D81022, which will be merged soon.
The dump should happen after `::runTillFixpoint().

In D78861#2081311, @kuter wrote:

This does not compile for me. The compiler error that I get is about creating a GraphTraits specialization outside of the llvm namespace.
When i put the GraphTraits in llvm namespace it does compile.

• Use AbstractAttribute directly as the dependency graph node
• Added opt options to dump and print the dependency graph

In D78861#2066299, @kuter wrote:

Hi, what is the state of this ?

Hi, I have just started my work on this.

Is there a plan to actually use the graph? If not, then the graph shouldn't be built unless there was a request to output it, i think.

In D76404#1956336, @jdoerfert wrote:

Apologies for the delay, can you rebase this and provide me with "Firstname Lastname <email>" from you so I can attribute it to you?

Rebased patch.

• added some CHECK-NOT to tests
• deleted unused statistic

• update tests

• Added tests
• Added noinline attribute to call site to prevent the internal function being inlined

Updated createShallowWrapper() function

• Added const for InlineableFunctions
• updated isFunctionIPOAmendable()

Created a helper function in Attributor which determines whether the function is IPO amendable and replaced hasExactDefinition with this helper function.

Move InlineableFunctions set to InfoCache

1. Use InlineableFunctions ptr set to track functions that can be inlined
2. As the ptr set is a private variable for Attributor, so in AA.initialize(), we cannot determine if the inexactly defined function can be inlined or not, so all inexactly defined functions that have alwayinline attribute will keep its state unchanged (just return from the function)
3. In CreateAAFor function, search the ptr set for the function, if the function has alwayinline attribute but cannot be inlined, we cannot analyze it (indicatePessimisticFixpoint)

I have fixed the problem that FnScope may be null and cached the result of isInlineViable. I have also updated my test file to check the attributes.