search for: guarding

Hi all, TL;DR: Should the loop guard branch be part of the canonical loop structure? Background: ----------- While working on the next set of improvements to loop fusion, we discovered that loop rotation will put a guard around a loop if it cannot prove the loop will execute at least once, as seen in the following (simplified) example: entry: br i1 %cmp1, label %for.body.lr.ph, label

Hello Everyone, I want to raise a discussion about @llvm.experimental.guard intrinsic and reasons why we should give up using it. Here is an alternative approach to representation of guards that resolves some of fundamental flaws that the current guards have. Basically, this intrinsic was introduced to model the following situation: we want to check that some condition is true, and if it's

Hi Sanjoy, Thanks for feedback! As for memory effects, currently I use " inaccessiblememonly " for it. It allows to prove that it doesn't alias with any other load/store in the function, but doesn't allow CSE to eliminate it. It is not actually super-cool, because there is no way that we can safely hoist it out of loop (and sometimes we want to, for example to make unswitching).

On Hexagon, unguarded loops cannot be converted to hardware loops. If the loop's latch branch alone handles the iteration count, including the possibility of 0, then the loop cannot be converted to a hardware loop, because hardware loops must iterate at least once. If the entire loop is guarded against zero iteration count, we can put the loop setup in the preheader, since at that point the

All, TLDR: guards currently require reasoning about implicit control flow.  LLVM struggles with implicit control flow within a basic block.  We should redesign guards to admit this rather than trying to boil the ocean. As you may be aware, LLVM currently has experimental support for a construct called a "guard".  A guard is like a branch to a potential deoptimzation point, except

Replies inline. At a high level, it feels like we'll eventually need a new instruction to represent the kind of control flow a guard entails (to be clear: we should probably still start with an intrinsic) -- they are fairly well-behaved, i.e. readonly, nounwind etc. as far as the immediate "physical" caller is concerned, but not so as far as its callers's callers are concerned.

Hi all, Guard intrinsics[0] are similar in nature to Assume intrinsics, in that the condition passed to a guard intrinsic call is known to be true at locations dominated (but *not* post-dominated) by the call[1]. I'd like to re-use the AssumptionCache infrastructure that already exists to teach the mid level optimizer to exploit this property. The steps I want to take are (not necessarily

R 2.1.0/src/include from 2005/04/18 download Naming inconsistent for guards as well but that's pedantic. Simple convention: file <foo.h> #ifndef R_FOO_H file <R_ext/bar.h> #ifndef R_EXT_BAR_H Missing guards: <IOStuff.h> <Internal.h> <Parse.h> <R_ext/GraphicsBase.h> <R_ext/GraphicsDevice.h> <R_ext/GraphicsEngine.h>

This is a proposal to add guard intrinsics to LLVM. Couple of glossary items: when I say "interpreter" I mean "the most conservative tier in the compilation stack" which can be an actual interpreter, a "splat compiler" or even a regular JIT that doesn't make optimistic assumptions. By "bailing out to the interpreter" I mean "side exit" as

Hello developeRs, Apologies in advance for a rather long email, but to describe the problem, I need to step through many details. I have been working on a new dispatching system (futile.paradigm on CRAN) based on functional programming concepts that is an alternative to S3 and S4 dispatching. I use a declarative syntax using guard statements to control the dispatching between function variants. I

On 05/16/2018 04:49 PM, Philip Reames wrote: > All, > > TLDR: guards currently require reasoning about implicit control flow.  > LLVM struggles with implicit control flow within a basic block.  We > should redesign guards to admit this rather than trying to boil the > ocean. > > As you may be aware, LLVM currently has experimental support for a > construct called a

...b/libswfdec/swfdec_as_frame.c index 5582f2b..841f438 100644 --- a/libswfdec/swfdec_as_frame.c +++ b/libswfdec/swfdec_as_frame.c @@ -860,26 +860,19 @@ swfdec_as_frame_get_this (SwfdecAsFrame *frame) /** * swfdec_as_frame_set_security: * @frame: the frame to be executed - * @guard: the security guarding this frame + * @guard: the security to be used in this frame * - * Checks that @guard allows executing the frame. The frame's security will - * be set to what @guard returns. By default, a frame has the security of - * its parent frame. If it's the first frame, it's allowed everything...

Hi, I was building LLVM with gcc 6.1.1 recently and it was spitting out some warnings relating to misleading indention that caught my eye. This wasn't a fresh build so I may have missed some. I've CC'ed the authors of the potentially misleading lines so they can decide what do about the warnings (if anything). I'm wondering if clang-format is making some inappropriate choices

I don't remember the details of the particular case where we encountered this, but I think the loop started with the condition check and ended with an unconditional branch back to the beginning. -- Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development -----Original Message----- From: Philip Reames <listmail at philipreames.com> Sent: Thursday, May 30, 2019 3:00 PM

Sanjoy gave the long answer, let me give the short one. :) "deopt" argument bundles are used in the middle end, they are lowered into a statepoint, and generate the existing stackmap format. i.e. one builds on the other. On 02/18/2016 11:43 AM, Eric Christopher wrote: > Hi Sanjoy, > > A quick question here. With the bailing to the interpreter support > that you're

It was found that passing an invalid cpu number to pv_vcpu_is_preempted() might panic the kernel in a VM guest. For example, [ 2.531077] Oops: 0000 [#1] SMP PTI : [ 2.532545] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2.533321] RIP: 0010:__raw_callee_save___kvm_vcpu_is_preempted+0x0/0x20 To guard against this kind of kernel panic, check is added to pv_vcpu_is_preempted() to

It was found that passing an invalid cpu number to pv_vcpu_is_preempted() might panic the kernel in a VM guest. For example, [ 2.531077] Oops: 0000 [#1] SMP PTI : [ 2.532545] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2.533321] RIP: 0010:__raw_callee_save___kvm_vcpu_is_preempted+0x0/0x20 To guard against this kind of kernel panic, check is added to pv_vcpu_is_preempted() to

Given the following C++ code: ``` // test.cpp struct Foo { int public_foo(); int outside_foo(); [[gnu::always_inline]] int inline_foo() { int x = outside_foo(); if (x % 17) { x += 1; } return x; } [[gnu::noinline]] int inline_bar1() { int x = inline_foo(); if (x % 23) { x += 2; } return x; } [[gnu::noinline]] int inline_bar2() {

On 03/25/2019 12:40 PM, Juergen Gross wrote: > On 25/03/2019 16:57, Waiman Long wrote: >> It was found that passing an invalid cpu number to pv_vcpu_is_preempted() >> might panic the kernel in a VM guest. For example, >> >> [ 2.531077] Oops: 0000 [#1] SMP PTI >> : >> [ 2.532545] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 >> [ 2.533321]

On 03/25/2019 12:40 PM, Juergen Gross wrote: > On 25/03/2019 16:57, Waiman Long wrote: >> It was found that passing an invalid cpu number to pv_vcpu_is_preempted() >> might panic the kernel in a VM guest. For example, >> >> [ 2.531077] Oops: 0000 [#1] SMP PTI >> : >> [ 2.532545] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 >> [ 2.533321]