[IRGen] Consume all arguments when generating Builtin.ZeroInitializer.

[zoecarver]

Before this patch, the Explosion destructor would assert because the arguments weren't consumed. This patch simply consumes all arguments in the BuiltinValueKind::ZeroInitializer case.

Refs #32402.

[jckarter]

I don't think this is correct. The explosion may contain further elements representing other values that are expected to be consumed after the zeroInitializer value. Why are we emitting a zeroInitializer call with an address in the first place? What do you expect that to do—produce a zero address, or zero out the referenced memory? The former would be undefined, but the latter would need a different address-only-type-specific implementation.

[zoecarver]

The explosion may contain further elements representing other values that are expected to be consumed after the zeroInitializer value.

Sorry, I'm not sure I follow. How would the explosion contain further elements? After adding a nulled out element for each member in the type, the function will always return. I think the expectation is that all arguments are consumed when the function (emitBuiltinCall) returns (but, I could be wrong about that).

What do you expect that to do—produce a zero address, or zero out the referenced memory? The former would be undefined, but the latter would need a different address-only-type-specific implementation.

We want to do the latter, zero out the referenced memory. What do you mean by an address-only-type-specific implementation? Why doesn't it work to generate a null value for each member's type?

[jckarter]

Sorry, I'm not sure I follow. How would the explosion contain further elements? After adding a nulled out element for each member in the type, the function will always return. I think the expectation is that all arguments are consumed when the function (emitBuiltinCall) returns (but, I could be wrong about that).

There are places in IRGen where an Explosion contains elements related to multiple SILValues, particularly when working with arguments and returns, but possibly in other situations. Correct code should only consume the number of arguments it expects.

We want to do the latter, zero out the referenced memory. What do you mean by an address-only-type-specific implementation? Why doesn't it work to generate a null value for each member's type?

Until this point, zeroInitializer has only expected to be used with "loadable" types which can be represented in SIL and LLVM IR as direct values. As such, it's only implemented expecting to receive zero inputs and generate zero values as results. If you want it to work with address arguments, that will require a new implementation that takes an Address value, and memsets the referenced memory.

[zoecarver]

There are places in IRGen where an Explosion contains elements related to multiple SILValues, particularly when working with arguments and returns, but possibly in other situations. Correct code should only consume the number of arguments it expects.

OK. Good to know.

Until this point, zeroInitializer has only expected to be used with "loadable" types which can be represented in SIL and LLVM IR as direct values. As such, it's only implemented expecting to receive zero inputs and generate zero values as results. If you want it to work with address arguments, that will require a new implementation that takes an Address value, and memsets the referenced memory.

Also good to know. I'll close this patch and make another that creates a memset when creating the constructor body in the clang importer.

[zoecarver]

(I'll also create patches to update the other constructors not to use Builtin.ZeroInitializer for address types.)