You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The optforfuzzing option(s) should be dropped completely.
The minsize, optsize, noinline, alwaysinline options all seem like they might be worth tuning for the individual functions in the tuning section. Thus, the attributes if present can serve as defaults and tuning can play with those options.
The inlinehint option primarily controls which threshold value the inliner should use in its cost model. It could useful to leave these this alone if they appear and have the tuner play with the inliner's hinted-threshold value to see what threshold should be used for that subset of the code. Alternatively, we can make this a tunable flag to set on functions ourselves (randomly or based on some heuristic, etc) so the tuner can use a different threshold for a subset of funcs. In both cases, this is a smarter / less direct way of tuning via noinline/alwaysinline.
Online profiling data can allow us to detect cold functions. This attribute places the function into another inlining threshold class too (among other optimizations). It might be fine to just trust our metric for determining a 'cold' function based on the data and place the attribute directly in the code periodically.
The text was updated successfully, but these errors were encountered:
The
optforfuzzing
option(s) should be dropped completely.The
minsize
,optsize
,noinline
,alwaysinline
options all seem like they might be worth tuning for the individual functions in the tuning section. Thus, the attributes if present can serve as defaults and tuning can play with those options.The
inlinehint
option primarily controls which threshold value the inliner should use in its cost model. It could useful to leave these this alone if they appear and have the tuner play with the inliner's hinted-threshold value to see what threshold should be used for that subset of the code. Alternatively, we can make this a tunable flag to set on functions ourselves (randomly or based on some heuristic, etc) so the tuner can use a different threshold for a subset of funcs. In both cases, this is a smarter / less direct way of tuning vianoinline
/alwaysinline
.Online profiling data can allow us to detect
cold
functions. This attribute places the function into another inlining threshold class too (among other optimizations). It might be fine to just trust our metric for determining a 'cold' function based on the data and place the attribute directly in the code periodically.The text was updated successfully, but these errors were encountered: