[EXTERNAL] Unexpected duplicate join points in "Core" output?
Viktor Dukhovni
ietf-dane at dukhovni.org
Thu Nov 25 02:43:54 UTC 2021
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.
More information about the ghc-devs
mailing list