similar to: [RFC] A new intrinsic, `llvm.blackbox`, to explicitly prevent constprop, die, etc optimizations

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

On Tue, Nov 3, 2015 at 3:15 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, Nov 3, 2015 at 12:29 PM, Richard Diamond < > wichard at vitalitystudios.com> wrote: > >> >> >> On Mon, Nov 2, 2015 at 9:16 PM, Daniel Berlin <dberlin at dberlin.org> >> wrote: >> >>> I'm very unclear and why you think a generic

The common use case I've seen for a black box like construct is when writing microbenchmarks. In particular, you're generally looking for a way to "sink" the result of a computation without having that sink outweigh the cost of the thing you're trying to measure. Common alternate approaches are to use a volatile store (so that it can't be eliminated or sunk out of

On Mon, Nov 2, 2015 at 9:16 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > I'm very unclear and why you think a generic black box intrinsic will have > any different performance impact ;-) > > > I'm also unclear on what the goal with this intrinsic is. > I understand the symptoms you are trying to solve - what exactly is the > disease. > > IE you say

On Mon, Nov 2, 2015 at 7:19 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Why does this need to be an intrinsic (as opposed to generic "unknown > function" to llvm)? > > Secondly, have you looked into a volatile store / load to an alloca? That > should work with PNaCl and WebAssembly. > > E.g. > > define i32 @blackbox(i32 %arg) { >

Hi Richard, You don't appear to have addressed my suggestion to not require a perfect external world, instead to measure the overhead of an imperfect world (by using an empty benchmark) and subtracting that from the measured benchmark score. Besides which, absolute benchmark results are more than often totally useless - the really important part of benchmarking is relative differences.

On Tue, Nov 3, 2015 at 2:50 PM, Diego Novillo <dnovillo at google.com> wrote: > I don't see how this is any different from volatile markers on > loads/stores or memory barriers or several other optimizer blocking > devices. They generally end up crippling the optimizers without much added > benefit. > Volatile must touch memory (right?). Memory is slow. > Would it

On Fri, 06 Nov 2015 09:27:32 -0800, Daniel Berlin via llvm-dev wrote: <snip> > > Great! > > You should then test that this happens, and additionally write a test > that can't be optimized away, since the above is apparently not a useful > microbenchmark for anything but the compiler ;-) > > Seriously though, there are basically three cases (with a bit of >

On Mon, Nov 16, 2015 at 9:07 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Mon, Nov 16, 2015 at 8:55 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > > > On Mon, Nov 16, 2015 at 6:59 PM, Dmitri Gribenko via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> > >> On Mon, Nov 16, 2015 at 10:03 AM, James Molloy via

I think the idea is to model the intrinsic as a normal external function call: - Can read/write escaped memory - Escapes pointer args - Functionattrs cannot infer anything about it - Returns a pointer which may alias any escaped data It's obvious how this works at the IR level, but I'm not sure what would happen in the backend. If you compile the intrinsic to nothing but a virtual

On Wed, Nov 11, 2015 at 10:41 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Wed, Nov 11, 2015 at 10:32 AM, Reid Kleckner <rnk at google.com> wrote: > >> I think the idea is to model the intrinsic as a normal external function >> call: >> > - Can read/write escaped memory >> > - Escapes pointer args >> - Functionattrs cannot infer

One thing that volatile doesn't do is escape results that have been written to memory. The proposed blackbox intrinsic is modeled as reading and writing any pointed to memory, which is useful. I also think blackbox will be a lot easier for people to use than empty volatile inline asm and volatile loads and stores. That alone seems worth something. :) On Mon, Nov 9, 2015 at 6:04 PM, Daniel

On Wed, 11 Nov 2015 11:13:43 -0800, Daniel Berlin via llvm-dev wrote: <snip for gmane> > Heck, i could even reason about inline asm if i wanted to ;-). > > My point is that this call is super special compared to all other > calls, > and literally everything in LLVM has to understand that. > The liklihood of subtle bugs being introduced in functionality (IE >

Hi all, I'm getting rather odd behavior from a call asm inteldialect(). TL;DR is "mov reg, $0" with a "i" constraint on $0 is behaving identical to "mov reg, dword ptr [$0]" and differently from "movl $0, reg" in AT&T syntax. I'm not sure how to get clang to emit an inteldialect, so for this example, I'm emitting llvm and then modifying

> On Jan 7, 2020, at 18:41, Craig Topper <craig.topper at gmail.com> wrote: > > What version of llvm are you using? This looks like it may be fixed on trunk. After poking at my installation of rust, I'm not entirely sure what version of LLVM it uses. Looking at the GitHub page, it looks like Rust maintains their own copy of llvm and cherry picks commits. The C example was

On Mon, Nov 16, 2015 at 6:59 PM, Dmitri Gribenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Nov 16, 2015 at 10:03 AM, James Molloy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > You don't appear to have addressed my suggestion to not require a perfect > > external world, instead to measure the overhead of an imperfect world (by > >

Hi all, I'm trying to land (a rebased version of) http://llvm.org/D37461 - which should make it possible to handle x86 Intel assembly like mov eax, offset Foo::ptr + 1 (Currently, omitting the +1 works... but offset doesn't work in compound expressions.) I'm having trouble figuring out what inline assembly I can emit into the LLVM IR that will work properly. So far, the closest

Hi all, I'm working for translating dex bytecode to LLVM IR In order to communicate with Android interpreter, The work have to add data below some instructions I want to use inline assembly to add data. Thus, I wrote a little program to find out the related LLVM IR int main() { asm(".long 0x12345678"); return 0; } and I use clang to translate it into bitcode It's the

> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > >> On 2015.02.28 14:23:02 -0800, Philip Reames wrote: >>> On 02/28/2015 10:04 AM, Björn Steinbrink wrote: >>> Hi, >>> >>>> On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >>>> ----- Original Message ----- >>>>> From: "Philip

On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > Hi, > > On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >> ----- Original Message ----- >>> From: "Philip Reames" <listmail at philipreames.com> >>>> 6. Use the lifetime.start/lifetime.end and >>>> invariant.start/invariant.end intrinsics where possible >>> Do you find these