www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - TYnptr in LLVM?

reply Jacob Carlborg <doob me.com> writes:
The TYnptr type in DMD [1], what is the corresponding type, in 
LLVM? I'm referring to a instance of `llvm::Type` [2] that can be 
used in global variable, `llvm::GlobalVarible`.

[1] 
https://github.com/dlang/dmd/blob/master/src/dmd/backend/ty.d#L66
[2] http://llvm.org/doxygen/classllvm_1_1Type.html

--
/Jacob Carlborg
Jul 15 2018
parent reply kinke <kinke libero.it> writes:
On Monday, 16 July 2018 at 06:38:01 UTC, Jacob Carlborg wrote:

 The TYnptr type in DMD [1], what is the corresponding type, in 
 LLVM? I'm referring to a instance of `llvm::Type` [2] that can 
 be used in global variable, `llvm::GlobalVarible`.

 [1] 
 https://github.com/dlang/dmd/blob/master/src/dmd/backend/ty.d#L66
 [2] http://llvm.org/doxygen/classllvm_1_1Type.html

 --
 /Jacob Carlborg


No idea about the DMD backend, but in LLVM you generally just 
declare a global of some arbitrary IR type (e.g., from a D type: 
`DtoType(dtype)`), and the resulting GlobalVariable will always 
be a pointer to that type. You define the global by setting an 
initializer. See the pretty new `{declare,define}Global()` 
helpers.
Jul 16 2018
parent reply Jacob Carlborg <doob me.com> writes:
On Monday, 16 July 2018 at 09:29:59 UTC, kinke wrote:


 No idea about the DMD backend, but in LLVM you generally just 
 declare a global of some arbitrary IR type (e.g., from a D 
 type: `DtoType(dtype)`), and the resulting GlobalVariable will 
 always be a pointer to that type. You define the global by 
 setting an initializer. See the pretty new 
 `{declare,define}Global()` helpers.


Hmm. I don't have a D type. This is for when referencing an 
Objective-C class defined externally. The compiler generates a 
symbol like _OBJC_CLASS_$_<name>. I need a type for that symbol. 
The IR code generated by Clang looks like this

%struct._class_t = type { %struct._class_t*, %struct._class_t*, 
%struct._objc_cache*, i8* (i8*, i8*)**, %struct._class_ro_t* }
%struct._objc_cache = type opaque
%struct._class_ro_t = type { i32, i32, i32, i8*, i8*, 
%struct.__method_list_t*, %struct._objc_protocol_list*, 
%struct._ivar_list_t*, i8*, %struct._prop_list_t* }
%struct.__method_list_t = type { i32, i32, [0 x 
%struct._objc_method] }
%struct._objc_method = type { i8*, i8*, i8* }
%struct._objc_protocol_list = type { i64, [0 x 
%struct._protocol_t*] }
%struct._protocol_t = type { i8*, i8*, 
%struct._objc_protocol_list*, %struct.__method_list_t*, 
%struct.__method_list_t*, %struct.__method_list_t*, 
%struct.__method_list_t*, %struct._prop_list_t*, i32, i32, i8**, 
i8*, %struct._prop_list_t* }
%struct._ivar_list_t = type { i32, i32, [0 x %struct._ivar_t] }
%struct._ivar_t = type { i64*, i8*, i8*, i32, i32 }
%struct._prop_list_t = type { i32, i32, [0 x %struct._prop_t] }
%struct._prop_t = type { i8*, i8* }

 "OBJC_CLASS_$_NSObject" = external global %struct._class_t
 "OBJC_CLASSLIST_REFERENCES_$_" = private global 
%struct._class_t*  "OBJC_CLASS_$_NSObject", section 
"__DATA,__objc_classrefs,regular,no_dead_strip", align 8

--
/Jacob Carlborg
Jul 16 2018
parent reply kinke <noone nowhere.com> writes:
On Monday, 16 July 2018 at 13:40:35 UTC, Jacob Carlborg wrote:

 Hmm. I don't have a D type. This is for when referencing an 
 Objective-C class defined externally. The compiler generates a 
 symbol like _OBJC_CLASS_$_<name>. I need a type for that 
 symbol. The IR code generated by Clang looks like this

 %struct._class_t = type { %struct._class_t*, %struct._class_t*, 
 %struct._objc_cache*, i8* (i8*, i8*)**, %struct._class_ro_t* }
 %struct._objc_cache = type opaque
 %struct._class_ro_t = type { i32, i32, i32, i8*, i8*, 
 %struct.__method_list_t*, %struct._objc_protocol_list*, 
 %struct._ivar_list_t*, i8*, %struct._prop_list_t* }
 %struct.__method_list_t = type { i32, i32, [0 x 
 %struct._objc_method] }
 %struct._objc_method = type { i8*, i8*, i8* }
 %struct._objc_protocol_list = type { i64, [0 x 
 %struct._protocol_t*] }
 %struct._protocol_t = type { i8*, i8*, 
 %struct._objc_protocol_list*, %struct.__method_list_t*, 
 %struct.__method_list_t*, %struct.__method_list_t*, 
 %struct.__method_list_t*, %struct._prop_list_t*, i32, i32, 
 i8**, i8*, %struct._prop_list_t* }
 %struct._ivar_list_t = type { i32, i32, [0 x %struct._ivar_t] }
 %struct._ivar_t = type { i64*, i8*, i8*, i32, i32 }
 %struct._prop_list_t = type { i32, i32, [0 x %struct._prop_t] }
 %struct._prop_t = type { i8*, i8* }

  "OBJC_CLASS_$_NSObject" = external global %struct._class_t
  "OBJC_CLASSLIST_REFERENCES_$_" = private global 
 %struct._class_t*  "OBJC_CLASS_$_NSObject", section 
 "__DATA,__objc_classrefs,regular,no_dead_strip", align 8

 --
 /Jacob Carlborg


Assuming you only need an opaque pointer to that symbol (and you 
don't mix LDC/clang bitcode, e.g., via LTO), any type should do 
(see clang's opaque `%struct._objc_cache` - I think you create an 
opaque type as IR struct without elements via 
`llvm::StructType::create(gIR->context(), "name")`).

Otherwise, you'll have to define these types like clang does 
(using another `StructType::create()` overload, one taking the 
array of element types). LDC's `getVoidPtrType()` helpers returns 
the common `i8*` IR type, `llvm::IntegerType::get(gIR->context(), 
32)` returns `i32` etc.
Jul 16 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-07-16 20:37, kinke wrote:


 Assuming you only need an opaque pointer to that symbol (and you don't 
 mix LDC/clang bitcode, e.g., via LTO), any type should do (see clang's 
 opaque `%struct._objc_cache` - I think you create an opaque type as IR 
 struct without elements via `llvm::StructType::create(gIR->context(), 
 "name")`).
 
 Otherwise, you'll have to define these types like clang does (using 
 another `StructType::create()` overload, one taking the array of element 
 types). LDC's `getVoidPtrType()` helpers returns the common `i8*` IR 
 type, `llvm::IntegerType::get(gIR->context(), 32)` returns `i32` etc.


Thanks. Ideally it should be full compatible with Clang so I'll go with 
trying to define the structs exactly as Clang outputs them.

-- 
/Jacob Carlborg
Jul 17 2018
parent kinke <noone nowhere.com> writes:
On Tuesday, 17 July 2018 at 17:34:46 UTC, Jacob Carlborg wrote:

 Thanks. Ideally it should be full compatible with Clang so I'll 
 go with trying to define the structs exactly as Clang outputs 
 them.


Well just using an opaque `struct._class_t` IR struct may work 
too when mixing bitcode, so I'd give that a try first.
Jul 17 2018