I am still working on this, tests will be added later.
Aug 28 2020
Aug 27 2020
Aug 15 2020
Aug 13 2020
Aug 1 2020
Jul 31 2020
Jul 28 2020
Jul 27 2020
Changed some function names.
- Cache the InternalizeCost for every function
Jul 26 2020
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.
Jul 24 2020
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
Jul 23 2020
Sorry, I will look into it and update soon.
Jul 20 2020
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.
Jul 14 2020
Added classof function to allow cast from AbstractAttribute to specific AA
Jul 12 2020
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.
Jul 9 2020
Jul 8 2020
Can we just merge the dependency graph and the "SchedulingGraph" because I think they are quite similar.
Jul 6 2020
- Added tests for the dot file
- other style fixes
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.
Jul 5 2020
Attributes are going to be decleared outside of the Attributor soon.
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.
Jul 3 2020
Directly declare the dependency graph inside the Attributor struct, instead of a pointer or reference
Jul 2 2020
Move the synthetic node in to the dependency graph
- Use references instead of pointer for the synthetic node
Jun 30 2020
- Added other 4 lines of test
- Rebased patch
- Replaced the AllAbstractAttributes with the syn node of the dependency graph
- Moved getName() function to header file
- 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)
Jun 22 2020
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.
Jun 21 2020
Jun 20 2020
Jun 16 2020
Added missing comments
- Use AADepGraphNode for dependence tracking and make AbstractAttribute inherent from it (thanks kuter for the advice)
- Updated testcase
Jun 11 2020
- 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.
Jun 8 2020
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().
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.
Jun 6 2020
- Use AbstractAttribute directly as the dependency graph node
- Added opt options to dump and print the dependency graph
Jun 1 2020
Hi, what is the state of this ?
Hi, I have just started my work on this.
Apr 30 2020
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.
Apr 25 2020
Apr 1 2020
Apologies for the delay, can you rebase this and provide me with "Firstname Lastname <email>" from you so I can attribute it to you?
Mar 20 2020
- added some CHECK-NOT to tests
- deleted unused statistic
- update tests
Mar 19 2020
- Added tests
- Added noinline attribute to call site to prevent the internal function being inlined
Mar 18 2020
Updated createShallowWrapper() function
Mar 6 2020
- 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
Mar 5 2020
- Use InlineableFunctions ptr set to track functions that can be inlined
- 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)
- 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)
Mar 4 2020
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.