similar to: [LLVMdev] Proposal: Debug information improvement - keep the line number with optimizations

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

Hi Patel, Thanks for your comments, some reply below... (This is the first part, I'll send the second part later) > 2.1 Verification Flow > > The most important of this project is to make the debug information > > do not block any optimization by LLVM transform passes. Here I > > propose a way to determine whether codegen is being impacted by > > debug info.

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 part

Hi, just a quick question about the intent of the ApproximateLoopSize() function in LoopUnroll.cpp: If a loop contains debug stoppoint intrinsics, does it make sense to count them? My understanding is that they are removed when not running under llvm-db anyway, so we probably shouldn't make size judgements based on them. Is that right, or am I missing something? Anyway, if I'm right,

Hi David, On Thu, Jul 9, 2009 at 10:26 AM, David Greene<dag at cray.com> wrote: > 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

> > 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/ >

Add a nouveau_drm_platform_probe() function that probes a Nouveau platform device and registers it using drm_platform_init(). Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/engine/device/base.c | 34 ++++++++++++++++++++++ .../gpu/drm/nouveau/core/include/engine/device.h | 10 +++++++ drivers/gpu/drm/nouveau/nouveau_drm.c | 19

On Tue, Apr 14, 2015 at 03:20:08PM -0400, Gene Cumm wrote: > > I thought I would try to find out how pxelinux copes with this, by trying > > to insert printfs in pxe_init, but nothing gets printed. > > This is normal. Can you give me hint as to why setting > > DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 changes that state of normality? (AFAICT dprintf.h

Hello Duncan Sorry for the mistake. Actually that error occurred when I was compiling all the files at once, NOT in for loop. The for loop is working perfectly as it is dealing with individual files. I have now one new issue. Let me specify it briefly. If I compile the program using the following command line i.e. $ clang -O3 -lm *.c then $ time ./a.out real 0m2.606s user 0m2.584s sys

Sure. The comb.ll and data files are attached and can be invoked as the following $ lli comb.ll data -c Regards Shahzad On Tue, Jun 12, 2012 at 12:28 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > >> Yes, they both are exactly the same. > > > then I don't know what is going on.  I suggest you send a copy of comb.ll to > the > list so that we can

I have reason to believe that an odd box that is having boot trouble has three instances of "!PXE" in the chunk of memory that "Method D" should look at. I thought I would try to find out how pxelinux copes with this, by trying to insert printfs in pxe_init, but nothing gets printed. I can spew lots of output if I set DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 but

Optimization passes running before LoopVectorizer should be able to combine the two statements (this should be happening in O1. Pls check) arr[i] = a + i sum += arr[i] to sum += a + i Not sure, why are you using the array there. - Suyog On 4 May 2015 23:11, "Michael Zolotukhin" <mzolotukhin at apple.com> wrote: > Hi Yaduveer, > > Vectorizer probably fails because it

Thanks Duncan It was really helpful. Regards Abdul On Fri, Jun 8, 2012 at 7:23 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > >> If I compile the program using the following command line i.e. >> >> $ clang -O3 -lm *.c > > > this may be doing link time optimization. > > >> >> then >> >> $ time ./a.out >>

Awesome, thanks! Now I have another question. I have a matrix multiplication code. This is my code: #include <stdio.h> #include <stdlib.h> #define n 4 int main(int argc, char *argv[]) { int i, j, k; int A[n][n], B[n][n], C[n][n]; for(i=0;i<n;i++){ for(j=0;j<n;j++){ A[i][j] = 1; B[i][j] = 2; C[i][j] = 0; } }

Hi, is the comb.ll used here: > $ time lli ./comb.ll > > then the runtime is > > real 0m2.671s > user 0m2.640s > sys 0m0.020s > > But, if I convert this same file comb,ll in to native binary the same as the comb.ll used here: > $ clang comb.ll ? Ciao, Duncan. > > and execute it, then the runtime increases alot > > $ time ./a.out > > real

On Mon, Feb 10, 2014 at 02:53:00PM +0900, Alexandre Courbot wrote: [...] > diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c [...] > +resource_size_t > +nv_device_resource_start(struct nouveau_device *device, unsigned int bar) > +{ > + if (nv_device_is_pci(device)) { > + return pci_resource_start(device->pdev,

Hi all, I would like to know which optimization passes are performed at -O2 by opt. So I used following command: llvm-as < /dev/null | opt -O2 -std-compile-opts -disable-output -debug-pass=Arguments I've got following output for LLVM opt 2.9: Pass Arguments: -no-aa -tbaa -basicaa -simplifycfg -domtree -scalarrepl -early-cse Pass Arguments: -targetlibinfo -no-aa -tbaa -basicaa

Try -mllvm -disable-unroll-scev if you're curious. There can be some luck involved. If you have the bitcode for the important function, I may be able to convert it into a test case to avoid regressing. I usually grab the unoptimized bitcode as follows: -emit-llvm -mllvm -disable-llvm-optzns -o module.bc -Andy On Sep 6, 2011, at 12:03 PM, Owen Anderson wrote: > Seems very likely to be

Hi, > Yes, they both are exactly the same. then I don't know what is going on. I suggest you send a copy of comb.ll to the list so that we can see for ourselves. Ciao, Duncan. > > Regards > > Shahzad > > On Tue, Jun 12, 2012 at 9:38 AM, Duncan Sands<baldrick at free.fr> wrote: >> Hi, is the comb.ll used here: >> >> >>> $ time lli

We can let compiler driver pass the right options to preprocessor after processing -Mxy options, right now its bypassing the gcc driver and handing them straight to cpp This also helps in other compilers processing these options correctly for their preprocessors consumption Signed-off-by: Khem Raj <raj.khem at gmail.com> --- mk/syslinux.mk | 4 ++-- 1 file changed, 2 insertions(+), 2