[EXTERNAL] Unexpected duplicate join points in "Core" output?

[Viktor Dukhovni]

On Wed, Nov 24, 2021 at 06:32:04PM -0500, Viktor Dukhovni wrote:

> > Yes exactly. And it would not be hard to adapt the existing CSE pass
> > to support this.  Just needs doing.
> > 
> > A ticket and a repo case would be really helpful.
> 
> I'll do my best to construct a standalone reproducer that is not mired
> in ByteString code.  The ByteString example should not be too difficult
> to mimmic in code that relies only on base.

Just noticed a complication, it seems that the placemnt of the IO state
token in the join point argument list is non-deterministic, so I'm
starting to see join points in which the argument lists are permuted,
with an equivalent permutation at the jump/call site... :-(

Two exit points returning equivalent data, the first returns early,
the second returns after first performing some I/O:

        return $ Result valid acc (ptr `minusPtr` start)

become respectively (ipv2 and w3 are IO state tokens):

        1. jump exit2 ww4 ww5 valid ipv2
                   -- acc ptr valid s#
        2. jump exit3 ww4 ww5 w3 valid
                   -- acc ptr s# valid

So the join points are then only alpha equivalent up to argument
permutation:

      join {
        exit2 :: Word# -> Addr# -> Bool -> State# RealWorld -> Maybe (Int, ByteString)
        exit2 (ww4 :: Word#) (ww5 :: Addr#) (valid :: Bool) (ipv2 :: State# RealWorld)
          = ...

      join {
        exit3 :: Word# -> Addr# -> State# RealWorld -> Bool -> Maybe (Int, ByteString)
        exit3 (ww4 :: Word#) (ww5 :: Addr#) (w2 :: State# RealWorld) (valid :: Bool)
          = ...

I don't how argument lists to join points are ordered, would it be
possible to make them predictably consistent?

-- 
    Viktor.