{"push_id":615990127,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"2be4145838d0603c1bfa51b4d4902b81703409da","before":"784f6c69850f21e457a989523564ba64123879e6","commits":[{"sha":"2be4145838d0603c1bfa51b4d4902b81703409da","author":{"email":"cdca4787270da064010d22babbd4b763d61bcde5@gmail.com","name":"Ahmed Bougacha"},"message":"[CodeGen] \"PromoteInteger\" f32 to f64 doesn't make sense.\n\nThe original f32->f64 promotion logic was refactored into roughly the\ncurrently shape in r37781. However, starting with r132263, the\nlegalizer has been split into different kinds, and the previous\n\"Promote\" (which did the right thing) was search-and-replace'd into\n\"PromoteInteger\". The divide gradually deepened, with type legalization\n(\"PromoteInteger\") being separated from ops legalization\n(\"Promote\", which still works for floating point ops).\n\nFast-forward to today: there's no in-tree target with legal f64 but\nillegal f32 (rather: no tests were harmed in the making of this patch).\n\nWith such a target, i.e., if you trick the legalizer into going through\nthe PromoteInteger path for FP, you get the expected brokenness.\nFor instance, there's no PromoteIntRes_FADD (the name itself sounds\nwrong), so we'll just hit some assert in the PromoteInteger path.\n\nDon't pretend we can promote f32 to f64. Instead, always soften.\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233464 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/earl/llvm-mirror/commits/2be4145838d0603c1bfa51b4d4902b81703409da"}]}