Differential D145762
Reduce inlining that had larger binary size impact Authored by jpienaar on Mar 9 2023, 8:37 PM.
Details
On a build with a large number of registered operations this resulted in These were found to reduce the size but this change is RFC (it contains changes
Diff Detail
Event TimelineComment Actions
I don’t know how to interpret this without the total binary size, what is the percentage? Comment Actions In general I am quite concerned about messing with the optimizer this way, this should be extremely exceptional. This'll be ad-hoc, forces a performance tradeoff specific to a given use case, and couple the "heuristic" to the exact compiler you're using (what does it do on Windows? On Mac?).
Comment Actions The total binary size is relevant for user to decide which part they want to optimize and that's where biggest impact will be by doing more application specific removal. But here I'm more interested in the MLIR parts as this reduction corresponds to ~30% of total MLIR codesize (filtering on any file with mlir in it) in the original binary rather than caring about this specific binary. Performance tradeoff wrt debugging and error case was what I wanted to discuss (these were programmatically identified but I don't think all would make sense). I agree that if pure size is goal it's one thing, but these are intended to be performance optimized binaries in general. The debugging or error case seems not specific, inlining vs function call for these paths trades size for speed in exceptional paths. This is similar to me to where we document expectations around verification in production runs, it's just in code :-). PGO would be able to change the heuristic either way wouldn't it? E.g., having the default of the error/debugging cases be marked as cold. | ||||||||||