search for: constprop

Building with MinGW-w64 GCC 5.3.0 via Makefile.lite, I get the following warnings: bitwriter.c: In function 'FLAC__bitwriter_write_utf8_uint64': bitwriter.c:324:19: warning: inlining failed in call to 'FLAC__bitwriter_write_raw_uint32.constprop': --param large-function-growth limit reached [-Winline] inline FLAC__bool FLAC__bitwriter_write_raw_uint32(FLAC__BitWriter *bw, FLAC__uint32 val, unsigned bits) ^ bitwriter.c:826:9: warning: called from here [-Winline] ok &= FLAC__bitwriter_write_raw_uint32(bw, 0x80...

...079604] Corrupted memory at 0x0000000025448a9e [ ! ! ! . . . . . . . . . . . . . ] (in kfence-#183): [21963.079711] free_async+0x1d8/0x1e0 [21963.079728] usbdev_ioctl+0x138/0x1c40 [21963.079744] __arm64_sys_ioctl+0xd0/0x130 [21963.079769] invoke_syscall+0x7c/0x130 [21963.079793] el0_svc_common.constprop.0+0x6c/0x160 [21963.079815] do_el0_svc+0x38/0x120 [21963.079835] el0_svc+0x34/0xc0 [21963.079856] el0t_64_sync_handler+0x11c/0x150 [21963.079876] el0t_64_sync+0x198/0x19c [21963.079892] [21963.079899] kfence-#183: 0x0000000070088b17-0x00000000bed184b6, size=5, cache=kmalloc-128 [21963.079899] [...

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

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 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 > >

...ke to propose a new intrinsic for use in preventing optimizations from deleting IR due to constant propagation, dead code elimination, etc. # Background/Motivation In Rust we have a crate called `test` which provides a function, `black_box`, which is designed to be a no-op function that prevents constprop, die, etc from interfering with tests/benchmarks but otherwise doesn't negatively affect resulting machine code quality. `test` currently implements this function by using inline asm, which marks a pointer to the argument as used by the assembly. At the IR level, this creates an alloca, stores...

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 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 >

Hi all, I just found an optimization regression regarding simple dataflow/constprop analysis: https://godbolt.org/g/Uz8P7t This code ``` int dataflow(int b) { int a; if (b==4) a = 3*b; // fully optimized when changed to a = 3; else a = 5; if (a == 4) return 0; else return 1; } ``` is no longer optimized to just a "return 1". The regression ha...

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 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

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 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) { >

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

...e_xmit_skb+0x7f/0xc10 > > [ 310.029731] ? netif_skb_features+0x920/0x920 > > [ 310.033469] ? __skb_tx_hash+0x2f0/0x2f0 > > [ 310.035615] ? validate_xmit_skb_list+0xa3/0x100 > > [ 310.037782] sch_direct_xmit+0x2eb/0x7a0 > > [ 310.039842] ? dev_deactivate_queue.constprop.29+0x230/0x230 > > [ 310.041980] ? netdev_pick_tx+0x212/0x2b0 > > [ 310.043868] __dev_queue_xmit+0x12fa/0x20b0 > > [ 310.045564] ? netdev_pick_tx+0x2b0/0x2b0 > > [ 310.047210] ? __account_cfs_rq_runtime+0x630/0x630 > > [ 310.048301] ? update_stack_state+0x402...

...e_xmit_skb+0x7f/0xc10 > > [ 310.029731] ? netif_skb_features+0x920/0x920 > > [ 310.033469] ? __skb_tx_hash+0x2f0/0x2f0 > > [ 310.035615] ? validate_xmit_skb_list+0xa3/0x100 > > [ 310.037782] sch_direct_xmit+0x2eb/0x7a0 > > [ 310.039842] ? dev_deactivate_queue.constprop.29+0x230/0x230 > > [ 310.041980] ? netdev_pick_tx+0x212/0x2b0 > > [ 310.043868] __dev_queue_xmit+0x12fa/0x20b0 > > [ 310.045564] ? netdev_pick_tx+0x2b0/0x2b0 > > [ 310.047210] ? __account_cfs_rq_runtime+0x630/0x630 > > [ 310.048301] ? update_stack_state+0x402...

...18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: G E 5.10.0-rc2-1-default+ #581 [ 18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24 10/24/2018 [ 18.346032] Call Trace: [ 18.348536] dump_stack+0xae/0xe5 [ 18.351919] print_address_description.constprop.0+0x17/0xf0 [ 18.357787] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.363818] __kasan_report.cold+0x20/0x38 [ 18.368099] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.374133] kasan_report+0x3a/0x50 [ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [no...

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

Hi, I just started working with llvm, I am trying to test and improve the constant propagation pass (-constprop), I have two main questions, 1. I wrote my own test file, which has something like int a = 1 int b = a + 2; int c = b + 3; print c However, non of the instruction was killed according to -stat. I think it might due to the fact the llvm instructions generated was a bit convoluted,...

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