search for: danchr

Hi all, I've previously posted this patch on llvm-commits, but due to a lack of replies, and the fact that this patch is more something to discuss than something to apply, I'm posting this again here. While working on my own backend, I found that things got really messy real quickly, partly caused by the fact that all .cpp files must be in the same directory (lib/Target/TargetName).

...cleaner to mark the distinct objects in the LLVM intermediate representation? This would make the default case the one resulting in best code, and seems to me to follow the principle of structural equivalence of types (and values) used elsewhere. -- Dan Villiom Podlaski Christiansen, stud.scient. danchr at daimi.au.dk, danchr at gmail.com

Hello, Tatu > Is that correct? I think it's just something to be aware of. Currently we're aggressively merging globals by default. Do you think it will be better to provide special flag to control this behavior? -- WBR, Anton Korobeynikov

On Oct 17, 2008, at 7:30 AM, Anton Korobeynikov wrote: > Hello, Tatu > >> Is that correct? I think it's just something to be aware of. > Currently we're aggressively merging globals by default. Do you > think it > will be better to provide special flag to control this behavior? Please no flag. If we want to fix this problem, lets do it right. To me this

This patch eases building clang when present in the source tree. Since clang is revlocked to llvm, one usually updates them together, and builds them together. Ok? -------------- next part -------------- A non-text attachment was scrubbed... Name: clang-3.patch Type: application/octet-stream Size: 794 bytes Desc: not available URL:

...together. > > Ok? In my humble opinion, using OPTIONAL_DIRS would be better and cleaner. It may require some changes to ‘Makefile.rules’ to work as intended, though. If there's interest in such a change, I can prepare a patch? -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com

On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen wrote: > In my humble opinion, using OPTIONAL_DIRS would be better and cleaner. > It may require some changes to ‘Makefile.rules’ to work as > intended, though. If there's interest in such a change, I can prepare > a patch? Are OPTIONAL_DIRS parallel? For some reason, I was assuming not.

...tually be executed parallel with other directories, but I wouldn't consider that a problem, as Clang itself contains quite a lot of source files, libraries and directories. Parallelism within the Clang source should be Good Enough™ ;) -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com

2009/1/2 Chris Lattner <clattner at apple.com> > On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote: > Do you have a specific example of a unit test that would need these? I > really think these should stay private. > Let's take lib/Transforms/Utils/CodeExtractor.cpp . The public interface for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the high-level

...build system integrated, and plan to post a proposal of how to get it done within the next few days or so. Apart from a general overhaul of the Makefiles, I integrated Clang into much of the LLVM build system, for instance ‘llvm-config’. -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com

On Jan 19, 2009, at 1:58 PM, Chris Lattner wrote: > On Jan 19, 2009, at 10:02 AM, Mike Stump wrote: > >> There isn't a good reason to create files called .dir in the >> installation directory. This patch fixes that. > > If we don't have this line, every build with do the makedir. And? $ time mkdir -p /bin real 0m0.002s user 0m0.000s sys 0m0.002s an extra mkdir

On Jan 19, 2009, at 12:35 PM, Dan Villiom Podlaski Christiansen wrote: > On 19 Jan 2009, at 21:16, Mike Stump wrote: > >> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen >> wrote: >>> In my humble opinion, using OPTIONAL_DIRS would be better and >>> cleaner. >>> It may require some changes to ‘Makefile.rules’ to work as >>>

Hello all, I have replaced the llvm-gcc shipped with the Xcode by the latest version and I was wondering if I have missed something... (everything *seems* to work). Here's what I did: 0. Checkout LLVM (and clang) + llvm-gcc 1. Build LLVM (with clang) and install into /Developer/usr/local : # mkdir llvmobj # cd llvmobj # CC=gcc-4.2 CXX=g++-4.2 ../llvm/configure

On Oct 17, 2008, at 11:18 AM, danchr at gmail.com wrote: > On 17/10/2008, Chris Lattner <clattner at apple.com> wrote: >> Please no flag. If we want to fix this problem, lets do it right. >> To >> me this consists of some flag on GlobalVariable that says that it is >> 'mergable' or somethi...

Oscar, I be willing to donate some machine time to you. How about a 2 x 3GHz Dual Core Intel Xeon with 8GB? The question is how to get past the NAT. Email me privately if interested. Regards Mark Kromis On Nov 11, 2008, at 12:12 AM, Óscar Fuentes wrote: > Reports arrived indicating that the LLVM cmake-based build system is > lacking some OS X specific work, which seems to be the OS of

Hi, > gcc: gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) most likely the version of gcc you are using is broken. See http://llvm.org/docs/GettingStarted.html#brokengcc Ciao, Duncan.

Hi, I am just starting a new project. I found that the above script rejects Autoconf versions later than 2.59, whereas it ought to accept them, imho. I had to edit the scrip to be able to use it with Autoconf 2.61. Also, aclocal gave the following warning: /usr/share/aclocal/oaf.m4:4: warning: underquoted definition of AM_PATH_OAF /usr/share/aclocal/oaf.m4:4: run info '(automake)Extending

On Nov 12, 2009, at 11:43 AM, John Criswell wrote: > Dear LLVMers, > > I'm currently working on creating an alternate libLTO.so that will run > some whole-program analysis and transforms of mine during the final > linking of an executable. The idea is for it to link all of the > bitcode > files together, run the regular LTO passes, and then run my passes. > For

On Dec 4, 2009, at 2:49 PM, John Criswell wrote: >> If you are building llvm-gcc yourself, try, in this order: >> 1) sudo ln -s ../../Developer/usr/lib/libLTO.dylib /usr/lib/ >> libLTO.dylib >> >> 2) If you still get errors, try installing the libLTO.dylib from >> your LLVM build into /Developer/usr/lib. Make sure that if you're >> on a 64-bit

Dear LLVMers, I'm currently working on creating an alternate libLTO.so that will run some whole-program analysis and transforms of mine during the final linking of an executable. The idea is for it to link all of the bitcode files together, run the regular LTO passes, and then run my passes. For Linux, I should be able to get the Gold linker to load my libLTO.so instead of the standard