I haven't seen any announcement about this and only found out when I saw that my stupid non-Int64 submission 137642072 to problem C in today's round didn't fail pretests. But maybe some of you would like to know.

Performance-wise, I think it's probably a nice win for some problems but not that significant overall. The convenience of not having to import Int64 and fiddle with explicit conversions or so frequently ask myself if one of the 'unimportant' constraints I don't have at top-of-mind will cause Int overflow will definitely be appreciated, though.

On the plus side: Arithmetic with large integers is presumably 2-3x faster now. Also, in my experience, Int64-related class methods often lack the performant specializations and rewrite rules available for their Int counterparts, and Int64 values tend to be unboxed less aggressively on 32-bit systems, all of which made awkward using efficiently the type. GHC's pointer-tagging magic will also probably work better for some types now, but I think this is uncommon.

On the minus side: The higher memory use that comes with 64-bit is probably relatively pronounced with Haskell. Typically, only ByteString and UArray contents (and similar) are actually stored in a packed unboxed format, and these are quite limited in what they can store. (StorableArray is more flexible in this regard, but it doesn't come shipped with an immutable wrapper, so it's inconvenient to use outside of an IO context. And unboxed Vectors are just not available on Codeforces for now.) GHC prior to 9.2.1 doesn't have any built-in support for user-defined fields smaller than the machine word size, so almost everything else will double in size. (And the same goes if your UArrays are storing Int instead of Int32.)

Thanks to the Codeforces team for making this happen!