search for: mispredictions

Hi Guys, I am an absolute newbie to the compiler community. I am experimenting a little bit with llvm. I have a few small questions, i would be really great if someone could help me. 1. Can i find out (is there something already built), if the previous instruction / or some instruction was a cache miss. Basically i want to detect cache misses and instructions that are causing this 2. Can i find

Ketan Pundlik Umare wrote: > Hi Guys, > I am an absolute newbie to the compiler community. I am experimenting a little bit with llvm. > I have a few small questions, i would be really great if someone could help me. It sounds like what you want is valgrind --tool=cachegrind (or --tool=callgrind). See http://valgrind.org/ > 1. Can i find out (is there something already built), if the

...r time, page fault. No one in the real world does this. Instead the use tools like Shark or vtune. You can say, show me all the instructions that missed cache and how often they missed. > 2. Can i find if there was a branch misprediction? Likewise. Though, I'm trying to recall if mispredictions where one of the things one could watch for on x86. google around for performance counters on x86. > 3. Can i find if a branch was taken or not taken? :-) gcov will tell you this today.

Thanx a lot Guys!! But i have to do this online and and use it to do some kind code transformation. Its for a different project. But all this has given me a quite a bit of knowledge.Wow!!! Thank you Best Ketan ----- Original Message ----- From: "OvermindDL1" <overminddl1 at gmail.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday,

On Mon, Sep 29, 2008 at 6:30 PM, Mike Stump <mrs at apple.com> wrote: > /* snip */ AMD's CodeAnalyst is free and quite wonderful at this job. Shows details about just about anything the CPU reports (and on newer AMD CPU's there is an even more ridiculous amount of information) about every little function call, time they took, multiple profiling modes, etc...

Than a lot John!!!! That was great, i wanted to read the performance counter, but was always afraid how llvm would react (virtual machine) Thanx for the resource i ll go through it. i think i read somewhere that llvm doesnot support assembly instructions??? Also can you redirect me to run-time transforms for llvm, where can i find the material. I thought that the transfor pass is done on the IR

Hi, Thanks for your email, I understand that the execution stalls until the predicated state is computed, then we mask pointers with all_zeros_mask if there is a mis-prediction. But I understand that as soon as the condition value is available, the processor can check about it's assumptions and revert back. That is, If the branch prediction is correct during speculation, we mask with

Hi, Yeah, now I understand the problem here. Thanks. But I too have another doubt in "Bounds check bypass store" In this example in the Speculative load hardening : unsigned char local_buffer[4];unsigned char *untrusted_data_from_caller = ...;unsigned long untrusted_size_from_caller = ...;if (untrusted_size_from_caller < sizeof(local_buffer)) { // Speculative execution enters here

Hello, I'm implementing a custom Haskell-to-LLVM compiler, and in my experimentation, noticed that GHC is much slower than clang certain examples, such as the ackermann function. However, from reading their respective IRs (Cmm for GHC and LLVM for clang), I don't really see much of a difference. Here is a link to the numbers. (n, m) are the parameters to the ackermann function

...56.hmmer -2.50% External/SPEC/CINT2006/464.h264ref/464.h264ref -1.60% MultiSource/Benchmarks/nbench/nbench -1.19% SingleSource/Benchmarks/Adobe-C++/functionobjects -1.07% I had a brief look at the regressions and they all look to be caused by getting bad luck with branch mispredictions: I looked into the Shootout-ary3 and yacr2 cases and in both the hot code path was the same with and without the patch, but with more mispredictions probably caused by changes elsewhere. John

Hi all, I understand how the speculative information flow attack works. I'm trying get my head around the spectre v1 mitigation of LLVM. In the design document here : https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening. <https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening> Example: void leak(int data);void example(int* pointer1,

On Feb 2, 2014, at 6:18 PM, Andrew Trick <atrick at apple.com> wrote: >> The result of such a system would produce weights for every block in the above CFG as '1.0', or equivalent to the entry block weight. This to me is a really useful metric -- it indicates that no block in the CFG is really more or less likely than any other. Only *biases* in a specific direction would

On 28 July 2016 at 16:14, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Can I ask you why you chose to patch both function entrances and exits, > rather than just patching the entrances and (in the patches) pushing on the > stack the address of __xray_FunctionExit , so that the user function returns > normally (with RETQ or POP RIP or whatever else instruction)

On Jan 3, 2011, at 11:30 PM, Jakob Stoklund Olesen wrote: > I noticed that we generate code like this for i386 PIC: > > calll L0$pb > L0$pb: > popl %eax > movl %eax, -24(%ebp) ## 4-byte Spill > > I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched. Yes, this will defeat the

.../SPEC/CINT2006/464.h264ref/464.h264ref  -1.60% > MultiSource/Benchmarks/nbench/nbench  -1.19% > SingleSource/Benchmarks/Adobe-C++/functionobjects -1.07% > > I had a brief look at the regressions and they all look to be > caused by > getting bad luck with branch mispredictions: I looked into the > Shootout-ary3 and > yacr2 cases and in both the hot code path was the same with and > without the > patch, but with more mispredictions probably caused by changes > elsewhere. > > John > > __________________________________...

From: Evgeny Kravtsunov <emkravts@openvz.org> compare_ether_addr() implicitly requires that the addresses passed are 2-bytes aligned in memory. This is not true for br_stp_change_bridge_id() and br_stp_recalculate_bridge_id() in which one of the addresses is unsigned char *, and thus may not be 2-bytes aligned. Signed-off-by: Evgeny Kravtsunov <emkravts@openvz.org> Signed-off-by:

Thanks for pointing this out, Tim. Then maybe this approach is not the best choice for x86, though ideally measuring is needed, it is just that on ARM the current x86 approach is not applicable because ARM doesn't have a single return instruction (such as RETQ on x86_64), furthermore, the return instructions on ARM can be conditional. I have another question: what happens if the instrumented

> This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation should keep > from introducing additional observable side-effects, and it's clear that whatever did this did not account > for floating point exception. That’s a very reasonable statement, but I’m not sure it corresponds to the way we have typically approached this sort of problem. In

...64ref -1.60% >>> MultiSource/Benchmarks/nbench/nbench -1.19% >>> SingleSource/Benchmarks/Adobe-C++/functionobjects -1.07% >>> >>> I had a brief look at the regressions and they all look to be caused by >>> getting bad luck with branch mispredictions: I looked into the Shootout-ary3 and >>> yacr2 cases and in both the hot code path was the same with and without the >>> patch, but with more mispredictions probably caused by changes elsewhere. >>> >>> John >>> >>> ___________________________...

I noticed that we generate code like this for i386 PIC: calll L0$pb L0$pb: popl %eax movl %eax, -24(%ebp) ## 4-byte Spill I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched. From Intel's Optimization Reference Manual: "The return address stack mechanism augments the static and dynamic