`xor undef, undef` always simplifies to `0`

[Veeloxfire]

Tested on x64 clang trunk

int foo_xor() {
    int i;
    int j;

    return i ^ j;
}

During optimization this reaches xor undef, undef
xor undef, undef then "optimizes" to 0

This is special cased to allow a ^ a to always be 0:

llvm-project/llvm/lib/IR/ConstantFold.cpp

Lines 628 to 632 in 4015545

	case Instruction::Xor:
	if (isa<UndefValue>(C1) && isa<UndefValue>(C2))
	// Handle undef ^ undef -> 0 special case. This is a common
	// idiom (misuse).
	return Constant::getNullValue(C1->getType());

I am aware this is UB so the behaviour doesn't necessarily matter but it feels unreasonable that the 2 "different" undef's here xor to 0 and we inject a concrete 0 that the optimizer has to work around
Not sure there is a way in llvm's internals to specify that 2 undef values are different (e.g. if you had a ^ a are both undefs the same pointer?) so it may not be worth investigating but I thought I would raise

[EugeneZelenko]

Variables are not initialized, so undefined behavior?

[Veeloxfire]

I am aware this is UB

I don't want a specific behaviour, but this leave potential optimization on the table by forcing 0 instead allowing undef to propogate

[Veeloxfire]

consider

int foo_xor() {
    int i;
    int j;

    return i ^ j;
}

int foo_add() {
    int i;
    int j;

    return i + j;
}

int other();

int bar_xor(bool b) {
    if (b) {
        return foo_xor();
    }
    else {
        return other();
    }
}


int bar_add(bool b) {
    if (b) {
        return foo_add();
    }
    else {
        return other();
    }
}

optimizes to

foo_xor():
        xor     eax, eax
        ret

foo_add():
        ret

bar_xor(bool):
        test    edi, edi
        je      other()@PLT
        xor     eax, eax
        ret

bar_add(bool):
        jmp     other()@PLT

The xor case is forced to branch whereas the add case can eliminate the UB branch

[pinskia]

Note c++26 changes this ...

[Veeloxfire]

My point is not about c++ semantics its about the llvm optimization of xor, where it is creating 0s where they do not need to be, which can restrict further optimization

However it is still relevant in c++26. You can tag values as [[indeterminate]]
And there are also still other ways to produce this behaviour with other uses of xor and undefined behaviour

int foo_xor() {
    int* p = new int(0);
    delete p;
    int* q = new int(1);
    delete q;
   
    return *p ^ *q;
}

This produce a ret 0 due to transformations with xor. I don't believe this something which is forced by programmer expectation. As they would likely expect this to simplify to 0 ^ 1. Nobody expects 0 ^ 1 to xor to 0

Code like the snippet below which produces poison values is able to propogate this correctly:

int foo_xor() {
    int i = 1;
    int j = 0;

    return (i / j) ^ (i / j);
}

With more research I found there is an ongoing effort to remove undef from llvmir and I wonder if this may be resolved by that

[nikic]

@Veeloxfire Do you have any evidence that changing this behavior would be useful for any real-world code?