[Feature] - ConstantDataSequential does not have a way of accessing non-string data

[spacehamster]

Is your feature request related to a problem? Please describe.
ConstantDataArray are sometimes used to store binary blobs and there is no built-in way to access the raw data in those cases.

Describe the solution you'd like
A built in ConstantDataArray.getRawDataValues method

Describe alternatives you've considered
I have been using this method to access the data

[SuppressUnmanagedCodeSecurity]
[DllImport("Ubiquity.NET.LibLLVM", CallingConvention = CallingConvention.Cdecl)]
public static extern IntPtr LLVMGetAsString(LLVMValueRef c, out size_t Length);

public static byte[] GetRawBytes(this ConstantDataSequential value)
{
	var valueHandle = (LLVMValueRef)typeof(Value)
		.GetProperty("ValueHandle", BindingFlags.Instance | BindingFlags.NonPublic)
		.GetValue(value);
	var charPtr = LLVMGetAsString(valueHandle, out var length);
	var result = new byte[length];
	Marshal.Copy(charPtr, result, 0, length);
	return result;
}

I've also considered something like this that would prevent a second copy of the byte array to a different typed array, but I did not require it for my use case.

public static unsafe T[] GetData<T>(this ConstantDataSequential value) where T : unmanaged
{
	var valueHandle = (LLVMValueRef)typeof(Value)
		.GetProperty("ValueHandle", BindingFlags.Instance | BindingFlags.NonPublic)
		.GetValue(value);
	var charPtr = LLVMGetAsString(valueHandle, out var length);
	var result = new T[length / Marshal.SizeOf<T>()];
	fixed(T* ptr = result)
	{
		Buffer.MemoryCopy(charPtr.ToPointer(), ptr, length, length);
	}
	return result;
}

Additional context
The default LLVMGetAsString returns a managed string and ConstantDataSequential.getRawDataValues returns a StringRef, but LLVM seems to use char pointers and StringRefs for both strings and non-string binary data.

[smaillet]

Yeah, the "string" in the name of the LLVM APIs for this is misleading. While it could be, and often is, a zero terminated string. The docs only say it is an array of i8. The creation APIs have a "do not null terminate" parameter, but there's no way to retrieve that from a given instance. So any APIs trying to treat it as one. There may be better options in the underlying C++ API we can leverage in an extended LibLLVM function instead of the official LLVM-C API.

[smaillet]

The underlying C++ does have isCString(), which is different from LLVMIsString() as the former reflects whether the array has a terminating null character (though the method of detection is a bit dodgy as it looks at the final value to see if it is zero and then at all other entries to see if they are non-zero (So no embedded nulls and can be confused by a byte array that happens to end in a zero as a CString). There doesn't appear to be any LLVM-C API to expose any of that so an extension in LibLLVM-C would be needed to support the distinction with all caveats.

NOTE: Raw access to the data in a ConstantDataSequential is tricky to work with as it exposes the TARGET endianess, which can be different from that of the HOST.

[spacehamster]

An example of how it its used in practice, DirectX 12 shaders serialize a ViewIDState inside of a ConstantDataArray,
They are then fetched into a vector and then later deserialized into a c++ class.
https://github.com/microsoft/DirectXShaderCompiler/blob/cb3b54fdc831c0052dff4b0ff7df96f0289092cc/lib/DXIL/DxilMetadataHelper.cpp#L1566

  const ConstantDataArray *pData = dyn_cast<ConstantDataArray>(pMetaData->getValue());

  SerializedState.clear();
  unsigned size = (unsigned)pData->getRawDataValues().size() / 4;
  SerializedState.resize(size);
  const unsigned *Ptr = (const unsigned *)pData->getRawDataValues().begin();
  memcpy(SerializedState.data(), Ptr, size * sizeof(unsigned));

I don't think the endian is an issue, because because there is an extra deserialization step the client needs to perform anyway, that can be handled there.