similar to: [LLVMdev] [un]wrapping llvm:DITypeRef

On 07/25/2015 08:57 PM, Andrew Wilkins wrote: > On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: > > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one > data member, a

On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop> wrote: > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a > way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class > with one > data member, a pointer to Metadata. > > If I try to make my C type a struct with one pointer, I can't

On 07/27/2015 10:59 AM, Rodney M. Bates wrote: > > > On 07/25/2015 08:57 PM, Andrew Wilkins wrote: >> On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: >> >> In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap >> llvm::DITypeRef, declared in

> On 2015-Jul-25, at 15:44, Rodney M. Bates <rodney_bates at lcwb.coop> wrote: > > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one > data member, a pointer to Metadata. > > If I try to make my C type a struct with one pointer, I can't

Have I correctly inferred below, how I build IR and debug info for a function type and a function (value), in particular, how to supply the names of the formal parameters? To create a function in llvm IR and give names to its formal parameters, I must: 1. Build a LLVMTypeRef for the type of each formal and the function result. 2. Build a function type using LLVMFunctionType, from the results of

I am, from a front end, calling functions like LLVMModuleCreateWithName, found in Core.h, ultimately calling LLVMWriteBitcodeToFile, found in BitWriter.h. Do I correctly presume, from the existence of LLVMDisposeModule, that I am responsible for calling it when I'm done? Will I need to do deeper disposing myself? I presume at least I will need to free strings I allocated myself, such as the

On 08/24/2017 09:40 AM, Tim Northover wrote: > On 17 August 2017 at 15:15, Rodney M. Bates via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> For an indirect call, i.e., on a function whose address is runtime variable, >> I can't find any place/way to attach this attribute. LLVMAddAttribute >> won't take a type. > > In the C++ API you'd add the

According to the Assembly language reference: "In LLVM, opaque types can eventually be resolved to any type (not just a structure type)." But the only way I can think of to do so is to give it a type name, then later redeclare the name. But that gives an error: %TO = type opaque %TF = type i32 ( %TO* ) %TO = type %TF gives: $ llvm-as types1.ll llvm-as: types1.ll:3:1: error:

On 08/03/2014 05:30 PM, Justin Bogner wrote: > "Rodney M. Bates" <rodney_bates at lcwb.coop> writes: >> I can build llvm 3.4.2 fine, using instructions in GettingStarted.html, >> and making assumptions to account for my using tar files instead of svn. >> Although I had downloaded and extracted both llvm-3.4.2.src.tar.gz and >> cfe-3.4.2.src.tar.gz, giving

On 01/20/2015 12:45 PM, Reid Kleckner wrote: > On Tue, Jan 20, 2015 at 9:52 AM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: > > 1) Larger structs are returned differently, via memcpy. Do > these methods of returning struct values show through in > the ultimately generated machine code? It seems hard to

For this C code: typedef struct s2 { char s2C1 , s2C2; } s2td; clang generates: %struct.s2 = type { i8, i8 } which I lets llvm decide on the actual layout of this type. For the return statement in: struct s2 fs2 ( char fs2p1 ) { struct s2 ls2; ls2.s2C1 = 'B'; ls2.s2C2 = fs2p1; return ls2; } I see this IR: %struct.s2 =

On 11/15/2015 01:29 PM, Tim Northover wrote: > On 15 November 2015 at 09:01, Rodney M. Bates via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> The latter is reduced to machine code by llc, the former is not, instead >> coming through as an external function call, which then fails to link. > > Is this for x86? I don't think that has a single instruction to >

The language I am working on connecting to an llvm back-end (Modula-3) allows a fairly extensive set of recursive declarations. It looks like I can translate all its high-level types using four llvm types that refer to another type: function, struct, pointer, and array. It looks like I can alter an llvm struct type in place after it has been created, using StructType::setBody. I don't see a

I can build llvm 3.4.2 fine, using instructions in GettingStarted.html, and making assumptions to account for my using tar files instead of svn. Although I had downloaded and extracted both llvm-3.4.2.src.tar.gz and cfe-3.4.2.src.tar.gz, giving directories llvm-3.4.2.src and cfe-3.4.2.src, clang apparently did not get built. The only files with names starting with "clang" anywhere

This is partly an llvm question, and maybe partly C++. I am trying to make calls on code in the llvm infrastructure.(3.4.2) I appear to be missing some include files, but don't know how to track them down. I get compile errors on existing llvm header files, like the following two examples: -------------------------------------------------------------------------------- In file included

On Mon, Jul 21, 2014 at 3:48 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 21, 2014 at 3:41 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Mon, Jul 21, 2014 at 3:35 PM, Manman Ren <manman.ren at gmail.com> wrote: >> > >> > >> > >> > On Mon, Jul 21, 2014 at 1:14 PM, David Blaikie

On Mon, Jul 21, 2014 at 3:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 21, 2014 at 1:14 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Mon, Jul 21, 2014 at 10:39 AM, Manman Ren <manman.ren at gmail.com> wrote: >> > >> > >> > >> > On Mon, Jul 14, 2014 at 11:32 AM, Manman Ren

On Mon, Jul 21, 2014 at 10:39 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 14, 2014 at 11:32 AM, Manman Ren <manman.ren at gmail.com> wrote: >> >> >> We still have access to types via MDNodes directly and the assertion that >> assumes all accesses to DITypes are accessing the resolved DIType will fire >> >> i.e

We still have access to types via MDNodes directly and the assertion that assumes all accesses to DITypes are accessing the resolved DIType will fire i.e assert(Ty == resolve(Ty.getRef())) One example is the access to DIType via DIArray in SubroutineType. If all elements in the type array are DITypes we can create a DITypeArray and use that for SubroutineType's type array instead. But we

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM