claus.reinke:
Here is a trivial example with drastic difference between T = Int and T = Word (~2.5x here):
main = print $ foldl' (+) 0 [1..100000000::T] .. GHC.Prim.word2Int# (GHC.Prim.and# (GHC.Prim.int2Word# wild13_XbE) (GHC.Prim.int2Word# y#_a4EZ))
Is that likely to cost me a lot or are these conversions cheap?
Those guys are no-ops, and in general you should never see a performance difference. If you do, it is a bug! There are some known cases where rules are missing however:
Thanks, that is one thing less to worry about. Btw, is there a "guide to reading Core" somewhere, with emphasis on performance aspects (what to look for when optimizing time or space usage, what to ignore, how to make it more readable, etc)?
Until I stumbled over CORE annotations, I found it near impossible even to find the pieces of interest for non-trivial programs, things like -dsuppress-uniques help a little with diffs, some things look big but are noops, etc. - that kind of helpful pragmatic knowledge (why does it look as if source variable names aren't always preserved; why does it use random uniques instead of de Bruijn-style disambiguation, which wouldn't interfere with diffs and would have static semantic content; why do the outputs look different for core2core vs dump-simpl, ..).
Some others I'm aware of are product/sum/maximum/minimum on lists have specialisations for some atomic types (Int, Integer) but not all (needs a ticket for this too).
A quick grep shows almost no specialization at all for Word, or for IntXX/WordXX (see below). Still, none of that seems to explain the example repeated at the top of this message.
We do need to decide on if we want to add specializations for all atomic types in general, and if so, then let'd do that intentionally. Does anyone see a reason not to do it in the libraries, via rules?