================
@@ -1035,6 +1043,13 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
}
+ // Re-link against any bitcodes supplied via the -mlink-builtin-bitcode
option
+ // Some optimizations may generate new function calls that would not have
+ // been linked pre-optimization (i.e. fused sincos calls generated by
+ // AMDGPULibCalls::fold_sincos.)
+ if (ClRelinkBuiltinBitcodePostop)
----------------
lamb-j wrote:
I did look into having a file-specific option to link specific bitcodes
post-optimization, and I think it is a good idea overall.
It is possible to come up with a specific set of bitcodes that need to be
re-linked, based on the current optimizations we've implemented that introduce
undefined functions. And we could then specify that set for a file-specific
post-optimization linking.
But there are some downsides:
- Any users would also need to know the specific set of bitcodes needed for
post-optimization linking
- We may need to hardcode that list in a bunch of different places, both
within LLVM and external APIs
- If a new optimization is implemented that expands the set of bitcodes
needed for post-optimization linking, we'd need to go around and update any
place that uses the file-specific options
Given that, I think the boolean relink option may serve us better for the time
being
https://github.com/llvm/llvm-project/pull/69371
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
