-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, I'd like to ask for some advise about optimization passes. Which pass might be responsible for this LLVM IR and why? %0 = load i288* bitcast ([9 x i32]* @array to i288*), align 16 %1 = lshr i288 %0, 224 array is just a global constant array of 9 integers and the code only accesses individual elements. The LLVM version is 3.1. Thanks, Mario -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP+IurAAoJEDv0fP6GapNt728H/1FxnzvXMUMNVxaKWKKNLd1Z BHyYbzDEGXD8DncBSyEj3XpccuEqXvVgjFBUKG5oCw7nQlSbmEipWDvVyM1nzVL0 VwKjmMmIyDDpxzN2rYz2vttbCOrAMcbwNsbaSnf+rXYHytezWnGN1jAZwV/Zx2wL w3x7mcQUMaPg0Wf9jUXzWgEip9/CuY6gqqpjwMEzTp2Vbl0ZF6z67TE+An5aeY7H tEwgOLYhsXqIN4SyqBCD8MCWhTZvH/TWQWWFuxik8E82QDno+Bz1QZOKWDFO+SWw cTfumInVRhuMSZj4WWMQibuakAvHvHx2Z92+oQQ38vSRPAS7IC72itZcbgXcEio=P7eZ -----END PGP SIGNATURE-----
The Scalar Replacement of Aggregates pass (-scalarrepl) generates these big integers. We recently added a constructor parameter to limit the size of the wide integer loads. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Mario Schwalbe Sent: Saturday, July 07, 2012 22:19 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Large integers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, I'd like to ask for some advise about optimization passes. Which pass might be responsible for this LLVM IR and why? %0 = load i288* bitcast ([9 x i32]* @array to i288*), align 16 %1 = lshr i288 %0, 224 array is just a global constant array of 9 integers and the code only accesses individual elements. The LLVM version is 3.1. Thanks, Mario -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP+IurAAoJEDv0fP6GapNt728H/1FxnzvXMUMNVxaKWKKNLd1Z BHyYbzDEGXD8DncBSyEj3XpccuEqXvVgjFBUKG5oCw7nQlSbmEipWDvVyM1nzVL0 VwKjmMmIyDDpxzN2rYz2vttbCOrAMcbwNsbaSnf+rXYHytezWnGN1jAZwV/Zx2wL w3x7mcQUMaPg0Wf9jUXzWgEip9/CuY6gqqpjwMEzTp2Vbl0ZF6z67TE+An5aeY7H tEwgOLYhsXqIN4SyqBCD8MCWhTZvH/TWQWWFuxik8E82QDno+Bz1QZOKWDFO+SWw cTfumInVRhuMSZj4WWMQibuakAvHvHx2Z92+oQQ38vSRPAS7IC72itZcbgXcEio=P7eZ -----END PGP SIGNATURE----- _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 07.07.2012 21:39, schrieb Rotem, Nadav:> The Scalar Replacement of Aggregates pass (-scalarrepl) generates these big integers. We recently added a constructor parameter to limit the size of the wide integer loads.Is it the Threshold parameter or are you referring to LLVM trunk? Besides that I (a) made sure both scalar replacement passes aren't added to the pass manager, and (b) put a debug message into SROA::runOnFunction(), SROA::performScalarRepl(), and SROA::performPromotion() (in ScalarReplAggregates.cpp) to check whether one of them is being called. Definitely not. But I still get the same result. So is there maybe any other pass that directly creates such code and/or indirectly causes some scalar replacement code to be invoked. Thanks and ciao, Mario -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP+XjCAAoJEDv0fP6GapNtDEwH/1VrTeKbtcC1P4ORTq1d6HfA vkqolZkoqsBri//V3nreI+zSJ/esD3xueErtyJ/+4DndqqEy9rVpRUf95bk6LT2K g+aR/moXcjROsFqdaLVDVejxEvhI1+wWvDOOP97Yg1wTJQUBmRHPRdE5cdNtoOR+ Wm/4fg/ggQ3FP3/7MwfOirUdu17XDEiiyCYrtYPtFlBSWOhjP3qVvX3tmMGjU+Wr /z3/f2a7gUQomcaXITWlKzTL3S0jt2WXD+rO74Lc9LSusF6+XjBrYcN7P+6qB0cp UFJjxhthRhNKMY115gqoDGIULtgV+z5+HrFjkFMiGFxmwVt6aNXqfCXOIspj9lo=ou1y -----END PGP SIGNATURE-----