search for: may_throw

...the same model for CLR filters). In particular, when an outer filter is invoked before entering an inner finally, which piece of IR reflects the filter's side-effects? To take a concrete example, consider this C code: void foo() { int x; __try { x = 0; __try { x = 2; may_throw(); } __finally { if (x == 1) { printf("correct\n"); } else { printf("incorrect\n"); } } } __except (x = 1) { } } The IR for the path from "x = 2" to the load of x in the __finally (via the exception edge) loo...

...that > you just need to think of LLVM as modeling speculative code barriers as > memory dependence. In LLVM, it makes no sense to have a readonly > may-throw call. The problem is that that model breaks down with aggressive aliasing like: void foo(int* restrict ptr) { *ptr = 40; may_throw(); // read/write call *ptr = 50; } Now it is tempting to CSE the store of 40 to *ptr. If we can't do that then what does restrict/noalias even mean? -- Sanjoy

...problem shown here which will lead to incorrect code on the method test::run(). In this example, the virtual function called from within the exception handler triggers the bug when using -fprofile-generate. #include <stdexcept> #include <iostream> extern void may_throw(int); class base { public: base() : x(0) {}; int get_x() const { return x; } virtual void update() { x++; } int x; }; class derived : public base { public: derived() {} virtual void update() { x--; } };...

...lead to > incorrect code on the method test::run(). In this example, the virtual > function called from within the exception handler triggers the bug when > using -fprofile-generate. > > #include <stdexcept> > #include <iostream> > > extern void may_throw(int); > > class base { > public: > base() : x(0) {}; > int get_x() const { return x; } > virtual void update() { x++; } > int x; > }; > > class derived : public base { > public: > derived() {}...

Is this example what you had in mind? void f() { int *p = get_p(); use_p(p); try { may_throw(p); } catch (int) { // don't need p } use_p(p); } The idea is that because p is not modified or used within the catch region (the funclet), it can live in a callee-saved register across the whole function. That is true, it is possible, but I don't think it fits very well in our...

https://llvm.org/docs/ExceptionHandling.html#wineh > No variables live in to or out of the funclet can be allocated in registers. I don't think this is quite true. though it might be a useful simplification. Obviously it is true for volatile registers, but I believe the funclet receives a CONTEXT with the nonvolatiles restored. Obviously cumbersome to access, but it lets you enregister

> > > LLVM's design decision is one where everything has to explicitly care > about implicit early exits to get correct answers (and not to harp too > much, but "not everything does", years later). If they don't, they will > get wrong answers. > > So, ironically, while looking at this, i noticed it turns out LLVM's PRE in GVN is another place that

...> > > memory dependence. In LLVM, it makes no sense to have a readonly > > > may-throw call. > > > > The problem is that that model breaks down with aggressive aliasing > > like: > > > > void foo(int* restrict ptr) { > > *ptr = 40; > > may_throw(); // read/write call > > *ptr = 50; > > } > > > > Now it is tempting to CSE the store of 40 to *ptr. If we can't do > > that then what does restrict/noalias even mean? > > I thought it meant ‘ptr’ doesn’t alias with other ‘restrict’ pointer > args. No...

Okay, so it sounds like it might actually be better to be even more low level, call it "ExtendedBBInfo" or something, and rename what it provides to be more clearly structural: A. Inst * FirstIsGuaranteedToTransferExecutionToSuccessor(BB) (naming bikeshed open on this one :P) B. Inst * LastIsGuaranteedToTransferExecutionToSuccessor(BB) C. Inst *FirstMayThrow(BB) D. Inst