Displaying 20 results from an estimated 5000 matches similar to: "llvm-config with shared libraries in cmake builds broken (since r257003?)"
2018 May 07
2
OpenCL runtimes and LLVM command line options
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
2018 May 08
0
OpenCL runtimes and LLVM command line options
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
2016 Feb 11
5
issues with split llvm libraries and llvmpipe and failing to load library
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
2018 May 06
2
OpenCL runtimes and LLVM command line options
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
2018 May 07
0
OpenCL runtimes and LLVM command line options
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
2016 May 09
2
Removing pointers from MCInstrDesc for less relocations
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
2019 Jun 30
2
Tablegen ridiculously slow when compiling for Debug
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
2019 Jul 01
2
Tablegen ridiculously slow when compiling for Debug
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.
2019 Jul 09
2
Tablegen ridiculously slow when compiling for Debug
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
2016 May 09
2
Removing pointers from MCInstrDesc for less relocations
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,
2019 Jul 02
4
Tablegen ridiculously slow when compiling for Debug
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
2019 Jul 01
3
Tablegen ridiculously slow when compiling for Debug
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]
>
>
>
>
2020 Mar 13
3
Why MachineBasicBlcok doesn't have transferPredecessors() ?
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
2020 Jun 29
5
Heads-up: Handling target-specific intrinsics in InstCombine
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
2019 Jun 30
3
Tablegen ridiculously slow when compiling for Debug
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
2019 Jun 06
3
[RFC] Expressing preserved-relations between passes from different modules (was: Re: Linker issue)
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
2018 Aug 22
4
Condition code in DAGCombiner::visitFADDForFMACombine?
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
2016 Oct 24
2
RFC: (Co-)Convergent functions and uniform function parameters
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:
2020 Feb 02
3
lld out of memory
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
2020 Feb 05
2
Eliminate some two entry PHI nodes - SimplifyCFG
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