<div dir="ltr"><div><div>On several variants of x86 processors, mixing `ah`, `al` and `ax` as source/destination in the same dependency chain will have some penalties, so for THOSE processors, there is a benefit to NOT use `al` and `ah` to reflect parts of `ax` - I believe this is caused by the fact that the processor doesn't ACTUALLY see these as parts of a bigger register internally, and will execute two independent dependency chains, UNTIL you start using `ax` as one register. At this point, the processor has to make sure both of dependency chains for `al` and `ah` have been complete, and that the merged value is available in `ax`. If the processor uses `cl` and `al`, this sort of problem is avoided.<br><br></div><div><<Quote from Intel Optimisation guide, page 3-44<br><a href="http://www.intel.co.uk/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf">http://www.intel.co.uk/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf</a><br><br>A partial register stall happens when an instruction refers to a register, portions of<br>which were previously modified by other instructions. For example, partial register<br>stalls occurs with a read to AX while previous instructions stored AL and AH, or a read<br>to EAX while previous in<br>struction modified AX.<br>The delay of a partial register stall is small in processors based on Intel Core and<br>NetBurst microarchitectures, and in Pentium M processor (with CPUID signature<br>family 6, model 13), Intel Core Solo,<br>and Intel Core Duo processors. Pentium M<br>processors (CPUID signature with family 6,<br>model 9) and the P6 family incur a large<br>penalty.<br></div><div><<Enq quote>><br><br></div>So for compact code, yes, it's probably an advantage. For SOME processors in the x86 range, not so good for performance.<br><br></div><div>Whether LLVM has the information as to WHICH processor models have such penalties (or better yet, can determine the amount of time lost for this sort of operation), I'm not sure. It's obviously something that CAN be programmed into a compiler, it's just a matter of understanding the effort vs. reward factor for this particular type of optimisation, compared to other things that could be done to improve the quality of the code generated.<br></div><div><br>--<br></div>Mats<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 May 2016 at 17:09, Smith, Kevin B via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Try using x86 mode rather than Intel64 mode.  I have definitely gotten it to use both ah and al in 32 bit x86 code generation.<br>
In particular, I have seen that in loops for both the spec2000 and spec2006 versions of bzip.  It can happen, but it does only rarely.<br>
<br>
Kevin Smith<br>
<div class="HOEnZb"><div class="h5"><br>
>-----Original Message-----<br>
>From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of<br>
>Krzysztof Parzyszek via llvm-dev<br>
>Sent: Tuesday, May 24, 2016 8:04 AM<br>
>To: LLVM Dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
>Subject: [llvm-dev] Liveness of AL, AH and AX in x86 backend<br>
><br>
>I'm trying to see how the x86 backend deals with the relationship<br>
>between AL, AH and AX, but I can't get it to generate any code that<br>
>would expose an interesting scenario.<br>
><br>
>For example, I wrote this piece:<br>
><br>
>typedef struct {<br>
>   char x, y;<br>
>} struct_t;<br>
><br>
>struct_t z;<br>
><br>
>struct_t foo(char *p) {<br>
>   struct_t s;<br>
>   s.x = *p++;<br>
>   s.y = *p;<br>
>   z = s;<br>
>   s.x++;<br>
>   return s;<br>
>}<br>
><br>
>But the output at -O2 is<br>
><br>
>foo:                                    # @foo<br>
>         .cfi_startproc<br>
># BB#0:                                 # %entry<br>
>         movb    (%rdi), %al<br>
>         movzbl  1(%rdi), %ecx<br>
>         movb    %al, z(%rip)<br>
>         movb    %cl, z+1(%rip)<br>
>         incb    %al<br>
>         shll    $8, %ecx<br>
>         movzbl  %al, %eax<br>
>         orl     %ecx, %eax<br>
>         retq<br>
><br>
><br>
>I was hoping it would do something along the lines of<br>
><br>
>   movb (%rdi), %al<br>
>   movb 1(%rdi), %ah<br>
>   movh %ax, z(%rip)<br>
>   incb %al<br>
>   retq<br>
><br>
><br>
>Why is the x86 backend not getting this code?  Does it know that AH:AL =<br>
>AX?<br>
><br>
>-Krzysztof<br>
><br>
><br>
><br>
>--<br>
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>
>hosted by The Linux Foundation<br>
>_______________________________________________<br>
>LLVM Developers mailing list<br>
><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>