equalMask with void initialized vector broken for optimized builds

[FinalEvilution]

Compiling this with -O produces a mask of zeros, while for an unoptimized build it works correctly.
Tested with ldc master and ldc2-1.42.0-linux-x86_64
https://godbolt.org/z/b5b43onGb

import std.stdio;
import ldc.simd;
import core.simd;

void main()
{
	int8 mask = void;
	writeln(cast(int[8]) mask.array);
	mask  = equalMask!int8(mask, mask);
	writeln(cast(int[8]) mask.array);
}

[kinke]

This is almost certainly undefined behavior, and the LLVM optimizer handling it like this.

[FinalEvilution]

At first i thought the same thing, but then i looked at the d spec and now i'm not so sure.
Void Initialization
"2. Implementation Defined: If a void initialized variable's value is used before it is set, its value is implementation defined."
The spec doesn't say that the variable's value can change between uses, only that the value could be random. That's my look on it.
If this behavior is intended then the spec should be updated to be more specific.

[kinke]

This is UB we're inheriting from LLVM, which apparently includes loads of undefined stack data. I don't see a problem with the spec, nor why anyone would want to rely on something like this.

[kinke]

Btw, masks are automatically generated for vector comparisons nowadays (with LDC at least):

import core.simd;

void main()
{
    int8 v = void;
    int8 mask = v == v;
    version (D_Optimized)
        assert(mask is int8(0));
    else
        assert(mask is int8(-1));
}

[FinalEvilution]

You're right. A mask is what i'm going for, but i also want to do a bit shift so i get a partial mask.

__m256i mask = _mm256_undefined_si256();
mask  = _mm256_cmpeq_epi32(mask, mask);
mask  = _mm256_srli_epi32(mask, 24);

I'm using AuburnSounds intel-intrinsics library and the _mm256_undefined_si256 intrinsic seemed like it might (in theory) speed
up the code as i've seen this before. Although i don't know if this would improve things, i had to try.
The intel compiler is now based on LLVM and they have this intrinsic, and i assume it works as i expect or they would not have it,
so i figured that the d library would work the same way, and looking at the void init it uses it seemed it would.

[kinke]

Oh, no idea about that *_undefined_* intrinsic... shifts are also supported directly nowadays:

int8 v;
int8 mask = (v == v) >>> 24;
assert(mask is int8(0xFF));

[FinalEvilution]

Thank you for the code. Unfortunately no performance improvement :) Ah well, i knew it was a long shot.
I'm opening a new issue for the intel-intrinsics library. They may need to adjust their intrinsic to match the intel compiler intrinsic.

[kinke]

This seems to be llvm/llvm-project#31524, which was apparently resolved (in 2017) by making those *_undefined_* intrinsics return a vector filled with zeros: llvm/llvm-project@e795daa

Edit: Yeah, clang 22 initializes it with zeros still: https://cpp.godbolt.org/z/aY8ePrzd1

[FinalEvilution]

Good find. I'm quite amused that their broken code is almost identical to mine.
I'm going to wait a few days for the library devs to respond to their issue, they may want to go the 'freeze poison' way.
If there is no action I'll make a pr myself and close both the issues.

[p0nce]

intel-intrinsics now workarounds that, however this issue can manifest itself without __vector

https://d.godbolt.org/z/1v5Gffc97

Source:

int cmpeq(T)(T a, T b)
{
    return (a == b) ? -1 : 0;
}

int undefined_int()
{
    int r = void;
    return r;
}

int makeOne()
{
    int r = undefined_int;
    return cmpeq!int(r, r); // Return -1 in O0 and 0 in -O2
}

void main()
{
	import std;
	writeln(makeOne); // write -1 in -O0 and 0 in -O2
}

Not sure what can be done about that.

[kinke]

AFAICT, nothing, except for not ever reading random garbage, to avoid UB territory. The *_undefined_* x86 vector intrinsics are a special case and need to be handled for LLVM at least.

For LLVM and creating a vector with all bits set, it's apparently best to avoid any explicit intrinsics and just use a splat in D:

int8 makeAllOnesVector() {
    return int8(-1);
}

with -O -mattr=+avx2 (https://d.godbolt.org/z/Pa7odEfcW) =>

        vpcmpeqd        ymm0, ymm0, ymm0
        ret

Yielding exactly the wanted instruction in the original post, using whatever garbage is in the ymm0 register.

And with the shift:

int8 makeMask() {
    return int8(-1) >>> 24; // int8(0xFF)
}

LLVM selects a single vbroadcastss instruction (probably faster than vpcmpeqd + shift?).

[p0nce]

Yes, for this reason some of the mundane intrinsics are not really better than normal code, their goal is to disappear before the optimizer. Especially just data movement is almost never better in intrinsics. They help for complex loops, sometimes.

[FinalEvilution]

@p0nce I'm ready to close this unless there's anything you want to add.

Side note. I was able to optimize the code using only bitshifts like so.

__m256i extractRGBChanel(RGBChanel C)(__m256i input)
{
	pragma(inline, true);
	static if (C == RGBChanel.r)
	{
		input = _mm256_slli_epi32(input, 24);
		return _mm256_srli_epi32(input, 24);
	}
...

Which got lowered after inlining to vpshufb %ymm,%ymm,%ymm instructions. Netting me a 3.88% reduction in runtime.
I'm very happy about that improvement.