You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there anything we can do to make this a little better. i.e emit this code differently. Specially because the memcpy there guarantees that this store is always dead.
Replacing the [16 x i8] array with a [1 x i128] also fixes this but is not really tenable with how this code is emitted.
The text was updated successfully, but these errors were encountered:
%13 = freeze [16 x i8] undef
store [16 x i8] %13, ptr %2, align 1
I assume the point of this is that you want "uninitialized" variables that aren't undef/poison? That's not something anyone has really looked at... in C/Rust it's UB to access uninitialized memory, and most other languages don't expose uninitialized local variables at all. And for security-sensitive C code, they usually go straight to zero-init.
I don't think using an array of bytes like this is a good approach; that's what's making SROA decompose the memcpy into individual byte stores. And it's like to be unfriendly to other passes.
Maybe we could add a dedicated intrinsic to freeze memory.
Replacing the [16 x i8] array with a [1 x i128] also fixes this but is not really tenable with how this code is emitted.
Not really following the reason this is problematic.
In julia we have a pass that generates code that looks something like
As it turns out that freeze we emit there causes a large pessimization.
The code without it optimizes to
While the code with it expands to
Is there anything we can do to make this a little better. i.e emit this code differently. Specially because the memcpy there guarantees that this store is always dead.
Replacing the [16 x i8] array with a
[1 x i128]
also fixes this but is not really tenable with how this code is emitted.The text was updated successfully, but these errors were encountered: