codegen: remove UB from uninitialized bitstypes in new

[vtjnash]

In the time since the creation of issue #26764, there is now 'a way to say to llvm "I don't care what this value is, but it always has to be the same"' using the freeze instruction, so we can use that to instruct LLVM to not give us undefined behavior when users are using uninitialized memory. There should not be an impact if users were already avoiding this paradigm and are fully initializing their structs.

Fixes #26764

[vtjnash]

Note that this is already consistent with the way that inference treats these bitstype allocations as being non-pure:

julia> Base.infer_effects(Bad{Int}, ())
(!c,+e,+n,+t,+s,+m,+u)

[vtjnash]

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[vtjnash]

@nanosoldier runbenchmarks("misc" || "inference" || "rem_pio2", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[aviatesk]

Note that this is already consistent with the way that inference treats these bitstype allocations as being non-pure:

julia> Base.infer_effects(Bad{Int}, ())
(!c,+e,+n,+t,+s,+m,+u)

I investigated into this and found this is a bug that we don't propagate :noub information to post-opt analysis

julia/base/compiler/ssair/inlining.jl

Lines 1268 to 1275 in e754f20

	if !isexpr(stmt, :call) && !isexpr(stmt, :invoke)
	# There is a bit of a subtle point here, which is that some non-call
	# statements (e.g. PiNode) can be UB:, however, we consider it
	# illegal to introduce such statements that actually cause UB (for any
	# input). Ideally that'd be handled at insertion time (TODO), but for
	# the time being just do that here.
	ir.stmts[idx][:flag] |= IR_FLAG_NOUB
	end

(i.e. :noub is actually tainted during abstract interpretation time but it is refined by post-opt analysis).

I think now we don't need to taint :noub during abstract interpretation time too.

[MasonProtter]

There should not be an impact if users were already avoiding this paradigm and are fully initializing their structs.

Just for clarity, will there be any impact on users who create uninitialized structs? i.e. are there things such as performance implications to this, or does this simply eliminate a family of bugs where LLVM was previously free to swap out bits

[vtjnash]

There are performance implications for people who were using uninitialized memory, though that was previously discouraged anyways. Some positive and some negative effects.