similar to: [LLVMdev] MIPS & GP register

On Aug 17, 2012, at 2:36 PM, Akira Hatanaka wrote: > (forwarding to llvm-dev) > > ---------- Forwarded message ---------- > From: Akira Hatanaka <ahatanak at gmail.com> > Date: Fri, Aug 17, 2012 at 2:35 PM > Subject: Re: [LLVMdev] MIPS & GP register > To: Carl Norum <carl at lytro.com> > > > Will something like this fix the problem? > > if

Hi LLVM MIPS people, I've been trying to keep track of the MIPS backend in order to eventually switch to clang/llvm from GCC for building our camera software. We've been using a build at revision 156432 for some time with no problems. I synced up to TOT clang/llvm today (revision 162004) to see if any optimizations had been improved, etc. The build I made with it started crashing

On Aug 15, 2012, at 11:56 PM, Eli Friedman wrote: > On Wed, Aug 15, 2012 at 10:17 PM, Carl Norum <carl at lytro.com> wrote: >>> -march=mips32r2 >>> -mtune=4kem >>> -msoft-float >>> -EL >>> >>> -Xclang -triple -Xclang mipsel-sde-elf >>> -Xclang -mrelocation-model -Xclang static >>> >>>

On Thu, Aug 16, 2012 at 10:37 AM, Carl Norum <carl at lytro.com> wrote: > > On Aug 15, 2012, at 11:56 PM, Eli Friedman wrote: > >> On Wed, Aug 15, 2012 at 10:17 PM, Carl Norum <carl at lytro.com> wrote: >>>> -march=mips32r2 >>>> -mtune=4kem >>>> -msoft-float >>>> -EL >>>> >>>> -Xclang

On Wed, Aug 15, 2012 at 10:17 PM, Carl Norum <carl at lytro.com> wrote: >> -march=mips32r2 >> -mtune=4kem >> -msoft-float >> -EL >> >> -Xclang -triple -Xclang mipsel-sde-elf >> -Xclang -mrelocation-model -Xclang static >> >> -Xclang -mllvm -Xclang -mips-ssection-threshold=0 >> -Xclang -mllvm -Xclang

On Jun 4, 2013, at 4:42 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> wrote: > I was suggesting to add it to the function, like > volatile void func(..); > Theoretically, this would tell the compiler not to omit seemingly superfluous calls to func. 'volatile' can't apply to a function, so I'm not sure what you mean. In your example, 'volatile' modifies

Hi Carl, I don't know much about the specifics of any given optimisation, but if you do something like the following, you can at least see which optimisation pass is responsible. At the very least perhaps that can point to the next place to investigate. (also interesting to note Apple's shipped clang doesn't exhibit this behaviour, I had to use my own recent svn tree) $ clang -arch

On Jun 4, 2013, at 5:20 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> wrote: > I tried the "extern" specifier, which (I guess) you should use if the definition isn't in the file; and it worked with -O3. That 'extern' doesn't do anything - it's implicit. Did you try without it and get different results? In my test here with the Mac OS X dev tools

On Jun 5, 2013, at 7:50 AM, John Regehr <regehr at cs.utah.edu> wrote: >> The optimizer can therefore conclude that if this program has well-defined behavior, then x can never point to the null pointer constant (since the null pointer constant is not part of any array object). As a result, the "if (!x)" branch would never trigger, and is dead code. > > This is

On Aug 16, 2012, at 10:58 AM, Eli Friedman wrote: > That's weird... you're probably triggering some sort of bad case in > the driver logic which tries to call gcc to assemble and link on > targets where we don't know what to do. That logic is generally a bit > shaky to begin with. It sounds like that means "time to file a bug". =) Which product should I file

On 6/4/2013 7:31 PM, David Mirabito wrote: > Hi Carl, > > I don't know much about the specifics of any given optimisation, but if you do something like the following, you can at least see which optimisation pass is responsible. > At the very least perhaps that can point to the next place to investigate. (also interesting to note Apple's shipped clang doesn't exhibit this

I updated our project recently to use a newer version of clang (we're at r127188 now). That version made our modified ccc-analyze script stop working, so updated that from TOT clang as well. I noticed in the new script a new environment variable check "CCC_UBI" that uses Ubigraph to visualize something... but what? I tried making a simple project with a few kinds of static

Hello, I am getting the following error while trying to build a benchmark with a custom function pass: clang -Xclang -fopenmp=libomp -Xclang -load -Xclang my_lib.so file.c error: unknown argument: '-fopenmp=libomp' If I use this instead: clang -Xclang -fopenmp=libomp -Xclang -load -Xclang my_lib.so file.c I get the error: fatal error: 'omp.h' file not found I am not

Hello, I m trying to test individual O3 optimizations/ replicating O3 behavior on IR. I took unoptimized IR (O0), used disable-o0-optnone via (*clang -O0 -Xclang -disable-O0-optnone*). I read somewhere about *clang -O1 -Xclang -disable-O0-optnone,* so I also tested on this initial IR. I have observed by using individual optimizations, the performance (i.e time) is better when the base/initial

Hi All, We trying to use clang+llvm to generate the gcc coverage format as clang version 3.6.0 $clang --coverage -Xclang -coverage-cfg-checksum -Xclang -coverage-no-function-names-in-data -Xclang -coverage-version='407*' test.c $a.out $llvm-cov gcov test.gcda Unexpected version: *704. Invalid .gcno File! Debugging the above cause ,But any hints from experts here ,will help a lot

Thanks a lot Justin, I will remove the toolkit header. Just one last question..(maybe ;) ) If I do away with toolkit headers it says unknown type name '__device__'. Does this function qualifier have an alternative ? or I can just do away with ? -- View this message in context: http://llvm.1065342.n5.nabble.com/UNREACHABLE-executed-error-while-trying-to-generate-PTX-tp56026p56093.html

@Craig and @Michael After installing clang-5.0 (download from http://releases.llvm.org, does not have Flang build's slowdown mention above), 1. clang++ -O0 -Xclang -disable-O0-optnone -Xclang -disable-llvm-passes -c -emit-llvm -o a.bc LULESH.cc; opt -O3 a.bc -o b.bc; llc -O3 -filetype=obj b.bc -o b.o ; clang++ b.o -o b.out; ./b.out 20 runtime: 2.354069e+01 2. clang++ -O1 -Xclang

Well, I tried the command line given by you and I get the following error clang++ nbody.kernel.cu -Xclang -fcuda-is-device -I/home/upitamba/llvm-3.2.src/tools/clang/test/SemaCUDA/ -Xclang -triple -Xclang nvptx64 -Xclang -target-cpu -Xclang sm_10 -S fatal error: error in backend: Cannot select: 0x334a870: v4f32 = NVPTXISD::MoveParam 0x334a770 [ORD=1] [ID=22] 0x334a770: v4f32 =

Hello Tobi, Thank you for the quick reply. I updated my complete build suite with your script (http://polly.grosser.es/polly.sh). The make-test fails with some errors, the rest went smoothly; -- Exit Code: 1 Command Output (stderr): -- LLVM ERROR: Could not resolve external global address: stdout -- ******************** Testing Time: 10.01s ******************** Failing Tests (3): Polly ::

Thanks a lot, it is clear to me now. BTW, for Clang's slowdown, I submit an issue here: https://github.com/flang-compiler/flang/issues/356 I have no idea about the root cause. Maybe due to debug symbols. But, I already use -DCMAKE_BUILD_TYPE=Release. Anyway, I believe there is a bug somewhere. On Sat, Jan 6, 2018 at 3:43 PM, Craig Topper <craig.topper at gmail.com> wrote: >