similar to: [LLVMdev] problem building llvm + 4.2 frontend from svn

Hi, > ./configure --prefix=/home/regehr --enable-optimized ... > ../configure --prefix=/home/regehr --enable-languages=c,c++ \ > --enable-llvm=/home/regehr/z/llvm I think gcc from svn has checking enabled by default (which means it wants to use LLVM built with checking enabled). Try configuring llvm-gcc with --enable-checking=release or compile an unoptimized LLVM. Ciao, Duncan.

I get the output below on Ubuntu Hardy on ia32 from svn 56984. John make[2]: Entering directory `/home/regehr/llvm-gcc/build/gcc' /home/regehr/llvm-gcc/build/./gcc/xgcc -B/home/regehr/llvm-gcc/build/./gcc/ -B/home/regehr/i686-pc-linux-gnu/bin/ -B/home/regehr/i686-pc-linux-gnu/lib/ -isystem /home/regehr/i686-pc-linux-gnu/include -isystem /home/regehr/i686-pc-linux-gnu/sys-include -O2 -O2

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

See below. This is on Ubuntu Hardy on ia32. Thanks, John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.

Although the process of porting the LLVM backend to a new architecture looks pretty straightforward (and is very well documented) there's a frontend issue that I'm not clear on: How do we to tell the frontend about implementation-defined constants like integer width? In other words, when llvm-gcc does a promote-to-integer operation, this acts differently if the target architecture

On Jul 1, 2008, at 9:45 PM, John Regehr wrote: > Thanks Chris. I'll follow any ongoing discussion about this. > Unless I'm > missing something, customizable widths for integer types is > necessary to > achieve source-level compatibility with existing cross-compilers. > > It would be great to see the fronend being parameterized by integer > widths > at

On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

Hi, I'd like to see what parts of LLVM/Clang are being executed. I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on 64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head using any of Clang 3.4, Clang head, or a recent GCC. The first error that I get when building with GCC is this:

One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,

On Jan 19, 2009, at 5:34 PM, John Regehr wrote: > Since yesterday I've been getting the error below when building llvm- > gcc > on Ubuntu Hardy on x86. For some reason, several instances of > autoconf > are getting confused and failing to detect a stdlib.h. > > John > > > /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc >

My InlineCost refactoring has been noticed in this aspect; that may or may notbe the culprit here. A quick thing you can do is to compile with -ftime-report and compare the top few passes between versions. Dan On Oct 19, 2009, at 8:47 PM, John Regehr <regehr at cs.utah.edu> wrote: > As part of routine testing, I run clang and llvm-gcc a lot of times. > Something happened

Since yesterday I've been getting the error below when building llvm-gcc on Ubuntu Hardy on x86. For some reason, several instances of autoconf are getting confused and failing to detect a stdlib.h. John /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc -B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/

I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details. THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is. Thanks,

Here's an example where llvm should probably be producing smaller code, its output is 700% larger than gcc. regehr at john-home:~/volatile/tmp11$ llvm-gcc -Os -w small.c -o small ; size small text data bss dec hex filename 6324 252 8 6584 19b8 small regehr at john-home:~/volatile/tmp11$ current-gcc -Os -w small.c -o small ; size small text data

Well, it looks like almost all of the problems go away when I build using trunk instead of 3.9. So, that was scary but I'm going to forget it ever happened. >8000 test cases failed under Valgrind!! John On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote: > Hi John, > > This is probably somewhat of a stretch, but since the problem does not > happen with a Debug build,

We have a bitwidth analysis that can be downloaded. It is not in LLVM. There should be a link in the paper: http://www.cs.utah.edu/~regehr/papers/pldi075-cooprider.pdf John Regehr

I did a RelWithDebInfo + asserts build of LLVM just now and, when running "make check" under Valgrind, am seeing a lot of uses of uninitialized memory like the one below. Anyone know offhand what's likely to be the root cause? Unfortunately a Debug build doesn't give these errors. Thanks, John FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)

Please link to the graphs if that seems appropriate-- I will leave them there and hopefully also update them as new versions of LLVM come out. It would be great if these graphs can serve as an advertisement for LLVM as well as an advertisement for my work. I hope to create analogous graphs for gcc 4.x sometime, and also to stress-test the x64 ports of both compiler families. There is a

I strongly suspect pointer union and pointer int pair style classes are the source of these... But perhaps I'm wrong On Nov 26, 2014 9:29 AM, "Michael Zolotukhin" <mzolotukhin at apple.com> wrote: > John, > > That’s a great post and really interesting data, thank you! > > On Nov 25, 2014, at 9:58 AM, Reid Kleckner <rnk at google.com> wrote: > >