Draft: Zap coercions in the rewriter
Sad about stalling in !6476, I have made my own attempt, after a short brainstorming session with @simonpj and having learned from @sheaf's attempts.
This zaps coercions right in the rewriter. It does repeat a fair bit of code. There may be an opportunity for improvement. Right now, I'm curious about performance. Note that this initial version unconditionally uses zapped coercions in the rewriter; a future version would have users choose via a compilation switch.
Meant to fix #8095.
Merge request reports
Activity
added 1 commit
- 6b282ba2 - Zonk coercion holes correctly; a few other fixes.
Great, so this implements what I called "using zapped nullicoercions in the rewriter" on this wiki page. I currently think this is the best way to zap, so it'll be good to have an implementation of that approach.
Edited by sheafHere's what I get from a quick local benchmark:
test (ghc/alloc) HEAD !7787 dco+zap !7844 zap co !7909 zap nullico CoOpt_Singletons 984,469,440 1,992,914,08 8 1,843,420,584 1,893,364,224 LargeRecord 6,140,072,220 3,327,980,336 2,191,354,760 2,443,273,032 T12227 479,779,040 293,555,520 267,812,024 466,179,792 T13386 887,913,392 40,795,392 46,132,320 129,782,624 T15703 532,192,308 390,545,584 1,148,686,400 563,038,032 T16577 7,588,794,744 7,961,537,664 7,841,667,048 8,476,694,432 T18223 1,119,964,672 1,142,598,536 1,132,690,904 1,208,041,064 T5030 356,224,592 103,302,512 105,683,712 188,566,408 T5642 471,947,420 493,938,064 490,058,416 670,154,640 T8095 3,257,820,628 186,612,624 526,866,304 347,718,472 T9630 1,551,652,176 1,585,077,800 1,610,447,440 2,761,169,976 T9872a 1,787,159,152 1,928,660,896 578,369,176 1,960,547,712 T9872b 2,082,232,304 2,214,371,392 761,973,416 2,147,363,536 T9872b_defer 3,153,955,252 2,282,802,240 4,174,971,640 2,165,350,440 T9872c 1,728,876,064 1,877,569,608 560,414,352 1,931,343,528 T9872d 449,285,296 425,046,152 834,352,192 404,205,080 Edited by sheaf
