================
@@ -1688,6 +1688,11 @@ def fprofile_sample_accurate : Flag<["-"],
"fprofile-sample-accurate">,
as cold. Otherwise, treat callsites without profile samples as
if
we have no profile}]>,
MarshallingInfoFlag<CodeGenOpts<"ProfileSampleAccurate">>;
+def fpropeller_profile_use_EQ : Joined<["-"], "fpropeller-profile-use=">,
+ Group<f_Group>, Visibility<[ClangOption, CC1Option, CLOption]>,
+ MetaVarName<"<pathname>">,
----------------
tmsri wrote:
So, we want :
1. Another option to expose raw propeller profiles, MBB hashes and counts to
the compiler.
2. It would be mutually exclusive to -fbasic-block-sections=list options
I want to have a discussion on how much of a maintenance burden this would
cause. This is because Propeller will now do code layout in two different
ways. With stale profiles, the compiler will do it. By default, the offline
tool would do it. For future optimizations, we need to figure out how to
support two paths. @rlavaee @shenhanc78
Can we expose raw profiles using -fbasic-blocks-sections=list= itself? Do we
need a new option? I like the stale profile matching ideas but I am not sure
adding a new flag and a new file is the way to go forward.
https://github.com/llvm/llvm-project/pull/139008
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits