similar to: [LLVMdev] PATCH allow for promoting any size struct arguments

Hi, Until recently I've been building LLVM with SHARED_LIBRARY=1. However, sith current svn, build now fails with unresolved symbols building opt. I've done a clean checkout, configure and make so it's not down to any local changes I've made. I'm building with: ./configure --enable-assertions \ --enable-expensive-checks=no \ --enable-pic \ --enable-targets=host-only \

I suspect my change adding --enable-shared broke you, since that configure option didn't exist before last week (r97119). SHARED_LIBRARY is not one of the variables you're supposed to be able to set on make's command line (http://llvm.org/docs/MakefileGuide.html#variables). What are you using it for? What happens if you remove it? On Tue, Mar 2, 2010 at 1:35 PM, James Williams

Hi all, I've been implementing some stuff that uses the new structs-as-firstclass values code. Apart from some implementation problems, I'm spotting a few structural problems that seem non-trivial to fix. In particular, now that structs are a first class values, the old way or returning multiple values is a bit confusing. The old way had a variable number of arguments to the return

And how about this one so as not to include a C specific header in llvm-backend (!!!) and not to have llvm-backend use a C specific flag (flag_no_builtin)? Index: gcc-4.2.llvm/gcc/c-opts.c =================================================================== --- gcc-4.2.llvm.orig/gcc/c-opts.c 2008-07-30 21:25:28.000000000 +0200 +++ gcc-4.2.llvm/gcc/c-opts.c 2008-07-30 21:26:17.000000000 +0200 @@

Hi All, in the last few days I've been working on a fix for PR2498. Currently ArgumentPromotion is a bit overzealous when promoting arguments: If any load of a pointer argument happens in the entry block (even a partial load for a struct pointer), it assumes that all loads in the function can be promoted to the caller (and thus executed uncondtionally). This is clearly wrong, as PR2498

Hi Dan, > Yes, the intention is that getresult will be removed once first-class > aggregates are a ready replacement. This won't leave LLVM missing the > concept of returning multiple values; a struct can be thought of as > a container for multiple values. I'm not saying we don't have some way of modeling multiple return values, I'm sayin the explicit concept

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some

Hi, I have to recognize that i don't fully understand the aggregate function, but i think it should help me with what i want to do. xveg is a data.frame with location, species, and total for the species. Each location is repeated, once for every species present at that location. For each location i want to find out which species has the maximum total ... so i've tried different ways to

> To clarify, we're trying to provide this invariant on the "ref" graph or > on the graph with direct calls only? I think the invariant need only apply > to the former > More clarification needed :) What do you mean by 'invariant need only apply to the former'? > if we're relying on this for correctness (i.e. an analysis must visit all > callees

In llvm-backend.cpp I see: if (optimize > 1) { if (flag_inline_trees > 1) // respect -fno-inline-functions PM->add(createFunctionInliningPass()); // Inline small functions if (flag_unit_at_a_time && !lang_hooks.flag_no_builtin()) PM->add(createSimplifyLibCallsPass()); // Library Call Optimizations if (optimize > 2)

Hi Dan, > The requirement to update all callers' call instructions when a callee > gets a new return value is also present in the current MRV-mechanism > with getresult. It's not been a problem we've worried about so far. I didn't mean you can get away without updating your calllers, I'm just saying it could be a bit easier. > Can you give some background about

On May 30, 2008, at 9:11 AM, Matthijs Kooijman wrote: > Hi all, > > I've been implementing some stuff that uses the new structs-as- > firstclass > values code. Apart from some implementation problems, I'm spotting a > few > structural problems that seem non-trivial to fix. Hi, thanks for your interest! > Furthermore, as far as I've understood, the

Hi, Thanks for getting back to me. I don't actually need opt dynamically linked but I do want shared libraries. If run make without "SHARED_LIBRARY=1" I don't appear to get any shared libraries built or installed. Is LLVM built as shared libraries supported? If so what's the correct build procedure? -- James On 2 March 2010 21:51, Jeffrey Yasskin <jyasskin at

Hi all, I was looking at the StructRetPromotion pass this morning and noticed it doesn't look at a function's linkage at all. Since it changes the signature of the function, I would say it should only change internal functions, like ArgumentPromotion does for example. Is there some implicit check I'm missing, or should an explicit check really be added? Gr. Matthijs --------------

It was found when running fio sequential write test with a XFS ramdisk on a VM running on a 2-socket x86-64 system, the %CPU times as reported by perf were as follows: 69.75% 0.59% fio [k] down_write 69.15% 0.01% fio [k] call_rwsem_down_write_failed 67.12% 1.12% fio [k] rwsem_down_write_failed 63.48% 52.77% fio [k] osq_lock 9.46% 7.88% fio [k]

It was found when running fio sequential write test with a XFS ramdisk on a VM running on a 2-socket x86-64 system, the %CPU times as reported by perf were as follows: 69.75% 0.59% fio [k] down_write 69.15% 0.01% fio [k] call_rwsem_down_write_failed 67.12% 1.12% fio [k] rwsem_down_write_failed 63.48% 52.77% fio [k] osq_lock 9.46% 7.88% fio [k]

On Jul 30, 2008, at 11:39 AM, Duncan Sands wrote: > On Wednesday 30 July 2008 18:13:27 Duncan Sands wrote: >> On x86-64 linux, in stage 2, I get: >> >> c++ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- >> prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno- >> variadic-macros -Wno-overlength-strings -Wold-style-definition - >>

Hi All, I have installed llvm-gcc4 patch to enable various llvm optimizations at -O1/-O2/-O3. This means instead of $ llvm-gcc4 --emit-llvm foo.c -o foo.bc $ opt foo.bc -o foo_optimized.bc $ llc foo_optimized.bc -o foo.o One can directly use $ llvm-gcc4 -O2 foo.c -o foo.o to get optimized foo.o - Devang + + if (optimize > 0) { + + +

Done. -bw On Jul 30, 2008, at 12:35 PM, Duncan Sands wrote: > And how about this one so as not to include a C specific > header in llvm-backend (!!!) and not to have llvm-backend > use a C specific flag (flag_no_builtin)? > > Index: gcc-4.2.llvm/gcc/c-opts.c > =================================================================== > --- gcc-4.2.llvm.orig/gcc/c-opts.c 2008-07-30

After LLVM rev 84987, the RaiseAllocations pass no longer exists. llvm-gcc needs to be patched: Index: gcc/llvm-linker-hack.cpp =================================================================== --- gcc/llvm-linker-hack.cpp (revision 84984) +++ gcc/llvm-linker-hack.cpp (working copy) @@ -80,7 +80,6 @@ llvm::createJumpThreadingPass(); llvm::createFunctionInliningPass();