Good day LLVM-Dev, I hope all are in good health. We are currently implementing the compare operation for i64 type in our target. The main difference of the i64 type compare to lower integer types is that it performs a library call instead of generating a compare instruction. All is good until before ISelDAGToDAG class. We have observed that the difference in a compare operation for i32 and i64 types is that, the 4th DAG node of the BRCOND node is glued for the i32 type and not glued in the i64 type. Please refer to the boxed nodes in the attached DAGs for a better visualization. Also, upon entering the ISelDAGToDAG class, the i64 type compare library call operation disappeared. I suspect that some optimization between Legalization and ISelDAGToDAG is removing the library call. The compare operation does not have an ISD opcode, only a target specific ISD opcode, which makes it hard to identify where it is being changed in the target independent source code. Does anybody know which class between Legalization and ISelDAGToDAG we should look into for this problem? Any kind of information may help. Also, are there other targets which does a library call for compare operations? This would greatly help us in our study. Thank you very much in advance! Stay healthy, stay [COVID-19] negative. Sincerely, Miguel Inigo J. Manalac JAPANESE: ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ENGLISH: This e-mail is intended for the person(s) to which it is addressed. If you have received it by mistake, please notify the sender and delete the received email. In addition, our company shall not assume any responsibility even if it causes any inconvenience, such as loss of mail, inconsistencies, delays, etc., due to the inclusion of computer viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200417/8672e741/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: i32_compare_before_isel.pdf Type: application/pdf Size: 48015 bytes Desc: i32_compare_before_isel.pdf URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200417/8672e741/attachment-0002.pdf> -------------- next part -------------- A non-text attachment was scrubbed... Name: i64_compare_before_isel.pdf Type: application/pdf Size: 56466 bytes Desc: i64_compare_before_isel.pdf URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200417/8672e741/attachment-0003.pdf>
Good day LLVM-Dev, I hope all are in good health. We are currently implementing the compare operation for i64 type in our target. The main difference of the i64 type compare to lower integer types is that it performs a library call instead of generating a compare instruction. All is good until before ISelDAGToDAG class. We have observed that the difference in a compare operation for i32 and i64 types is that, the 4th DAG node of the BRCOND node is glued for the i32 type and not glued in the i64 type. Please refer to the DAG nodes in the attached files for a better visualization (Sorry cant attach the whole DAG due to 100kb mailing limit). Also, upon entering the ISelDAGToDAG class, the i64 type compare library call operation disappeared. I suspect that some optimization between Legalization and ISelDAGToDAG is removing the library call. The compare operation does not have an ISD opcode, only a target specific ISD opcode, which makes it hard to identify where it is being changed in the target independent source code. Does anybody know which class between Legalization and ISelDAGToDAG we should look into for this problem? Any kind of information may help. Also, are there other targets which does a library call for compare operations? This would greatly help us in our study. Thank you very much in advance! Stay healthy, stay [COVID-19] negative. Sincerely, Miguel Inigo J. Manalac JAPANESE: ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ENGLISH: This e-mail is intended for the person(s) to which it is addressed. If you have received it by mistake, please notify the sender and delete the received email. In addition, our company shall not assume any responsibility even if it causes any inconvenience, such as loss of mail, inconsistencies, delays, etc., due to the inclusion of computer viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200417/b4201f59/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: i32_cmp_before_isel.JPG Type: image/jpeg Size: 18991 bytes Desc: i32_cmp_before_isel.JPG URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200417/b4201f59/attachment-0002.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: i64_cmp_before_isel.JPG Type: image/jpeg Size: 43512 bytes Desc: i64_cmp_before_isel.JPG URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200417/b4201f59/attachment-0003.jpe>