[llvm-dev] RFC: Adding debug information to LLVM to support Fortran

[Sohail Somani (Fizz Buzz Inc.) via llvm-dev]

On Thu, Nov 1, 2018, at 6:27 PM, via llvm-dev wrote:





> Regarding flags, I was just thinking that maybe we should invent a new
> DISubprogramFlags type.  DISubprogram already has a few bitfields for
> subprogram-specific things, Fortran will want 3 more, and there's no
> reason to fill up the generic DIFlags with more bits that are used in
> only one class.>  


> I agree that the array stuff needs to be designed with an eye to
> handling how other languages do arrays, and leverage the common
> aspects.  Several languages have runtime-sized arrays and it would be
> nice to handle them all the same way.> However the CHARACTER type probably does want to be DW_TAG_string_type
> rather than an array. COBOL also has strings as a fundamental type.>  


> I guess we'll have to learn what all the Fortran array stuff actually
> means now…> --paulr






May I suggest changing DIFlags from an enum to a simple int wrapper that
behaves like an enum and can implement encoding? It is true that a lot
of the bits are left unused in everyday contexts, so there is a
possibility to encode more data.For example:

DIFlags flags = FortranRelatedContext; flags |= SomeFortranFlag;So when assigning SomeFortranFlag the appropriate DIFlags operator would
assert that the specific context is active.I’ve had to extend DIFlags and in the end, just increased the size of
the data type, but a clever encoding with a non-clever interface would
halve memory usage currently used for DIFlags in my circumstance.— Sohail Somani Fizz Buzz Inc. Booking schedule:
https://sohailsomani.youcanbook.me

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181101/306dff4d/attachment.html>