Currently DIBuilder supports constant length strings only. In this review I have added a new interface called createStringType() which is capable of generating the debug info metadata for an assumed length string.
I just added a new field StringLocationExp to DIStringType in this commit: https://reviews.llvm.org/rG28bfa57a7315c3161124c90b4d52f467616dc92e . Please add an optional argument to these createStringType functions so that the caller can specify this new field if it desires.
stringLength can be typed as DIVariable *.
Side note: LLVM coding convention calls for capital first letter of a variable name; so stringLength -> StringLength.
Use DIVariable * for StringLength.
Use DIExpression * for StrLocationExp.
Using nullptr for the length argument seems too generic. Could you mock up a DIVairbale/DIExpression for length and a DIExpression for location for both new functions?
One last suggestion: We can combine the two new functions into one by typing the length argument PointerUnion<DIVariable*, DIExpression*>. Please see DIBuilder::createArrayType for a precedent.
In the createArrayType() instance, the expression and variable arguments are interchangeable metadata to the same composite type parameter. In DIStringType, at least currently, the variable string length and string length expression are independent parameters. To reflect this in the DIBuilder interface I would prefer to have independent createStringType() calls.
DIStringType should have only one field to represent the string length. I think this boils down to if the DIBuilder interface needs to reflect the current state of the underlying implementation. My take is that we can go ahead with what the user should see with this patch, and then change the implementation at a later time if necessary to avoid an additional API change down the road.
Even if this change was made, there will still be a second interface routine for creating constant string length types. I don't see value in upcasting the arguments and performing isa comparisons on them just to downcast them into separate arguments again. The string type does not yet have the complexity of the array type interface. The proposed implementation here is cleaner and functionally equivalent.