<html><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"></head><body
 bgcolor="#FFFFFF" text="#000000">
Hello Devs,<br>
  <br>
I've started thinking about the implementation of 
<a class="moz-txt-link-freetext" href="https://github.com/ghc-proposals/ghc-proposals/pull/182">https://github.com/ghc-proposals/ghc-proposals/pull/182</a> recently. (<span
 class="js-issue-title" style="box-sizing: border-box;">Add control flow
 hint pragmas.)</span><br>
  <br>
For this purpose I've rebased <span style="color: rgb(70, 76, 92); 
font-family: "Segoe UI", "Segoe UI Emoji", 
"Segoe UI Symbol", Lato, "Helvetica Neue", 
Helvetica, Arial, sans-serif; font-size: 13px; font-style: normal; 
font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 
700; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 
0px; text-transform: none; white-space: nowrap; widows: 2; word-spacing:
 0px; -webkit-text-stroke-width: 0px; background-color: rgb(243, 245, 
247); text-decoration-style: initial; text-decoration-color: initial; 
display: inline !important; float: none;">D4327 </span>"WIP: Add 
likelyhood to alternatives from stg onwards" which already does a lot of
 the work at the Cmm/Stg level.<br>
  <br>
The issue I ask you for feedback now is how to best attach branch 
weights to case alternatives in core.<br>
  <br>
My prefered approach would be to expand core data types to include them 
unconditionally. <br>
While this is quite far reaching in the amount of code it touches it 
would be rather straight forward to implement:<br>
  <br>
Alternative 1: Putting the weights directly into the case alternative 
tuple:<br>
+ It it's trivial to check which places manipulate case alternatives as 
they will initially fail to compile.<br>
+ It's very mechanical, almost all use sites won't actually change the 
weight.<br>
+ It's easy to keep this working going forward as any new optimizations 
can't "forget" they have to consider them.<br>
- It will introduce a cost in compiler performance.<br>
- New optimization who don't have to care about branchweights still have
 to at least pipe them through.<br>
- While syntactically heavy in terms of real complexity it's a simply 
approach.<br>
  <br>
Alternative 2:  Putting the weights into the case constructor.<br>
+ Might give better compiler performance as I expect us to rebuild cases
 less often than alternatives.<br>
- Seems kind of clunky.<br>
- Weaker coupling between case alternatives and their weights.<br>
  <br>
Or we could use ticks:<br>
+ There is some machinery already there<br>
+ Can be turned off for -O0<br>
+ Can be ignored when convenient.<br>
- Can be ignored when convenient.<br>
- Very weak coupling between case alternatives and their weights.<br>
- The existing machinery doesn't exactly match the needs of this.<br>
- We would have to extend tick semantics to a degree where complexity 
might grow too large<br>
  for me to successfully implement this.<br>
- If new optimizations end up just removing these ticks because they are
 allowed to  then<br>
  the whole exercise becomes rather pointless.<br>
- Makes it harder to ensure all relevant code paths in GHC are actually 
updated. <br>
  <br>
In particular there is currently no tick category which can stick to 
case alternatives but just get's removed in case<br>
it get's in the way of optimizations.<br>
The closest match is SoftScope which allows ticks to be floated up, 
something that could impact performance quite badly<br>
in this case. As then we might float something intended to mark a branch
 as unlikely into another branch that is actually<br>
along the hot path.<br>
  <br>
I think the core variant(s) mostly stand and fall with the actual 
compile time impact. For -O0 the impact<br>

would be negligible as the compile time is already dominated by codegen 
and typechecking. For the rest<br>

it's hard to say.<br>
  <br>
So I'm looking for feedback on this. Maybe you have other suggestions I 
haven't considered?<br>
How much compile time cost increase would be acceptable for what kind of
 performance boost?<br>
  <br>
Cheers,<br>
Andreas Klebinger<br>
</body>
</html>