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.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
