Fix (bitcast (fabs x)), (bitcast (fneg x)) and (bitcast (fcopysign cst, x)) combines for ppc_fp128, since signbit computation is more complicated.
Discussion thread: http://lists.llvm.org/pipermail/llvm-dev/2015-November/092863.html
Differential D15138
Fix signbit related bitcast optimization for ppc_fp128 timshen on Dec 1 2015, 6:44 PM. Authored by
Details Fix (bitcast (fabs x)), (bitcast (fneg x)) and (bitcast (fcopysign cst, x)) combines for ppc_fp128, since signbit computation is more complicated. Discussion thread: http://lists.llvm.org/pipermail/llvm-dev/2015-November/092863.html
Diff Detail Event TimelineComment Actions Is the code generation for ppc_fp128 better this way? If not, please actually fix the problem. If so: 1) please specifically test (in the regression test) for the better code generation and 2) make the change specific to ppc_fp128 [doing this for all illegal types is not good because on soft-float implementations this is still useful even though the types are illegal]. Comment Actions The code generation for ppc_fp128 better, since it's originally wrong and now correct. Changed checks to pin down the exact correct behavior. Comment Actions One of the things that I really like about working on LLVM is that It is the general philosophy of this project not to simply disable optimizations in otherwise-broken corner cases, but to properly fix them. Obviously this is not always practical, but it certainly is in this case. Please prototype a fix which generates the correct mask for ppc_fp128 and compare the resulting code quality. If you don't wish to do this, please let me know, and I (or someone else who works on PowerPC here) will do it for you. Also, please upload your patches with full context. See http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface for instructions. Comment Actions I have updated the combiners, with these optimizations correctly implemented. Compared to disabling these optimizations: Links to the actual assembly code: Comment Actions I'm not sure if we should keep fabs & fneg combiners. I kept them in the updated patch just as part of the investigation result. Comment Actions Thanks for continuing to work on this! The EXTRACT_ELEMENT index is Endian sensitive in this case, right? I suspect you need to use index 1 for big-Endian targets.
Comment Actions I've gone ahead and committed this here: dzur:~/sources/llvm> git svn dcommit |
I think you need a check for !LegalTypes here because EXTRACT_ELEMENT should only be used prior to legalization, and i64 might not be legal (if you're compiling for ppc32).