similar to: [LLVMdev] Valid names for symbols

On Sep 11, 2010, at 11:03 AM, David Given wrote: > What's the set of valid characters that can occur in an LLVM symbol name? > > The reason I ask is that my compiler is generating symbols based on > method names. Some methods are operators, and I haven't got around to > mangling the names yet. As a result it's producing symbols that look > like _f_+ and _f_:=. >

On 02/23/11 02:46, Chris Lattner wrote: [...] > Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. Can I put in a plea to have as much of LLVM as possible *not* require knowledge of a single, specific architecture to work? I have various things I would like to do that work on

Hi All, There is recently a discussion on the LLDB list about how to deal with targets, and our current mismash of llvm::Triple and the various subclasses of TargetSubtarget leave a lot to be desired. GNU target triples are really important as input devices to the compiler (users want to specify them) but they aren't detailed enough for internal clients. Anyway, in short, I think that we

On Fri, 13 Mar 2015, Cliff Hayes writes: >> By closing off other avenues other than dovecot imap/pop/lda/etc., >> the indices will stay sync'd. > > I use dovecot's lda and dovecot's sieve filter. Then I'm not sure how mailboxes ever get out of sync. > So it looks like I need to compare the index/mailbox mtimes as you suggest. > > What am I looking for?

I'd like my compiler to emit proper line number information. The docs talk about Instruction::setDebugLoc(), but that method doesn't actually have to be in my 2.7 LLVM Debian package. What's the correct way of doing this? In addition, can anyone point me at an example of how to emit a comment attached to an instruction (or function)? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully

My language is producing a lot of very short functions, typically two or three instructions long. These should be ideal candidates for inlining, but it isn't happening. My compiler is producing one big bitcode file, and all the functions are marked as 'internal'. I'm then doing the optimisation and translation manually using llc -O3 into a .s file, and then linking this against

I'm working on an LLVM-based compiler for a very closure-centric language. It's becoming apparent that it's going to suffer heavily from garbage collector churn, as all the useful programming idioms the language makes possible are going to involve memory allocations, either to create objects or to allocate storage for upvalues. However, it's possible to optimise away a lot of heap

My architecture has an FPU, but uses integer registers to store floating-point values. So each register can store either an int or an IEEE float. I define a register class like this: def GR32 : RegisterClass<"MyArch", [i32, f32], 32, (sequence "R%u", 0, 32)>; So far so good. However, when I write a rule to store a register: def STORE32r : S32< (outs), (ins

I'm using the Debian LLVM package to try and do JIT on a Linux armhf device. Unfortunately it seems to be generating armel code rather than armhf code, and since the ABIs don't match nothing works. I've tried overriding the triple to arm-unknown-linux-gnueabihf and arm-linux-gnueabihf (via module->setTargetTriple), and while the triples are accepted, the actual generated code

sqrtf is detected by code in SelectionDAGBuilder.cpp. This gets turns into a FSQRT ISD node type that the target can handle just like any other ISD node. If the target doesn't mark ISD::FSQRT as Legal or Custom then ExpandNode in LegalizeDAG.cpp turns it back into a sqrtf libcall. On Sun, Jan 20, 2013 at 11:34 AM, David Given <dg at cowlark.com> wrote: > On 20/01/13 19:20,

There are passes which mark function parameters as "nocapture", which means that the function does not store the passed-in pointer for use after that function returns. If pointers to a newly created object are only ever passed through "nocapture" parameters, never stored in a global, and not returned from the function, then that object is dead when the function that created

Hello, Last year I tried --- and failed --- to generate float-heavy ARM code via the JIT on an armhf platform. No matter what I did, it would always generate armel code instead. This was on LLVM 3.2, which was all that was available then. Now I'm running into a requirement to do this again: while it's much less crashy than it was, I still can't seem to persuade the JIT to generate

I have a simple expression-evaluation language using LLVM (it's at https://cowlark.com/calculon, if anyone's interested). It has pretty primitive support for 3-vectors, which I'm representing as a <3 x float>. One of my users has asked for proper n-vector support, and I agree with him so I'm adding that. However, he wants to use quite large vectors. He's mentioned 30

Given a structure like this (using C syntax rather than LLVM because I'm still not fluent with LLVM assembly): struct Object { int i1; int i2; int i3; }; Then, if I have an int* pointer which I know is pointing to the i3 element, what's the best way of recovering a pointer to the structure as a whole? My fallback option is to cast the pointer to an int64, use getelementptr to

On Sep 22, 2010, at 9:54 AM, David Given wrote: > My language is producing a lot of very short functions, typically two or > three instructions long. These should be ideal candidates for inlining, > but it isn't happening. > > My compiler is producing one big bitcode file, and all the functions are > marked as 'internal'. I'm then doing the optimisation and

How does the LLVM JIT determine the ABI and architecture to generate code for? I ask because I have an armhf device (running Debian, sort of), except the JIT is generating soft-float code. This isn't ABI compatible as parameters are passed in the wrong registers, and so simply doesn't work. Is this something that I, as an LLVM library user, should not need to worry about (and therefore

Hello, For a while I've been working on an LLVM backend for Broadcom's VideoCore 4, the GPU made famous by the Raspberry Pi. This isn't the QPU, for which Broadcom released docs a little while ago; it's the main processor, which is a VC4 core. It's a rather elegant thing with two cores, 32 registers, a built-in DSP and an extremely nice instruction set; reverse engineered

For a hypothetical Evil Project(tm), I would like to do a LLVM backend for a virtual machine that does not use 8-bit bytes. Does LLVM support this sort of thing? The details are: each addressing unit in the virtual machine can store a single value of any type, except for data pointers, which are stored as pairs (handle and offset). As such, sizeof(char) == sizeof(int) == sizeof(long long) ==

On 7/23/14, 1:20 PM, Tim Northover wrote: [...] > You should probably be specifying a triple directly, and making it an > AAPCS-VFP one for good measure: "armv7-linux-gnueabihf" for example, > or "thumbv7-none-eabihf". You shouldn't even need to set FloatABI for > those two. How do I do this? (I can't find any examples, and the API is decidedly unclear...)