search for: dbgopt

Hi, I'm following http://llvm.org/docs/SourceLevelDebugging.html#debugopt to do the dbgopt testing. But seems, there is something wrong with the Makefile, it told me : llvm-gcc sse.expandfft.c -g --emit-llvm -c -o Output/sse.expandfft.bc llvm-gcc: sse.expandfft.c: No such file or directory llvm-gcc: no input files Am I missing something, like the configure option? -------------- next...

> > Are you able to run nightly test ? > Yes, I can run nightly test. > Here is what I see... > > $ make TEST=dbgopt > /Developer/usr/bin//llvm-gcc sse.expandfft.c -g --emit-llvm -c -o > Output/sse.expandfft.bc > /Volumes/Nanpura/mainline/llvm/Debug/bin/opt Output/sse.expandfft.bc - > strip-nondebug -strip-debug -std-compile-opts -strip -f -o Output/ > sse.expandfft.t.bc > /Volumes/Nanpura/m...

...the debug stops kill > optimization, don't they? We worked hard to avoid this. Now if a debug stop point threatens to kill optimization then the llvm optimizer will kill the debug stop point itself! We have updated optimizer in all cases we could find. (Try running nightly tester using TEST=dbgopt and TEST=ipodbgopt and report failures.) However this means, in optimized code you may lose location info here and there. > We have our own privately-maintained way of tracking line information even > in optimized code but it's a big hack and not something suitable for > pushing upstr...

...+ } + + ret = nouveau_engine_create_(NULL, NULL, &nouveau_device_oclass, true, + "DEVICE", "device", length, pobject); + device = *pobject; + if (ret) + goto done; + + device->platformdev = pdev; + device->handle = name; + device->cfgopt = cfg; + device->dbgopt = dbg; + device->name = sname; + + nv_subdev(device)->debug = nouveau_dbgopt(device->dbgopt, "DEVICE"); + nv_engine(device)->sclass = nouveau_device_sclass; + list_add(&device->head, &nv_devices); +done: + mutex_unlock(&nv_devices_mutex); + return ret; +} diff -...

...LL, &nouveau_device_oclass, true, > + "DEVICE", "device", length, pobject); > + device = *pobject; > + if (ret) > + goto done; > + > + device->platformdev = pdev; > + device->handle = name; > + device->cfgopt = cfg; > + device->dbgopt = dbg; > + device->name = sname; > + > + nv_subdev(device)->debug = nouveau_dbgopt(device->dbgopt, "DEVICE"); > + nv_engine(device)->sclass = nouveau_device_sclass; > + list_add(&device->head, &nv_devices); > +done: > + mutex_unlock(&nv_devi...

On Thursday 09 July 2009 10:01, John Criswell wrote: > Dear All, > > To add to this, what you want to do is find the appropriate debug stop > point intrinsic and then use it to look up the information for that > instruction. Ick. So line number information is only available at debug stop points? That's bad when compiling optimized code since the debug stops kill optimization,

...+ } + + ret = nouveau_engine_create_(NULL, NULL, &nouveau_device_oclass, true, + "DEVICE", "device", length, pobject); + device = *pobject; + if (ret) + goto done; + + device->platformdev = pdev; + device->handle = name; + device->cfgopt = cfg; + device->dbgopt = dbg; + device->name = sname; + + nv_subdev(device)->debug = nouveau_dbgopt(device->dbgopt, "DEVICE"); + nv_engine(device)->sclass = nouveau_device_sclass; + list_add(&device->head, &nv_devices); +done: + mutex_unlock(&nv_devices_mutex); + return ret; +} diff -...

...; info but not variable info, we can go through the process above to >> > identify passes that change behavior when line number intrinsics are >> > in the code. >> > > I think, the optimizer is not changing behavior when dbg info is > present. Try running dbgopt tests. > > >> > Obvious cases are things like loop unroll and inlining: they >> > 'measure' the size of some code to determine whether to unroll it or >> > not. This means that it should be enhanced to ignore debug >> > intrinsics for the...

Dear All, To add to this, what you want to do is find the appropriate debug stop point intrinsic and then use it to look up the information for that instruction. Here is some sample code from SAFECode that finds the debug information associated with a CallInst (LLVM call instruction) held in the variable CI. It uses the findStopPoint() function in llvm/Analyis/DebugInfo.h: // // Get the

...ers/gpu/drm/nouveau/core/include/core/device.h b/drivers/gpu/drm/nouveau/core/include/core/device.h index ac2881d..d04c523 100644 --- a/drivers/gpu/drm/nouveau/core/include/core/device.h +++ b/drivers/gpu/drm/nouveau/core/include/core/device.h @@ -70,6 +70,7 @@ struct nouveau_device { const char *dbgopt; const char *name; const char *cname; + u64 disable_mask; enum { NV_04 = 0x04, -- 1.8.3.2

...uot;, "device", length, pobject); >> + device = *pobject; >> + if (ret) >> + goto done; >> + >> + device->platformdev = pdev; >> + device->handle = name; >> + device->cfgopt = cfg; >> + device->dbgopt = dbg; >> + device->name = sname; >> + >> + nv_subdev(device)->debug = nouveau_dbgopt(device->dbgopt, "DEVICE"); >> + nv_engine(device)->sclass = nouveau_device_sclass; >> + list_add(&device->head, &nv_devices); >>...

Hi, I've been thinking about how to keep the line number with the llvm transform/Analysis passes. Basically, I agree with Chris's notes ( http://www.nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt), and I will follow his way to turn on the line number information when optimization enabled. Here is a detailed proposal: 1. Introduction At the time of this writing, LLVM's

...name, const char *sname, if (ret) goto done; - device->pdev = pdev; + switch (type) { + case NOUVEAU_BUS_PCI: + device->pdev = dev; + break; + case NOUVEAU_BUS_PLATFORM: + device->platformdev = dev; + break; + } device->handle = name; device->cfgopt = cfg; device->dbgopt = dbg; diff --git a/drivers/gpu/drm/nouveau/core/engine/falcon.c b/drivers/gpu/drm/nouveau/core/engine/falcon.c index 5e077e4ed7f6..2914646c8709 100644 --- a/drivers/gpu/drm/nouveau/core/engine/falcon.c +++ b/drivers/gpu/drm/nouveau/core/engine/falcon.c @@ -119,7 +119,7 @@ _nouveau_falcon_init(stru...

Hello everyone, GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open

On 12/02/14 05:38, Alexandre Courbot wrote: > Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead > of PCI to which Nouveau is tightly dependent. This patch allows Nouveau > to handle platform devices by: > > - abstracting PCI-dependent functions that were typically used for > resource querying and page mapping, > - introducing a nv_device_is_pci()