x86 backend legalises `xor i1` incorrectly

[Quuxplusone]

Bugzilla Link	PR30579
Status	RESOLVED FIXED
Importance	P normal
Reported by	simonas+llvm.org@kazlauskas.me
Reported on	2016-09-30 12:14:42 -0700
Last modified on	2017-04-17 11:51:00 -0700
Version	3.9
Hardware	PC Linux
CC	arielb1@mail.tau.ac.il, david.majnemer@gmail.com, hans@chromium.org, hfinkel@anl.gov, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, mkuper@google.com
Fixed by commit(s)
Attachments	file_30579.txt (637 bytes, text/plain)
Blocks
Blocked by
See also

Created attachment 17389 The LLVM IR reproducing the issue

The attached LLVM-IR sample, when compiled with llc -filetype=asm -o - test.ll -O0 (the -O0 is important here) produces the following assembly (with unnecessary details removed):

banana:
    pushq   %rbp
    movq    %rsp, %rbp
.Ltmp2:
    movb    $1, -1(%rbp)
    movb    -1(%rbp), %al  # %al = 1
    movb    F, %cl         # %cl = 0
    xorb    $-1, %cl       # %cl = 255 ^ 0 = 255
                           # missing andb $1, %cl
    cmpb    %cl, %al
    je  .LBB0_2
    ud2
.LBB0_2:
    popq    %rbp
    retq
.Lfunc_end0:

F:
    .byte   0
    .size   F, 1

The %2 = xor i1 %f, true from original LLVM-IR seems to be legalised incorrectly, as it is missing a andb $1, %cl after the xorb instruction.

[Quuxplusone]

Attached file_30579.txt (637 bytes, text/plain): The LLVM IR reproducing the issue

[Quuxplusone]

Seems like the trunk is behaving exactly like llvm 3.8 did for this particular case (which involves not using the xor instruction).

banana:
    pushq   %rbp
    movq    %rsp, %rbp
    movb    $1, -1(%rbp)
    movb    $1, %al       # %al = 1
    movb    F(%rip), %cl  # %cl = 0
    subb    $1, %cl       # %cl - 1 = 255, ZF = 0
    movb    %al, -2(%rbp) # spill
    movb    %cl, -3(%rbp) # spill
    jne     .LBB0_2       # jump if ZF = 0
    jmp     .LBB0_1
.LBB0_1:  
     ud2
.LBB0_2:                      # correct branch taken
     popq    %rbp
     retq

F:
    .byte   0                       # 0x0
    .size   F, 1

so this is fixed in trunk, but a backport to the eventual 3.9.1 would be nice.

[Quuxplusone]

It seems this wasn't picked up for 3.9.1, and since it's fixed on trunk and 4.0, I'm marking it fixed.

[Quuxplusone]

Looks like this is caused by a change on our side: https://github.com/rust-lang/llvm/commit/e60a7c182b54e88310a13b5b692b4f05c70b412c