[llvm-dev] Redundant promotion of integer values in x86 target

[Sanjay Patel via llvm-dev]

Hi Taewook -

There's a discussion about the underlying x86 micro-arch details here:
http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/167221

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

There are open bugs with more discussion related to this:
https://llvm.org/bugs/show_bug.cgi?id=17113
https://llvm.org/bugs/show_bug.cgi?id=22473
https://llvm.org/bugs/show_bug.cgi?id=22532
https://llvm.org/bugs/show_bug.cgi?id=23155  (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> 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160131/378d7088/attachment.html>