[llvm-dev] Liveness of AL, AH and AX in x86 backend
Smith, Kevin B via llvm-dev
llvm-dev at lists.llvm.org
Tue May 24 14:17:59 PDT 2016
Sorry, I misunderstood what you were looking for then. I have never seen the x86 backend create separate defs of
ah, al, and then use ax as the combined value. I tried to come up with such cases and never found any. I suspect
that current CG can never generate such code.
Kevin
>-----Original Message-----
>From: Krzysztof Parzyszek [mailto:kparzysz at codeaurora.org]
>Sent: Tuesday, May 24, 2016 2:00 PM
>To: Smith, Kevin B <kevin.b.smith at intel.com>; 'mehdi.amini at apple.com'
><mehdi.amini at apple.com>
>Cc: mats petersson <mats at planetcatfish.com>; llvm-dev at lists.llvm.org
>Subject: Re: [llvm-dev] Liveness of AL, AH and AX in x86 backend
>
>Thanks Kevin. This isn't exactly what I'm looking for, though. The ECX
>is explicitly defined here and CL/CH are only used. I was interested in
>the opposite situation---where the sub-registers are defined separately
>and then the super-register is used as a whole.
>
>Hopefully the sub-register liveness tracking is what I need, so the
>questions about x86 may become moot.
>
>-Krzysztof
>
>
>
>On 5/24/2016 3:25 PM, Smith, Kevin B wrote:
>> Here's some of the generated code from the current community head for
>bzip2.c from spec 256.bzip2, with these options:
>>
>> clang -m32 -S -O2 bzip2.c
>>
>> .LBB14_4: # %bsW.exit24
>> subl %eax, %ebx
>> addl $8, %eax
>> movl %ebx, %ecx
>> movl %eax, bsLive
>> shll %cl, %edi
>> movl %ebp, %ecx
>> orl %esi, %edi
>> movzbl %ch, %esi
>> cmpl $8, %eax
>> movl %edi, bsBuff
>> jl .LBB14_6
>>
>> As you can see, it is using both cl and ch for different values in this basic
>block. This occurs in the generated code for the routine bsPutUInt32
>>
>> Kevin Smith
>>
>>> -----Original Message-----
>>> From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
>>> Sent: Tuesday, May 24, 2016 1:03 PM
>>> To: Krzysztof Parzyszek <kparzysz at codeaurora.org>
>>> Cc: mats petersson <mats at planetcatfish.com>; Smith, Kevin B
>>> <kevin.b.smith at intel.com>; llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] Liveness of AL, AH and AX in x86 backend
>>>
>>> Hi,
>>>
>>> Could you use "MIR" to forge the example you're looking for?
>>>
>>> --
>>> Mehdi
>>>
>>>
>>>> On May 24, 2016, at 10:10 AM, Krzysztof Parzyszek via llvm-dev <llvm-
>>> dev at lists.llvm.org> wrote:
>>>>
>>>> Then let me shift focus from performance to size. With either optsize or
>>> minsize, the output is still the same.
>>>>
>>>> As per the subject, I'm not really interested in the quality of the final
>code,
>>> but in the way that the x86 target deals with the structural relationship
>>> between these registers. Specifically, I'd like to see if it would generate
>>> implicit defs/uses for AX on defs/uses of AH/AL. I looked in the X86
>>> sources and I didn't find code that would make me certain, but I'm not too
>>> familiar with that backend. Having a testcase to work with would make it
>a lot
>>> easier for me.
>>>>
>>>> -Krzysztof
>>>>
>>>>
>>>> On 5/24/2016 12:03 PM, mats petersson wrote:
>>>>> 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.
>>>>>
>>>>> <<Quote from Intel Optimisation guide, page 3-44
>>>>> http://www.intel.co.uk/content/dam/doc/manual/64-ia-32-architectures-
>>> optimization-manual.pdf
>>>>>
>>>>> A partial register stall happens when an instruction refers to a
>>>>> register, portions of
>>>>> which were previously modified by other instructions. For example,
>>>>> partial register
>>>>> stalls occurs with a read to AX while previous instructions stored AL
>>>>> and AH, or a read
>>>>> to EAX while previous in
>>>>> struction modified AX.
>>>>> The delay of a partial register stall is small in processors based on
>>>>> Intel Core and
>>>>> NetBurst microarchitectures, and in Pentium M processor (with CPUID
>>>>> signature
>>>>> family 6, model 13), Intel Core Solo,
>>>>> and Intel Core Duo processors. Pentium M
>>>>> processors (CPUID signature with family 6,
>>>>> model 9) and the P6 family incur a large
>>>>> penalty.
>>>>> <<Enq quote>>
>>>>>
>>>>> So for compact code, yes, it's probably an advantage. For SOME
>>>>> processors in the x86 range, not so good for performance.
>>>>>
>>>>> 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.
>>>>>
>>>>> --
>>>>> Mats
>>>>>
>>>>> On 24 May 2016 at 17:09, Smith, Kevin B via llvm-dev
>>>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>>
>>>>> 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.
>>>>> 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.
>>>>>
>>>>> Kevin Smith
>>>>>
>>>>> >-----Original Message-----
>>>>> >From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org
>>>>> <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of
>>>>> >Krzysztof Parzyszek via llvm-dev
>>>>> >Sent: Tuesday, May 24, 2016 8:04 AM
>>>>> >To: LLVM Dev <llvm-dev at lists.llvm.org <mailto:llvm-
>>> dev at lists.llvm.org>>
>>>>> >Subject: [llvm-dev] Liveness of AL, AH and AX in x86 backend
>>>>> >
>>>>> >I'm trying to see how the x86 backend deals with the relationship
>>>>> >between AL, AH and AX, but I can't get it to generate any code that
>>>>> >would expose an interesting scenario.
>>>>> >
>>>>> >For example, I wrote this piece:
>>>>> >
>>>>> >typedef struct {
>>>>> > char x, y;
>>>>> >} struct_t;
>>>>> >
>>>>> >struct_t z;
>>>>> >
>>>>> >struct_t foo(char *p) {
>>>>> > struct_t s;
>>>>> > s.x = *p++;
>>>>> > s.y = *p;
>>>>> > z = s;
>>>>> > s.x++;
>>>>> > return s;
>>>>> >}
>>>>> >
>>>>> >But the output at -O2 is
>>>>> >
>>>>> >foo: # @foo
>>>>> > .cfi_startproc
>>>>> ># BB#0: # %entry
>>>>> > movb (%rdi), %al
>>>>> > movzbl 1(%rdi), %ecx
>>>>> > movb %al, z(%rip)
>>>>> > movb %cl, z+1(%rip)
>>>>> > incb %al
>>>>> > shll $8, %ecx
>>>>> > movzbl %al, %eax
>>>>> > orl %ecx, %eax
>>>>> > retq
>>>>> >
>>>>> >
>>>>> >I was hoping it would do something along the lines of
>>>>> >
>>>>> > movb (%rdi), %al
>>>>> > movb 1(%rdi), %ah
>>>>> > movh %ax, z(%rip)
>>>>> > incb %al
>>>>> > retq
>>>>> >
>>>>> >
>>>>> >Why is the x86 backend not getting this code? Does it know that
>>>>> AH:AL =
>>>>> >AX?
>>>>> >
>>>>> >-Krzysztof
>>>>> >
>>>>> >
>>>>> >
>>>>> >--
>>>>> >Qualcomm Innovation Center, Inc. is a member of Code Aurora
>Forum,
>>>>> >hosted by The Linux Foundation
>>>>> >_______________________________________________
>>>>> >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
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> hosted by The Linux Foundation
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
>--
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>hosted by The Linux Foundation
More information about the llvm-dev
mailing list