similar to: Exceptions and performance

There is a fair amount of dispute and detail here, and real benchmarks can be difficult to write, because you often end up in arguments about whether or not the two styles of coding are equivalent or not. But I agree with Dave--exceptions generally inhibit optimization. One way to think about this is that, generally speaking, the less the compiler can prove about a program, the less aggressive

On Thu, Aug 13, 2020 at 4:38 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Hello David and Sterling, thanks for the reply! > > I have no intention to heat up the discussion, please pardon me if I asked questions that might sound silly to you -- it's just that I truly didn't understand since I'm not expert in llvm or optimizer or exception handling at all. >

On Thu, Aug 13, 2020 at 6:11 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the insights David! > > For your first 3 points, is it correct to understand it as following: the external function prototypes are missing reliable information on whether the function throws and what exceptions it may throw (due to C++'s design failures and that it is impractical to

On Thu, Aug 13, 2020 at 6:35 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the reply. > >> Sorry, yes. No difference between explicit error handling and >> exceptions. The difference is in all the functions that don't have >> explicit error handling but (in the exception-using equivalent code) >> aren't marked nothrow (where, without

> > I did some experiments about a year ago with different hand-written > assembly implementations of error handling control flow patterns and it > was really hard to beat the checked return on recent Intel hardware. > This was a microbenchmark, so didn't see effects from increased cache > usage. That's a very interesting result. Thanks for the insights! Just out of

On 9 Feb 2017, at 08:41, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Feb 8, 2017 at 5:45 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > What isn’t clear to me still is : why shouldn't this be transitive? > In the example you’re showing, for a caller of f() in bar, what is the advantage of knowing that f() is nounwind if it an

Hi, Thanks for the quick reply again. > On Thu, Dec 15, 2011 at 1:17 PM, David Fang <fang at csl.cornell.edu> wrote: >> Hi, >> >> I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and >> have the following test results to share. >> Summary below, full log at: >>

Hello, Could anyone kindly explain to me why the 'g()' in the following function cannot have tail call optimization? > void f(int* x); > void g(); > void h(int v) { > f(&v); > g(); > } > A while ago I was taught that tail call optimization cannot apply if local variables needs to be kept alive, but 'g()' doesn't seem to require anything to be

Hello, I recently noticed a performance issue of JIT execution vs native code of the following simple logic which computes the Fibonacci sequence: uint64_t fib(int n) { if (n <= 2) { return 1; } else { return fib(n-1) + fib(n-2); } } When compiled natively using clang++ with -O3, it took 0.17s to compute fib(40). However, when executing using LLJIT, fed with the IR output of "clang++

Hello, I recently hit an issue when JIT'ing my generated IR using llvm::orc::LLJIT. My IR contains the following definition of a global variable: > $_ZZ23TestStaticVarInFunctionbE1x = comdat any > @_ZZ23TestStaticVarInFunctionbE1x = linkonce_odr dso_local global i32 123, > comdat, align 4 > And in my host process, there exists the same symbol. I would expect LLJIT to resolve the

Hi friendly LLVM Devs, I'm trying to understand the technical details of tail call optimization, but unfortunately I hit some issues that I couldn't figure out myself. So I tried the following two really simple functions: > extern void g(int*); > void f1() { > int x; > g(&x); > } > void f2(int* x) { > g(x); > } > It turns out that 'f1'

Thank you so much David! After thinking a bit more I agree with you that attempting to add 'target-features' to my functions seem to be the safest approach of all. I noticed that if I mark the clang++ function as 'AlwaysInline', the inlining is performed normally. Is this a potential bug, given what you said that LLVM may accidentally move code using advanced cpu features outside

Hi, Recently I hit an issue that LLJIT crashes when CodeGenOpt::Less or higher is given. After investigation, it turned out that the issue is some global constant string in the IR, like > @.str.117 = private unnamed_addr constant [9 x i8] c"lineitem\00", align 1 > becomes an invalid pointer in the generated code. > $1 = 0xf7fab054 <error: Cannot access memory at address

Hi David, Thanks for your quick response! I now understand the reason that inlining cannot be done on functions with different target-attributes. Thanks for your explanation! However, I think I didn't fully understand your solution; it would be nice if you would like to elaborate a bit more. Here's a bit more info on my current workflow: (1) The clang++ compiler builds C++ source file

I am nuilding that now. CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_SHARED_LIBS=ON \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \ -DLLVM_HOST_TRIPLE=x86_64-pc-linux-gnu \ -DLLVM_TARGETS_TO_BUILD="AMDGPU;MSP430;WebAssembly;X86" \

Hello, I'm new to LLVM and I recently hit a weird problem about inlining behavior. I managed to get a minimal repro and the symptom of the issue, but I couldn't understand the root cause or how I should properly handle this issue. Below is an IR code consisting of two functions '_Z2fnP10TestStructi' and 'testfn', with the latter calling the former. One would expect the

After a long tale of sorrow and woe, my colleagues and I stand here before you defeated. The Itanium EH representation is not amenable to implementing MSVC-compatible exceptions. We need a new representation that preserves information about how try-catch blocks are nested. WinEH background ------------------------------- Skip this if you already know a lot about Windows exceptions. On Windows,

On Aug 10, 2018, at 1:28 PM, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > * The clock stuff being added in C++20 has already been discussed here. I’ve missed the discussions on file_time_type, however I thought I should throw in my opinion here before it is too late to do anything about it. I believe it is a mistake to model file_time_type with 128 bits. It

On Fri, May 15, 2015 at 5:27 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I like the way this sorts out with regard to funclet code generation. > It feels very natural for Windows EH, though obviously not as natural for > non-Windows targets and I think it is likely to block some optimizations > that are currently possible with those targets. > Right, it will

Hello, I recently found that LLVM generates sub-optimal assembly for a tail call optimization case. Below is an example (https://godbolt.org/z/ao15xE): > void g1(); > void g2(); > void f(bool v) { > if (v) { > g1(); > } else { > g2(); > } > } > The assembly generated is as follow: > f(bool): # @f(bool) > testb %dil, %dil > je .LBB0_2 >