similar to: Adding custom callback function before/after passes

Hello Fedor. Thank you for the information. I made a simple patch that exposes PassInstrumentationCallback so llvmGetPassPluginInfo can use it: https://reviews.llvm.org/D71086 . Would this change make sense? Thanks, Juneyoung Lee On Thu, Dec 12, 2019 at 12:44 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 12/3/19 8:01 PM, Juneyoung Lee via llvm-dev wrote: > >

Hi all, I'm porting some LLVM plugins to the new pass manager and I've noticed that the command line options are no longer registered when using `-load-pass-plugin` (the new PM flag) to load the plugins in opt. Everything is back to normal when loading via `-load` (the legacy PM). For example, given this CL option: static cl::opt<bool> SomeFlat("some-flag",

On 8/6/19 7:31 PM, Fedor Sergeev via llvm-dev wrote: > > > On 8/6/19 3:02 AM, Hiroshi Yamauchi via llvm-dev wrote: >> I had a chance to try -print-after-all with NPM. >> >> It seems like there's still no output for the passes >> before objc-arc-contract (which is basically what I saw before.) Does >> anyone else see this? >> >> Are we

I had a chance to try -print-after-all with NPM. It seems like there's still no output for the passes before objc-arc-contract (which is basically what I saw before.) Does anyone else see this? Are we talking about the same thing? *** IR Dump After ObjC ARC contraction *** *** IR Dump After Pre-ISel Intrinsic Lowering *** *** IR Dump After Expand Atomic instructions *** *** IR Dump After

On 8/7/19 6:20 PM, Hiroshi Yamauchi wrote: > I basically run "clang > -fexperimental-new-pass-manager -print-after-all ..." > > It's conceivable that something is different in our setup or in clang > (from opt)... I'll see if I can reproduce it outside our setup. Does it depend on machine architecture? I generally use x86... regards,   Fedor. > > Thanks.

TL;DR ==== This RFC suggests an API to enable customizable instrumentation of pass execution. The intent is to have a common machinery to implement all the pass-execution-debugging features mentioned here. Prime target of the interface is the new pass manager. The overall approach and most of the implementation details should be equially applicable to the legacy one though. Background

On 06/07/2018 06:11 PM, Chandler Carruth wrote: > We had already talked about this, so unsurprisingly I'm generally in > favor of the direction. Some comments below. > > On Thu, Jun 7, 2018 at 2:00 AM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >    - access through LLVM Context (allows to control life-time and

Care to expand a bit on what you mean by per-optimization level? Preferably with a use case. To me optbisect is a low level developer tool and it doesn't cope well with a crude user level hammer of optimization level. F. On Fri, Jun 8, 2018 at 9:12 AM +0300, "Zhizhou Yang" <zhizhouy at google.com<mailto:zhizhouy at google.com>> wrote: Hi Fedor, Thanks for replying

Thanks Craig, that's exactly what I mean, stopping at particular changes inside a pass. Would you please refer me the discuss about combining opt-bisect with debug counters? Is it already under implementation? On Fri, Jun 8, 2018 at 12:19 AM Craig Topper <craig.topper at gmail.com> wrote: > I think that "level" was referring to what level of granularity the >

I was going to write something up about fine-grained opt-bisect but didn't get to it last week. We've had a -pass-max option here for some time and have hand-added instrumentation to various passes to honor it. It's saved us man-years of debug time. I was planning on sending it upstream but saw this effort with pass execution instrumentation and thought it might fit there.

I think it’s reasonable to expect that IR generated by frontends doesn’t do this. Not sure about transforms; I can imagine that we might speculate a load without proving all the bits are well-defined. -Eli From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Juneyoung Lee via llvm-dev Sent: Sunday, September 20, 2020 3:54 PM To: llvm-dev <llvm-dev at lists.llvm.org>

> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap representations for unsigned char, two's complement > signed char, etc.). This interpretation is further stressed because C only explicitly ascribes > undefined behaviour to trap

Hello all, Is it valid to dereference a pointer that has undef bits in its offset? For example, %p = alloca [8 x i8] %p2 = gep %p, (undef & 8) store 0, %p2 undef & 8 is always less than 8, so technically it will store zero to one of the array's elements. The reason is that I want to improve no-undef analysis by suggesting that a pointer that is passed to load/store is

Thank you for the infos; it seems making it raise UB is problematic. Would clarifying it in LangRef be good? I can update the patch to contain the information instead. Another concern is then, how can we efficiently encode an assumption that a pointer variable in IR does not have undef bits? Certainly, in the front-end language, (most of) pointers won't have undef bits, and it would be great

> > // Members are initialized to poison at object creation. >> p = alloca {i8, i32} // p[0], p[4~7] are poison >> p[0] is an i8, so it shouldn't be poison? > > My interpretation of standard is that reading uninitialized char can also yield trap representation. If uninitialized, char variable has indeterminate value, and C/C++ does not seem to forbid reading trap

I think we need to allow this.  Otherwise, we have to prove that addresses are non-undef before we can hoist or sink a memory instruction.  Today, aliasing can use things like known bits, and if we imposed a no-undef in address requirement, we'd either need to replace such reasoning in AA, or have passes which wish to hoist/sink check the property afterwards. Or to say it differently, I

Hello all, How can I see the result of lazy value info analysis? I ran a command `opt -lazy-value-info -correlated-propagation -print-lazy-value-info example.ll -disable-output` with a following program as the input: ``` define i32 @f(i32 %a, i32 %b) { %i = icmp eq i32 %a, 10 br i1 %i, label %A, label %B A: %c = add i32 %a, 20 ret i32 %c B: ret i32 0 } ``` However, it shows a

It is UB when a poison is passed to certain operations that raise UB on poison, such as division by poison/dereferencing poison pointer/branching on poison condition/etc. Otherwise, poison is simply propagated, but it does not raise UB Copying poison bytes is okay: // Members are initialized to poison at object creation. p = alloca {i8, i32} // p[0], p[4~7] are poison q = alloca {i8, i32} // we

Hello Sanjoy, Yep, combining it with propagateEquality of pointers may raise problem. :\ However I believe propagateEquality should be fixed properly, and adding psub also suggests a solution for that. :) It is sound to replace a pointer with another if subtraction of them is 0: a = malloc() free(a) b = malloc() // Assume b == a numerically if ((psub inbounds a b) == 0) { // a and b are

Two thoughts: 1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB. 2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself.