similar to: [LLVMdev] Advice on field access, adding a Modula-3 front end

On 04/10/2014 09:02 PM, Krzysztof Parzyszek wrote: > On 4/10/2014 8:40 PM, Rodney M. Bates wrote: >> >> I could probably create llvm IR in this style by generating explicit >> address arithmetic, but I suspect that might hurt the optimization >> possibilities, perhaps a lot. It looks like re-raising the level to >> field numbers would not be horribly difficult,

> On Feb 5, 2017, at 7:13 PM, Rodney M. Bates via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > A couple of Modula-3 developers have worked on splicing LLVM on as an alternative > back end to the Modula-3 compiler, out-of-tree (the LLVM tree), of course. A major > portion of the necessary glue code is there, and at one time, I was able to get the > M3 compiler and the

I need to set the 'next' attribute on a parameter. If the function is to be directly called, i.e., a function constant, I am getting what I want as follows (using the C 'Core.h' binding) 1) Build a function type, using LLVMFunctionType. 2) Build a function value, passing the result of 1) to LLVMAddFunction 3) Go through the formal parameters of 2), using LLVMGet[First|Next]Param,

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

Suppose I have compiled a record equivalent to: struct ST { short s; char c3, c4; } STvar; and llvm IR: %STvar = alloca { i16, i8, i8 } According to "The Often Misunderstood GEP Instruction", I can construct an artificial llvm type to supply to GEP. (The "ugly GEP"?) So I can think of three ways to access STvar.c3. These are in order of increasing easiness for me to

Hi folks, Happy new year! Last LLVM Developers' Meeting I had a BoF: 'Raising Next Generation LLVM Developers'. It was suggested that we should update our open projects page and possibly restructure it a little bit. I volunteered to do this work and I need your help. Chandler and I started working on a google doc [1]. We pinged few code owners asking them to list of

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

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

I am generating llvm code for nested procedures. Each one gets a static link, which I am passing as an internally added, first parameter. However, it needs to be stored in memory too, so a debugger can find it. So, when I need to use the value, is it better to use the ssl parameter or load the memory copy? I can imagine the ssl value might avoid unnecessary fetches, but then, it might also

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:

It's now a multi-stage process. First, there is a difference between a permanent forward declaration (i.e. the actual definition is in a different file) and a temporary forward declaration (i.e. it will appear later in the same file). To create a permanent forward declaration: DICompositeType *result = m_DIBuilder->createForwardDecl( dwarf::DW_TAG_structure_type,

Before metadata was separated from values, I could create a debug info forward declaration and eventually resolve it using LLVMReplaceAllUsesWith in core.h. Now, I can't figure out how to resolve it. I can find no function that seems to do this. My one wild guess that giving the forward decl and the resolving decl the same UniqueId might do it is not working. I am currently using 3.6.1, but

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

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 >

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 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

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 =

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 cast it to DITypeRef. If I try to go inside the classes and use the pointer, I can cast, but can't construct a

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

I have a smallish compilation that contains calls on intrinsics @llvm.maxnum.f32 and @llvm.fabs.f32: %fminmax = call float @llvm.maxnum.f32(float %fabs5, float %fabs) %fabs = call float @llvm.fabs.f32(float %v.6) 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. I can't see any differences