similar to: Building LLVM through Bazel

> On Aug 14, 2018, at 2:43 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Yeah - not sure we're quite at the point where LLVM wants to start supporting two build systems again (used to be Configure+Make and the CMake system, now it's just the Cmake system), but if you want to make it work out-of-tree it shouldn't be too difficult (Google does

> > You could look at the cmake+ninja (or other build system) build and dump > the commands it executes (I think ninja produces a log, or can do so) which > should show you all the commands needed to build any part of LLVM. > There's a switch to dump all compiler commands as a JSON file: https://cmake.org/cmake/help/v3.12/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html On Wed,

I believe it would be possible to run a cmake command to generate a BUILD file, though I don't know if that would be easier to maintain on the LLVM side. Would definitely be happy to see direct support, though I was just trying to figure out what's needed to hack this together on my end. I guess my real question is what underlying commands are necessary to build all the source files

I tried running all the commands in the compile_commands.json (thanks for pointing that out), but it runs into the same "No such file or directory: *.inc". I don't see those files built anywhere in that list. Does it take tblgen into account? Doug On Thu, Aug 16, 2018, 1:02 PM Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > TensorFlow uses bazel to build LLVM:

Hi all, trust all is well! I was wondering if LLVM would have a Bazel integrated build in the future? I can imagine the benefits this could bring, especially with regards to remote builds and caching. I'm thinking of dumping the LLVM source-tree into my code-base and experiment with building LLVM via Bazel. Will pull requests be accepted for this? I won't mind contributing my changes

Hi Wynand, My big concern is related to what Mehdi mentioned as #4. Bazel doesn't really handle the configuration-management that CMake does, so adding Bazel support would really mean supporting an extra build system with no path for it to replace CMake. We're kinda already in that situation with gn, but gn is a developer productivity tool and we don't consider changes that break gn

I previously <https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/> proposed contributing Bazel build files to the LLVM monorepo, supported *only* by interested community members and not to interfere with or affect the existing CMake configuration. As part of that conversation, it became clear that the LLVM policies for more "peripheral" components were not clearly documented. We

On 11/16/20 10:01 PM, Geoffrey Martin-Noble via llvm-dev wrote: > I previously <https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/ > > proposed contributing Bazel build files to the LLVM monorepo, > supported *only* by interested community members and not to interfere > with or affect the existing CMake configuration. As part of that > conversation, it became clear that

Hello. I'm posting this question here, because there seem to be no LLD-specific mailing list. Sorry in advance if this is wrong one. I compile two C source with following command: clang -flto -o %name.bc %name.c LLVM is augmented with my custom pass, which amongst other things create a global with appending linkage: @myvar = appending constant [1 x [1 x i8]*] ... I also have another pass

> > >>> >>> One of our definitions of non-determinism is simply "output from command >>> line tools should always be bit identical given identical inputs", which is >>> suitable for content-based caching build systems like Bazel. >>> >> Just to point out: These systems already often have to ignore whitespace >> differences,

On Thu, Jul 6, 2017 at 12:34 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jul 6, 2017 at 10:20 AM, Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Thu, Jul 6, 2017 at 8:02 AM, Robinson, Paul via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>>

Hi all, The TensorFlow team at Google has been leading the charge to build a new set of compiler infrastructure, known as the MLIR project <https://github.com/tensorflow/mlir>. The initial focus has been on machine learning infrastructure, high performance accelerators, heterogeneous compute, and HPC-style computations. That said, the implementation and design of this infrastructure is

Hello all, LLVM-TAPI seeks to decouple the necessary link-time information for a dynamic shared object from the implementation of the runtime object. This process will be referred to as dynamic shared object (DSO) stubbing throughout this proposal. A number of projects have implemented their own versions of shared object stubbing for a variety of reasons related to improving the overall linking

On Tue, Sep 10, 2019 at 1:40 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > But perhaps more importantly, as Hal states clearly, is the need for > > an official specification, similar to the one for LLVM IR, as well as > > a formal document with the expected semantics into

Hi Teresa, Impressive results, indeed! (But no less is expected from an Itanium alumni... ;-)) One question, if you don't mind. In the blog post you wrote: "In a few cases ThinLTO even outperforms full LTO, most likely because the higher scalability of ThinLTO allows using a more aggressive backend optimization pipeline (similar to that of a non-LTO build)." Is it due to

Estimado Jesús Para Fernández En teoría es ese material, lo vi muy rápido y en la parte genética tiene cosas que biológicamente no son así, hay un libro de Falconer, Introducción a la genética cuantitativa, que tiene escrita la parte matemática, hay un abismo entre la biología y los ingenieros que se inspiran en la biología. Yo pensaba en la resolución de un problema real, aunque relativamente

> On Jul 22, 2016, at 12:36 PM, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Vikram, > > Thanks! > > I'm not sure what part got committed in the 3.8 timeframe - it looks like that was released back in March? 3.8 was branched in early January though. It has some of the work-in-progress for ThinLTO, it “could” work in simple cases I

Overall, I think it will be a good move. Maintenance wise, I'm expecting the existing community to move into LLVM (if not all in already), so I don't foresee any additional costs. Though, Hal's points are spot on... On Mon, 9 Sep 2019 at 18:47, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 3. As a specific example of the above, the current development

On 26 May 2015 at 14:58, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > The intention isn't to change the kind of triples/tuples in use by toolchains and users. There's a lot of legacy and inertia to overcome if we try that. The intention is to map the ambiguous/insufficient GNU triples onto an internal representation as early as possible and pass that internal

> From: Renato Golin [renato.golin at linaro.org] > Sent: 26 May 2015 18:43 > To: Daniel Sanders > Cc: Jim Grosbach; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo > > On 26 May 2015 at 14:58, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > > The intention