Some functions has available_external linkage type and with definition (instead of declaration) and SpecPriv will go inside and add profile calls. However, this functions will not be codegened since they are external library calls. The available_external allows inlining and other analysis/opts to know what’s inside.
Problem
SpecPriv doesn't understand this information and will try to modify the function by adding profiling calls (might applies to LAMP too). This is problematic because the instrumented code will be discarded during codegen.
@sapostolakis comments
In terms of planning it might be also better to interpret the linkage type and if the function is pure/local/semi-local avoid going into it. For functions with cross-iter deps it should be profitable to go inside. In general, it might be useful to link all external functions with this linkage and have a unified approach
that will justify better the use of profile-guided devirt
that requires full visibility
Actions
[ ] Fix SpecPriv by first treating functions with available_external type as external functions (which is true)
[ ] Figure out a way to first use attributes then inlining if failed to best leverage this opportunity
Overview
Some functions has
available_externallinkage type and with definition (instead of declaration) and SpecPriv will go inside and add profile calls. However, this functions will not be codegened since they are external library calls. The available_external allows inlining and other analysis/opts to know what’s inside.Problem
SpecPriv doesn't understand this information and will try to modify the function by adding profiling calls (might applies to LAMP too). This is problematic because the instrumented code will be discarded during codegen.
Actions