similar to: [LLVMdev] Compiler-RT roadmap

Hi David, On Wed, Feb 12, 2014 at 5:22 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 12 Feb 2014, at 13:21, Alexey Samsonov <samsonov at google.com> wrote: > > > On Wed, Feb 12, 2014 at 4:56 PM, David Chisnall < > David.Chisnall at cl.cam.ac.uk> wrote: > >> Are you going to move the unwind library there as part of the >

I am attempting to port an operating system project to use Clang/LLVM instead of GCC, but I'm having issues with Compiler-RT. Right now, the OS is being cross-compiled on an x86_64 host targeting ARMv7a. I built the LLVM toolchain according to the instructions, though I limited the supported targets to arm, x86, and x86_64 to reduce compilation time. I'm finding that compilation proceeds

On 31 Jan 2014, at 08:12, Chandler Carruth <chandlerc at google.com> wrote: > - There is the core runtime library. Historically this was called 'compiler-rt' informally, but perhaps better called 'libclang_rt', which provides the core necessary runtime library facilities to compile C or C++ applications. It's analogous to libgcc but without some of the unwinding code

Hi all, compiler-rt is now not only a libgcc replacement for different platforms, there are sanitizer and profile runtimes as well. I plan to move the files as follows during this week: 1. libraries: a) all libgcc replacement stuff moves from "/lib" to "/lib/core" (the name sucks, please suggest alternatives). Same for platform-specific code:

When LLVM's configure finds a usable <pthread.h>, it prefers to use that rather than the home-grown stuff. However if LLVM is configured with --disable-pthreads, both mingw flavors produce the same results. BTW, I've tried to quantify the slowdown: a quick test indicates that LLVM build that uses pthreads is about 10% slower than the one which doesn't. This is less that I

On 1 February 2014 00:44, Nick Kledzik <kledzik at apple.com> wrote: > * One of the interesting things about compiler-rt is the static library to > dynamic library migration (e.g. libgcc.a vs libgcc_s.so, or on Darwin > libclang_*.a vs libSystem.dylib). If the shared library ships > independently from the compiler, then the compiler may need a .a file that > can ship with it

In the effort to flesh out the CMake build system a problematic issue has come up, and I’d like some feedback on how to best handle it. For reference this issue has been reported by a few users, one proposed patches that don’t really address the underlying problem here: http://reviews.llvm.org/D13131 The problem comes when bootstrapping a cross-compiler toolchain. In order to have a

Hi, Is it somehow possible to have LLVM emit machine code for the 'unreachable' IR instruction, which would assert that it indeed never gets reached? Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140414/02108a74/attachment.html>

Hi, Having just found an ABI conformance bug in a compiler front-end, I am curious: is the state of target-independent argument lowering in LLVM still the same as when this thread was taking place?: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387 Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL:

I am not seeing this happening, at least not for unreachables that follow calls to 'noreturn' functions. On Apr 14, 2014, at 3:48 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > x86 backend emits ud2 instruction in this case > > On Mon, Apr 14, 2014 at 1:46 PM, Vadim Chugunov <vadimcn at gmail.com> wrote: >> Hi, >> Is it

Hi Yaron, Not sure I understand your question. Wasn't <mutex> one of the more important C++11 features that LLVM would like to use? On Thu, Sep 25, 2014 at 1:24 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > Vadim, > > Thanks for the feedback on the -win32. A dependency on a small DLL with > BSD license does not sound too bad, but performance regression is

> On Dec 18, 2016, at 3:48 AM, Dmitry Golovin <dima at golovin.in> wrote: > > > > 16.12.2016, 18:23, "Vedant Kumar" <vsk at apple.com>: >>> On Dec 16, 2016, at 7:06 AM, Dmitry Golovin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> I want to build LLVM-based toolchain with Musl, I have LLVM sources with clang and

On Wed, Dec 3, 2014 at 1:41 PM, Reid Kleckner <rnk at google.com> wrote: > On Wed, Dec 3, 2014 at 1:27 PM, Vadim Chugunov <vadimcn at gmail.com> wrote: > >> If we added unwind target to every potentially throwing instruction >> (loads, stores, all binary operations), wouldn't all such instructions have >> to become BB terminators? I'd expect that CFG

Hi, I have a couple of questions about MachineBasicBlocks: - If I have a pointer to an MBB, is there an easy way to find which block that precedes it in the MachineFunction blocks list? (without iterating through all of the MF's basic blocks) - Does LLVM make any effort to ensure that MBB's predecessors and successors lists are semantically correct? For example, what happens if an MBB

Hi All, For various obscure reasons I'd like to detect the condition when X86 CALL instruction immediately precedes a function epilogue in the final emitted code, and insert a NOP between them if that happens. My initial attempt at it looked like this: MachineBasicBlock& MBB; MachineBasicBlock::iterator MBBI; <-- points to where the epilogue would be inserted if (MBBI != MBB.begin()

Hi! LLVM has a class, ConstantExpr, that is very handy for compile-time evaluation of const expressions. Unfortunately I cannot find any methods in it that would be helpful in evaluation of expressions similar to this: (uintptr_t)(&(*(TYPE*)0).FIELD), which is basically the implementation of the offsetof(TYPE, FIELD) macro. Specifically, there seem to be no provisions for dereferencing a

On Fri, Jan 2, 2015 at 2:20 AM, David Majnemer <david.majnemer at gmail.com> wrote: > > > On Fri, Jan 2, 2015 at 1:58 AM, Vadim Chugunov <vadimcn at gmail.com> wrote: > >> Hi! >> LLVM has a class, ConstantExpr, that is very handy for compile-time >> evaluation of const expressions. Unfortunately I cannot find any methods >> in it that would be

16.12.2016, 18:23, "Vedant Kumar" <vsk at apple.com>: >>  On Dec 16, 2016, at 7:06 AM, Dmitry Golovin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>  I want to build LLVM-based toolchain with Musl, I have LLVM sources with clang and lld (under `tools` directory) and libunwind, compiler-rt, libcxx and libcxxabi (under `projects` directory). All are

On 22 October 2014 19:24, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) testing > of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say that > it's not possible to test libunwind on arm-linux when using compiler_rt? Yeah, it's hard and clumsy, not impossible. Basically,

+llvmdev. I find this pretty surprising. Actually, we already use std::mutex and std::recursive_mutex in clang, lld, and other llvm projects, it's just a coincidence that it hadn't been introduced into LLVM until my commits. I'm not sure what the right thing to do here is. If I understand correctly, it seems like in order to encounter this, a) you must be using GCC, b) you must be