Taewook Oh via llvm-dev
2016-Feb-01 23:46 UTC
[llvm-dev] Redundant promotion of integer values in x86 target
Sanjay, Kevin, Thank you for your reply. Kevin, I wonder if you are still working on it and have a plan to submit your changes for the review. Thanks, Taewook From: "Smith, Kevin B" <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> Date: Monday, February 1, 2016 at 3:30 PM To: 'Sanjay Patel' <spatel at rotateright.com<mailto:spatel at rotateright.com>>, Taewook Oh <twoh at fb.com<mailto:twoh at fb.com>> Cc: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: RE: [llvm-dev] Redundant promotion of integer values in x86 target This is an excerpt from Chandler's comment in https://llvm.org/bugs/show_bug.cgi?id=22473<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22473&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=hdE0lOvbk0jqWq2vtN1X_3HLHfpvK-z49XSU3LyY6kU&e=> Ø We need to add a pass that replaces movb (and movw) with movzbl (and movzwl) when the destination is a register and the high bytes aren't used. I have created such a pass, and have it working in a local workspace of mine. However, I think that the way it attempts to prove that the high bytes aren't used is flawed, and so I haven't yet submitted it for community review. Kevin From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Sunday, January 31, 2016 9:57 AM To: Taewook Oh <twoh at fb.com<mailto:twoh at fb.com>> Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Smith, Kevin B <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> Subject: Re: [llvm-dev] Redundant promotion of integer values in x86 target Hi Taewook - There's a discussion about the underlying x86 micro-arch details here: http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/167221<https://urldefense.proofpoint.com/v2/url?u=http-3A__comments.gmane.org_gmane.comp.compilers.llvm.cvs_167221&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=GXM3c7BrHLhnmiVCIrEm9Kpa9mtVMbrW9G8HTTGUc0s&e=> The conclusion was that we should change how we currently handle these, but we don't want to regress the case that was addressed by: http://reviews.llvm.org/rL195496<https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL195496&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=_8T2G8KU33uBBq3_LkXZEnpzN3J8iKCF5Pg8vXHUPEw&e=> There are open bugs with more discussion related to this: https://llvm.org/bugs/show_bug.cgi?id=17113<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D17113&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=2mYbHl1QB1OzIdlzXfVpTlMJ_oGFldBZMKJ6_gmGtCY&e=> https://llvm.org/bugs/show_bug.cgi?id=22473<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22473&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=hdE0lOvbk0jqWq2vtN1X_3HLHfpvK-z49XSU3LyY6kU&e=> https://llvm.org/bugs/show_bug.cgi?id=22532<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22532&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=MMoQ-XntXWrnXU4kmdhnvXVhDiinxjSXiWQH8hcLA4w&e=> https://llvm.org/bugs/show_bug.cgi?id=23155<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23155&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=WXDoKPefpTQwCS3vsY8ki5faY2eURdKecODSZaKywlQ&e=> (cc'ing Kevin in case there's any update on this one) On Fri, Jan 29, 2016 at 10:04 PM, Taewook Oh via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello, While looking at some internal benchmarks, I found that llvm generates codes with redundant promotion, something like: xor %al, %cl movzbl %cl, %ecx cmp $0x20, %ecx I believe that the promotion stems from the logic in X86TargetLowering::EmitCmp. Comments in the code says, "Do the comparison at i32 if it's smaller, besides the Atom case. This avoids subregister aliasing issues. Keep the smaller reference if we're optimizing for size, however, as that'll allow better folding of memory operations." Can anybody please explain me more in detail about the subregister aliasing issues? Thanks, Taewook _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=SLs62ig3RuWWdvCIeqTpSLIkus8-NwvppqkNCTZATro&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/3671253a/attachment-0001.html>
Smith, Kevin B via llvm-dev
2016-Feb-01 23:56 UTC
[llvm-dev] Redundant promotion of integer values in x86 target
Yes, I am still working on it. I believe I have it conservatively correct. I suppose I should just go ahead and submit it with comments explaining why I think it is conservatively correct, and a TODO on what I think is actually required for complete generality. Kevin From: Taewook Oh [mailto:twoh at fb.com] Sent: Monday, February 01, 2016 3:46 PM To: Smith, Kevin B <kevin.b.smith at intel.com>; 'Sanjay Patel' <spatel at rotateright.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Redundant promotion of integer values in x86 target Sanjay, Kevin, Thank you for your reply. Kevin, I wonder if you are still working on it and have a plan to submit your changes for the review. Thanks, Taewook From: "Smith, Kevin B" <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> Date: Monday, February 1, 2016 at 3:30 PM To: 'Sanjay Patel' <spatel at rotateright.com<mailto:spatel at rotateright.com>>, Taewook Oh <twoh at fb.com<mailto:twoh at fb.com>> Cc: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: RE: [llvm-dev] Redundant promotion of integer values in x86 target This is an excerpt from Chandler's comment in https://llvm.org/bugs/show_bug.cgi?id=22473<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22473&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=hdE0lOvbk0jqWq2vtN1X_3HLHfpvK-z49XSU3LyY6kU&e=> ? We need to add a pass that replaces movb (and movw) with movzbl (and movzwl) when the destination is a register and the high bytes aren't used. I have created such a pass, and have it working in a local workspace of mine. However, I think that the way it attempts to prove that the high bytes aren't used is flawed, and so I haven't yet submitted it for community review. Kevin From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Sunday, January 31, 2016 9:57 AM To: Taewook Oh <twoh at fb.com<mailto:twoh at fb.com>> Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Smith, Kevin B <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> Subject: Re: [llvm-dev] Redundant promotion of integer values in x86 target Hi Taewook - There's a discussion about the underlying x86 micro-arch details here: http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/167221<https://urldefense.proofpoint.com/v2/url?u=http-3A__comments.gmane.org_gmane.comp.compilers.llvm.cvs_167221&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=GXM3c7BrHLhnmiVCIrEm9Kpa9mtVMbrW9G8HTTGUc0s&e=> The conclusion was that we should change how we currently handle these, but we don't want to regress the case that was addressed by: http://reviews.llvm.org/rL195496<https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL195496&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=_8T2G8KU33uBBq3_LkXZEnpzN3J8iKCF5Pg8vXHUPEw&e=> There are open bugs with more discussion related to this: https://llvm.org/bugs/show_bug.cgi?id=17113<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D17113&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=2mYbHl1QB1OzIdlzXfVpTlMJ_oGFldBZMKJ6_gmGtCY&e=> https://llvm.org/bugs/show_bug.cgi?id=22473<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22473&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=hdE0lOvbk0jqWq2vtN1X_3HLHfpvK-z49XSU3LyY6kU&e=> https://llvm.org/bugs/show_bug.cgi?id=22532<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22532&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=MMoQ-XntXWrnXU4kmdhnvXVhDiinxjSXiWQH8hcLA4w&e=> https://llvm.org/bugs/show_bug.cgi?id=23155<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23155&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=WXDoKPefpTQwCS3vsY8ki5faY2eURdKecODSZaKywlQ&e=> (cc'ing Kevin in case there's any update on this one) On Fri, Jan 29, 2016 at 10:04 PM, Taewook Oh via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello, While looking at some internal benchmarks, I found that llvm generates codes with redundant promotion, something like: xor %al, %cl movzbl %cl, %ecx cmp $0x20, %ecx I believe that the promotion stems from the logic in X86TargetLowering::EmitCmp. Comments in the code says, "Do the comparison at i32 if it's smaller, besides the Atom case. This avoids subregister aliasing issues. Keep the smaller reference if we're optimizing for size, however, as that'll allow better folding of memory operations." Can anybody please explain me more in detail about the subregister aliasing issues? Thanks, Taewook _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=SLs62ig3RuWWdvCIeqTpSLIkus8-NwvppqkNCTZATro&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/3388703a/attachment.html>
Taewook Oh via llvm-dev
2016-Feb-01 23:59 UTC
[llvm-dev] Redundant promotion of integer values in x86 target
Sounds great. Thanks! -- Taewook From: "Smith, Kevin B" <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> Date: Monday, February 1, 2016 at 3:56 PM To: Taewook Oh <twoh at fb.com<mailto:twoh at fb.com>>, 'Sanjay Patel' <spatel at rotateright.com<mailto:spatel at rotateright.com>> Cc: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: RE: [llvm-dev] Redundant promotion of integer values in x86 target Yes, I am still working on it. I believe I have it conservatively correct. I suppose I should just go ahead and submit it with comments explaining why I think it is conservatively correct, and a TODO on what I think is actually required for complete generality. Kevin From: Taewook Oh [mailto:twoh at fb.com] Sent: Monday, February 01, 2016 3:46 PM To: Smith, Kevin B <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>>; 'Sanjay Patel' <spatel at rotateright.com<mailto:spatel at rotateright.com>> Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Redundant promotion of integer values in x86 target Sanjay, Kevin, Thank you for your reply. Kevin, I wonder if you are still working on it and have a plan to submit your changes for the review. Thanks, Taewook From: "Smith, Kevin B" <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> Date: Monday, February 1, 2016 at 3:30 PM To: 'Sanjay Patel' <spatel at rotateright.com<mailto:spatel at rotateright.com>>, Taewook Oh <twoh at fb.com<mailto:twoh at fb.com>> Cc: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: RE: [llvm-dev] Redundant promotion of integer values in x86 target This is an excerpt from Chandler's comment in https://llvm.org/bugs/show_bug.cgi?id=22473<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22473&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=hdE0lOvbk0jqWq2vtN1X_3HLHfpvK-z49XSU3LyY6kU&e=> ?We need to add a pass that replaces movb (and movw) with movzbl (and movzwl) when the destination is a register and the high bytes aren't used. I have created such a pass, and have it working in a local workspace of mine. However, I think that the way it attempts to prove that the high bytes aren't used is flawed, and so I haven't yet submitted it for community review. Kevin From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Sunday, January 31, 2016 9:57 AM To: Taewook Oh <twoh at fb.com<mailto:twoh at fb.com>> Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Smith, Kevin B <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> Subject: Re: [llvm-dev] Redundant promotion of integer values in x86 target Hi Taewook - There's a discussion about the underlying x86 micro-arch details here: http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/167221<https://urldefense.proofpoint.com/v2/url?u=http-3A__comments.gmane.org_gmane.comp.compilers.llvm.cvs_167221&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=GXM3c7BrHLhnmiVCIrEm9Kpa9mtVMbrW9G8HTTGUc0s&e=> The conclusion was that we should change how we currently handle these, but we don't want to regress the case that was addressed by: http://reviews.llvm.org/rL195496<https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL195496&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=_8T2G8KU33uBBq3_LkXZEnpzN3J8iKCF5Pg8vXHUPEw&e=> There are open bugs with more discussion related to this: https://llvm.org/bugs/show_bug.cgi?id=17113<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D17113&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=2mYbHl1QB1OzIdlzXfVpTlMJ_oGFldBZMKJ6_gmGtCY&e=> https://llvm.org/bugs/show_bug.cgi?id=22473<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22473&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=hdE0lOvbk0jqWq2vtN1X_3HLHfpvK-z49XSU3LyY6kU&e=> https://llvm.org/bugs/show_bug.cgi?id=22532<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D22532&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=MMoQ-XntXWrnXU4kmdhnvXVhDiinxjSXiWQH8hcLA4w&e=> https://llvm.org/bugs/show_bug.cgi?id=23155<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23155&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=WXDoKPefpTQwCS3vsY8ki5faY2eURdKecODSZaKywlQ&e=> (cc'ing Kevin in case there's any update on this one) On Fri, Jan 29, 2016 at 10:04 PM, Taewook Oh via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello, While looking at some internal benchmarks, I found that llvm generates codes with redundant promotion, something like: xor %al, %cl movzbl %cl, %ecx cmp $0x20, %ecx I believe that the promotion stems from the logic in X86TargetLowering::EmitCmp. Comments in the code says, "Do the comparison at i32 if it's smaller, besides the Atom case. This avoids subregister aliasing issues. Keep the smaller reference if we're optimizing for size, however, as that'll allow better folding of memory operations." Can anybody please explain me more in detail about the subregister aliasing issues? Thanks, Taewook _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=CwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=4GlWLa5X3i08opHX4qEinKM5A85qGzRUacht2PVZxT8&s=SLs62ig3RuWWdvCIeqTpSLIkus8-NwvppqkNCTZATro&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/1407bdf9/attachment.html>