search for: wo_patch

...t all with your change is that ISel has a longstanding issue where it can't conclude that the upper half of zext i32 %x to i64 is zero if the zext is in a different block from the user of the zext. -Eli -------------- next part -------------- A non-text attachment was scrubbed... Name: test2.s.wo_patch.arm Type: application/octet-stream Size: 447 bytes Desc: test2.s.wo_patch.arm URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110314/3e93ccc4/attachment.obj> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test2.c URL: <ht...

On Sun, Mar 13, 2011 at 5:01 PM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64,

...d... Name: test.s.patch.x86_32 Type: application/octet-stream Size: 2075 bytes Desc: test.s.patch.x86_32 URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110313/71c8b9cc/attachment-0002.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: test.s.wo_patch.arm Type: application/octet-stream Size: 1102 bytes Desc: test.s.wo_patch.arm URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110313/71c8b9cc/attachment-0003.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: test.s.wo_patch.x86_32 Type: appl...