similar to: Is there a way to know the target's L1 data cache line size?

I guess that in this case, what I would like to know is a reasonable upper bound of the cache line size on the target architecture. Something that I can align my data structures on at compile time so as to minimize the odds of false sharing. Think std::hardware_destructive_interference_size in C++17. Le 11/03/2017 à 13:16, Bruce Hoult a écrit : > There's no way to know, until you run

Thank you! Is this information available programmatically through some LLVM API, so that next time some hardware manufacturer does some crazy experiment, my code can be automatically compatible with it as soon as LLVM is? Le 11/03/2017 à 13:38, Bruce Hoult a écrit : > PowerPC G5 (970) and all recent IBM Power have 128 byte cache lines. I > believe Itanium is also 128. > > Intel

Le 13/10/2017 à 01:46, Jeremy Allison via samba a écrit : > On Thu, Oct 12, 2017 at 03:58:58PM +0200, Hadrien Grasland via samba wrote: >> Hi, >> >> We're slowly deprecating SMBv1 support at work, so I'm trying to >> mount our Samba network shares using SMBv2.0. This should in >> principle be supported by the server, and seems works well enough >> for

Hi, We're slowly deprecating SMBv1 support at work, so I'm trying to mount our Samba network shares using SMBv2.0. This should in principle be supported by the server, and seems works well enough for the Windows clients. But it fails for me with some errors which I do not understand. Can you help me figure out what's going on? Here's my system configuration and a quick

Hello, Lately, I have been working on moving Debian & Ubuntu packages to a stage2 build. This means that, instead of shipping llvm-toolchain packages built with gcc, we are rebuilding everything a second time using the newly built clang. Now, when pushed to Debian, it caused some unexpected issues in particular with rust reported here:

> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Hadrien Grasland via samba > Verzonden: vrijdag 13 oktober 2017 15:34 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] Share mounts in SMBv1 mode, but fails > weirdly in SMBv2 mode > > Hi Louis, > > Thanks for your reply! > > > This might be a

On Wed, Nov 11, 2015 at 07:14:28PM -0800, Sean Silva via llvm-dev wrote: > Can you show a real benchmark that users have tried to write where the call > overhead of actually using an external function call is measurable? This is the wrong question. The correct question is: What useful benchmark cannot trivally factor out the overhead of the external function call. Yes, if you do

The beautiful world of uncontained dependencies: - We restrict mockall to 0.11.0, which in practice currently expands to 0.11.4, - mockall depends on predicates-tree, - predicates-tree depends on predicates-core, - approx. two weeks ago, predicates-tree and predicates-core have seen *PATCHLEVEL* upgrades (1.0.7 -> 1.0.9, and 1.0.5 -> 1.0.6, respectively) that now require

On Tue, Jul 02, 2019 at 10:14:19PM +0900, Hiroyuki Katsura wrote: >From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> > >--- > Makefile.am | 4 ++++ > configure.ac | 3 +++ > generator/Makefile.am | 3 +++ > generator/bindtests.ml | 3 +++ > generator/bindtests.mli | 1 + > generator/main.ml | 5 +++++ > generator/rust.ml

I originally meant to post only the "vector.h" patch, but then (independently) nbdkit wouldn't build. Hence the other (rust plugin) patch. Laszlo Laszlo Ersek (2): common/utils: document empty_vector compound literal assignment plugins/rust: restrict predicates-{tree,core} to {1.0.7,1.0.5} common/utils/vector.h | 8 +++++++- plugins/rust/Cargo.toml | 2 ++ 2 files changed,

I have been working on adding proper tail (via `become`) to rustc. I was able to make them work (some parts of the type checker aren't implemented yet). However, I ran into an LLVM-related problem. LLVM claims to support proper tail calls when fastcc is used — but only on i386, x86-64 and PowerPC. Is this accurate? Will proper tail calls be supported on WebAssembly? Are they supported on

Hello, I'm currently doing a little music player using libflac and libao. What I've currently done works as it should, but I have a problem where only one metadata block is detected, even if there are more (it doesn't have the last attribute set to true). This is using flac 1.3.2 on Gentoo amd64. The main code file is attached, it mainly follows the examples given with the libflac

Hi, Sorry if you've seen this message before on llvm.discourse.group or elsewhere -- I've been trying to get to the bottom of this for a while now and asked about this in a few different platforms before. I'm currently trying to debug a bug in a LLVM-generated Wasm code. The bug could be in the code that generates LLVM (rustc) or in the LLVM, I'm not sure yet. LLVM IR and Wasm

Hi, This is Ariel from the Rust team again. I am having another pass ordering issue. Looking at the pass manager at https://github.com/llvm-mirror/llvm/blob/7034870f30320d6fbc74effff539d946018cd00a/lib/Transforms/IPO/PassManagerBuilder.cpp (the early SimplifyCfg now doesn't sink stores anymore! I can't wait until I can get to use that in rustc!) I find that the loop optimization group

Hi, compiler-rt builtins currently doesn't build on MSVC 2019, I the problem is that compiler-rt\lib\builtins\int_math.h includes the header ymath.h. according to eg. https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/finite-finitef?view=vs-2019 the header to include is float.h also the ymath.h file contains the comment /* ymath.h internal header */ so probably shall not be

Thanks Andy, helpful as always! 1 is a possibility, but not ideal for us. Could you elaborate a little on 3? I don't really know what a jump stub is, but am guessing it's a kind of "alternative symbol" which would just act as a middle man to invoke the "real" symbol in the static library. If that's the case, I can think of a way to implement it for specific

On Thu, Sep 12, 2019 at 8:18 AM Teresa Johnson <tejohnson at google.com> wrote: > I just have a couple suggestions off the top of my head: > - have you tried using the new pass manager > (-fexperimental-new-pass-manager)? That has access to additional analysis > info during inlining and is able to make more precise PGO based inline > decisions. > (although note the above

Hi everyone, As part of my work for Mozilla's Low Level Tools team I've implemented PGO in the Rust compiler. The feature is available since Rust 1.37 [1]. However, so far we have not seen any actual performance gains from enabling PGO for Rust code. Performance even seems to drop 1-3% with PGO enabled. I wonder why that is and I'm hoping that someone here might have experience

Interesting. By ld do you mean GNU ld? I know GNU ld does "work" with LLVM's gold plugin, but it's an untested combination and not recommended. I wouldn't be surprised if there were some issues around it not passing necessary info to the gold plugin. Teresa On Mon, Sep 16, 2019 at 8:41 AM Michael Woerister <mwoerister at mozilla.com> wrote: > So one interesting

Can you clarify if performance difference is caused by using different linkers at instrumentation build? If that is the case, try dump the sections of the resulting binary and compare __llvm_prf_** sections. Also check the arguments passed to the linker. It should have -u__llvm_profile_runtime to force the profile runtime to be linked in. David On Mon, Sep 16, 2019 at 8:42 AM Michael