This is an archive of the discontinued LLVM Phabricator instance.

[ThinLTO] WIP Tracking of per-call mod ref info
Needs ReviewPublic

Authored by tejohnson on Aug 18 2017, 6:13 PM.

Details

Reviewers
ncharlie
davide
Summary

Draft changes to add per-call memory access information to the
in-memory index. The ReadNone and ReadOnly function attributes
are changed to only reflect non-call instructions.

This will enable more effective propagation of those attributes
during the thin link. For example, if the callee is marked as
ReadNone during the bottom up SCC propagation, then calls to
it that had conservative mod ref (indicating that they MayWrite)
can be changed to ReadNone. I.e the new function attribute will
be the max (most conservative) of its recorded attribute computed
without considering its calls, and the read/write attribute on
the call, where the call's read/write attribute is computed by
combining (taking the most conservative of) the read/write attribute
recorded in the index along that edge and the function attribute
recorded for it in the index (after earlier bottom up propagation).

Some notes:

  • I noted that we should probably rename the ReadNone and

ReadOnly attributes to reflect the fact that they don't include
calls. However, after the bottom up propagation during the thin
link they will in fact include call behavior (as described above).
Not sure how to accurately name these attributes

  • I only added the changes in the in-memory index, the Bitcode

reader and writer support still needs to be added.

  • I left in some tracing messages emitted during ModuleSummaryIndex

building.

  • I had to split out some of the FunctionAttr handling and moved it

to some files in lib/Analysis so that it could be accessed by
the ModuleSummaryIndex builder which lives in lib/Analysis. I also
constified the Function parameter.

  • I'm not really happy with the way I hacked up checkFunctionMemoryAccess.

If the new map pointer is non-null, it puts the info for each call site
in the map rather than affecting the return value. I feel this could
probably be refactored in a cleaner way.

  • I have defaulted the new CalleeInfo field (for the call edges) to

the least conservative setting, so that I can update it by taking
the max. This should be ok since the only time we wouldn't update it
is if it has no calls or we don't have an AAResult object passed
into the summary builder. In that latter case, we set the function
attributes in the index based on the function attributes on the
Function, which would already be conservative, so it should be ok.
But it would probably be clearer to have an "Unknown" setting and
init to that.

Event Timeline

tejohnson created this revision.Aug 18 2017, 6:13 PM
davide edited edge metadata.Aug 19 2017, 9:34 AM

I'm OK with the direction, Teresa, thanks.
If Charles wants to pursue this path before the GSoC ends, that will be great.

ncharlie edited edge metadata.Aug 19 2017, 3:35 PM

I'm OK with the direction, Teresa, thanks.
If Charles wants to pursue this path before the GSoC ends, that will be great.

Yeah, I definitely like this approach better than what I had written. I can address the TODOs and clean it up a bit on Monday?

I'm OK with the direction, Teresa, thanks.
If Charles wants to pursue this path before the GSoC ends, that will be great.

Yeah, I definitely like this approach better than what I had written. I can address the TODOs and clean it up a bit on Monday?

Sure! I may add a couple comments before then with some cleanup ideas.

mehdi_amini added inline comments.Aug 20 2017, 10:33 AM
include/llvm/IR/ModuleSummaryIndex.h
300

What about "LocalReadNone"? It reminds me the "local_unnamed_addr" attribute.

I added bitcode read/write support and updated all the tests so they use the new bitcode. I was planning on waiting for a bit more feedback on this patch (and updating mine with the requested changes), but I can post mine whenever you want to move the discussion to llvm-commits.

I added bitcode read/write support and updated all the tests so they use the new bitcode. I was planning on waiting for a bit more feedback on this patch (and updating mine with the requested changes), but I can post mine whenever you want to move the discussion to llvm-commits.

Awesome! Why don't you go ahead and post it to llvm-commits and we can continue with a more formal review. Thanks.