{"push_id":811258624,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"410e6c01c9cf65fd6050a08ae08eb2168586b9b9","before":"60c2dcce8cf55b572b0be84a9d7b707339dcc1a0","commits":[{"sha":"410e6c01c9cf65fd6050a08ae08eb2168586b9b9","author":{"email":"cdca4787270da064010d22babbd4b763d61bcde5@gmail.com","name":"Ahmed Bougacha"},"message":"[X86] Don't custom-lower vNi32 uint_to_fp when unsafe-fp-math.\n\nThe custom code produces incorrect results if later reassociated.\n\nSince r221657, on x86, vNi32 uitofp is lowered using an optimized\nsequence:\n\n  movdqa LCPI0_0(%rip), %xmm1 ## xmm1 = [65535, ...]\n  pand %xmm0, %xmm1\n  por LCPI0_1(%rip), %xmm1 ## [0x4b000000, ...]\n  psrld $16, %xmm0\n  por LCPI0_2(%rip), %xmm0 ## [0x53000000, ...]\n  addps LCPI0_3(%rip), %xmm0 ## [float -5.497642e+11, ...]\n  addps %xmm1, %xmm0\n\nSince r240361, the machine combiner opportunistically reassociates\n2-instruction sequences (with -ffast-math). In the new code sequence,\nthe ADDPS' are eligible. In isolation, for simple examples (without\nreassociable users), this makes no performance difference (the goal\nbeing to enable reassociation of longer chains).\n\nIn the trivial example (just one uitofp), the reassociation doesn't\nhappen, because (I think) it would require the emission of a separate\nmovaps for a constantpool load (instead of folding it into addps).\n\nHowever, when we have multiple uitofp sequences, and the constantpool\nloads are CSE'd earlier, the machine combiner can do the reassociation.\n\nWhen the ADDPS' are reassociated, the resulting sequence isn't correct\nanymore, as we'd be adding large (2**39) constants with comparatively\nsmaller values (~2**23). Given that two of the three inputs are powers\nof 2 larger than 2**16, and that ulp(2**39) == 2**(39-24) == 2**15,\nthe reassociated chain will produce 0 for any input in [0, 2**14[.\nIn my testing, it also produces wrong results for 99.5% of [0, 2**32[.\n\nAvoid this by disabling the new lowering when -ffast-math. It does\nmean that we'll get slower code than without it, but at least we\nwon't get egregiously incorrect code.\n\nOne might argue that, considering -ffast-math is all but meaningless,\nuitofp producing wrong results isn't a compiler bug. But it really is.\n\nFixes PR24512.\n\n...though this is really more of a workaround.\nIdeally, we'd have some sort of Machine FMF, but that's a problem\nthat's not worth tackling until we do more with machine IR.","distinct":true,"url":"https://api.github.com/repos/llvm-project/llvm-project/commits/410e6c01c9cf65fd6050a08ae08eb2168586b9b9"}]}