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.
What about "LocalReadNone"? It reminds me the "local_unnamed_addr" attribute.