similar to: llvm-config with shared libraries in cmake builds broken (since r257003?)

On 05/07/2018 12:28 AM, Nicolai Hähnle via llvm-dev wrote: > We have a similar problem in Mesa's radeonsi driver. It would be great if command-line options could somehow be tied to an llvm::Context, for example. > > There is an even worse problem when *different versions* of LLVM are loaded into the same process. This is basically guaranteed to lead to crashes because of symbol

On 07.05.2018 17:49, Tom Stellard wrote: > On 05/07/2018 12:28 AM, Nicolai Hähnle via llvm-dev wrote: >> We have a similar problem in Mesa's radeonsi driver. It would be great if command-line options could somehow be tied to an llvm::Context, for example. >> >> There is an even worse problem when *different versions* of LLVM are loaded into the same process. This is

Hey, So in Fedora rawhide we are now building llvm 3.7.1 into the lots of little shared libraries format. However I'm running into a major problem with the fact that sometimes dlclose isn't dropping all the LLVM libraries from the address space of the process. We have a sequence like this: a) X server asks mesa gbm library to init, it loads the kms_swrast_dri.so with

Hello everyone, A while back I hit an issue where the presence of multiple OpenCL runtimes on a single system triggered errors in libLLVM caused by redeclaring command line arguments [0]. There's been some discussion on the bug report and a pointer to a slightly older report, unrelated to OpenCL, but most likely about the same issue [1]. OpenCL uses an ICD loader library to abstract away

We have a similar problem in Mesa's radeonsi driver. It would be great if command-line options could somehow be tied to an llvm::Context, for example. There is an even worse problem when *different versions* of LLVM are loaded into the same process. This is basically guaranteed to lead to crashes because of symbol clashes. I wonder if C++11 inline namespaces could be used for proper

On 09.05.2016 05:19, Benjamin Kramer wrote: > On Mon, May 9, 2016 at 5:35 AM, Nicolai Hähnle <llvm-dev at lists.llvm.org> wrote: >> Hi everybody, >> >> I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment >> - i.e. data that needs to be touched by the dynamic linker even though it's >> ultimately read-only, and data that cannot be

This is also the case with the Visual Studio generators. Custom commands in a single cmake file essentially get written out line by line into a single batch file that gets processed as a custom build step. In the VS case this means that it can, for example, run X86 and Aarch64 tablegen steps in parallel with each other but all of the individual X86 invocations get processed serially. I can well

Hey Joan, When looking for build support it is really useful to include a bunch of information about your build up front. Knowing that you are on macOS, and using the Xcode generator are really useful. On macOS, BUILD_SHARED_LIBS won’t really help much because the default linker (ld64) is pretty good. Using an IDE generator and setting LLVM_USE_OPTIMIZED_TABLEGEN will kill your release builds.

FWIW, tablegen does not update timestamps for .inc files, if their contents is unchanged, so if you somehow affect a .td file's timestamp (without changing its contents) it will trigger rebuild of the corresponding .inc file with all subsequent incremental make builds. At the same time, this will not trigger rebuilding any targets dependent on this .inc file, since it is not modified. From

Hi everybody, I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment - i.e. data that needs to be touched by the dynamic linker even though it's ultimately read-only, and data that cannot be shared between multiple processes using LLVM. It turns out that a solid ~1.3MB of that data is in the tablegen'd MCInstrDesc tables - there a pointers for ImplicitUses,

Much of this has been discussed (over many, many years) on https://bugs.llvm.org/show_bug.cgi?id=28222 Some of the issues that were identified included: 1 - Poor tablegen dependency handling leading to unexpected rebuilds. 2 - Debug STL iterator checks taking an insane amount of time (might be MSVC specific). 3 - Lack of parallelization of custom commands (XCode and VS builds) - VS at least

If someone can manage it, it wouldn't be a bad thing - obviously open up more parallelism (I don't know how much of LLVM can be built before you hit everything that needs tblgen run - I guess libSupport and some other bits) On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev < llvm-dev at lists.llvm.org> wrote: > [resending to the whole list] > > > >

for example I want to insert a new machine bb “before” a specific machine bb. or split a mbb and keep the later one as the original one. (to keep the label/Blackadder's correct t) (or keep other property of mbb) so I need to transfer the original mbb's predecessor to the new mbb. Nicolai Hähnle <nhaehnle at gmail.com> 於 2020年3月13日 週五 23:57 寫道： > On Fri, Mar 13, 2020 at

Hello, this mail is to raise awareness of https://reviews.llvm.org/D81728, which is substantial enough of a conceptual change that it should probably at least be mentioned in llvm-dev. InstCombine has dealt with target-specific intrinsics for a long time, since its fix-point iteration is arguably the right place to do so. A downside is that there's a pull to add an increasing amount of code

Hi Praveen, Thanks for the tip, but Xcode seems to spend all the time running tablegen "custom shell scripts", one by one at a time, not linking. Linking is actually very fast, possibly less than a second. The “scripts” that take longer are “AArch64CommonTableGen" and “AMDGPUCommonTableGen”. As said this is on LLVM 9.0. However, on LLVM 7.0.1, the same process takes just 5-6

Any comments at all on this? Chandler perhaps? I've since dug a bit further, and it seems like the template-based solution wouldn't work anyway because DLL loading on Windows can't do the required commoning. So the general approach taken in https://reviews.llvm.org/D62802 seems to be the only technically viable path forward, though it would still be good to get an outside look at the

On 22.08.2018 13:29, Ryan Taylor wrote: > The example starts as SPIR-V with the NoContraction decoration flag on > the fmul. > > I think what you are saying seems valid in that if the user had put the > flag on the fadd instead of the fmul it would not contract and so in > this example the user needs to put the NoContraction on the fadd though > I'm not sure

On 24.10.2016 21:54, Mehdi Amini wrote: >> On Oct 24, 2016, at 12:38 PM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Some brain-storming on an issue with SPMD/SIMT backend support where I think some additional IR attributes would be useful. Sorry for the somewhat long mail; the short version of my current thinking is that I would like to have the following:

Hi, I am seeing an LLVM build failure with recent LLD on x86 like: [...] lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMScalarOpts.a lib/libLLVMAgg ressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMDebugInfoDWARF.a lib/lib LLVMMCDisassembler.a lib/libLLVMExecutionEngine.a lib/libLLVMTarget.a lib/libLLVMAnalysis.a lib/libLLVMProfil eData.a

Conditional on the target supporting cmov? Though that's probably not optimal. On Wed, Feb 5, 2020, 7:47 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > Hi Ryan, > > On Mon, Feb 3, 2020 at 7:08 PM Ryan Taylor via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > SimplifyCFG FoldTwoEntryPhiNode looks to simplify all 2 entry phi nodes > in a block, if it