similar to: [LLVMdev] Bytecode Change: Compaction Tables gone.

On Mar 22, 2006, at 11:22 PM, Reid Spencer wrote: > In looking at tools, we should also look at the example programs > and the > projects such as Stacker. For example, it would be nice to have a > virtual component that includes the libraries necessary for an LLVM > front end translator (source -> llvm bytecode). It would also be nice > to have a virtual component that

On Thu, 2006-03-23 at 00:58 -0500, Eric Kidd wrote: > On Mar 22, 2006, at 11:22 PM, Reid Spencer wrote: > > LLVM back end target library (LLVM IR -> machine code). > > What would you include in each set? I dunno. You want me to actually think about this stuff? :) I'd have to derive the actual set of required libraries, but I'm lacking motivation for that task right

For everyone understand which code must be emitted to implement TLS, I will paste the code generated by gcc for a simple function: __thread int a = 1; int f(){ return a; } gcc teste.c -o teste.s -S -O2 (arm-linux-gnueabi): .global a .section .tdata,"awT",%progbits <== special section for tls symbols .align 2 .type a, %object

All, Our plan in 2.0 for backwards compatibility with llvm-1.9 is to provide a translator for upgrading from 1.9 to 2.0 llvm assembly. The tool will be named llvm-upgrade and used something like this: llvm-1.9/bin/llvm-dis < 1.9.bc | llvm-2.0/bin/llvm-upgrade | llvm-2.0/bin/llvm-as -o 2.0.bc The 2.0 assembly and bytecode are going to be significantly different and this approach offers us a

Hi Lauro, On Wed, 2007-04-11 at 15:15 -0300, Lauro Ramos Venancio wrote: > For everyone understand which code must be emitted to implement TLS, I > will paste the code generated by gcc for a simple function: ... snip ... This proposal sounds really good to me. I only have a couple comments. We have a "section" keyword already developed in LLVM assembly. Perhaps instead of

At 09:37 PM 8/23/2004, you wrote: >On Mon, 2004-08-23 at 19:46, Robert Mykland wrote: > > At 06:43 PM 8/20/2004, Chris Lattner wrote: > > >I don't understand what you're getting at here. You can change char to > > >default to unsigned right now with llvm-gcc -funsigned-char. I don't > > >understand how that would change anything to be more useful

On Mon, 2004-08-23 at 19:46, Robert Mykland wrote: > At 06:43 PM 8/20/2004, Chris Lattner wrote: > >I don't understand what you're getting at here. You can change char to > >default to unsigned right now with llvm-gcc -funsigned-char. I don't > >understand how that would change anything to be more useful though. > > Well, in the old days, char strings were

On Thu, 8 Jan 2004, Grant Gould wrote: Dear Mr. Gould, > Is there any documentation of the llvm bytecode format? I looked > around the website but didn't see any; did I miss some obvious > document? At this time, we do not have any documentation on the bytcode format. I believe one LLVM user was working on such a document at one time, but if so, it is not complete. One option

On Fri, 2004-08-20 at 17:39, Robert Mykland wrote: > No, you're not getting the point. The bytecode is bloated by pointers to > all types. Every time a type is defined pretty much a pointer is defined > with it already, and since the pointer type is not implied by the > definition of the literal, we waste two or more bytes whenever we define a > type. I'm advocating

On Fri, Jun 26, 2015 at 12:58 PM, Gioh Kim <gioh.kim at lge.com> wrote: > Compaction calls interfaces of driver page migration > instead of calling balloon migration directly. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 1 + > mm/compaction.c | 9 +++++---- > mm/migrate.c | 21

On Fri, Jun 26, 2015 at 12:58 PM, Gioh Kim <gioh.kim at lge.com> wrote: > Compaction calls interfaces of driver page migration > instead of calling balloon migration directly. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 1 + > mm/compaction.c | 9 +++++---- > mm/migrate.c | 21

Hi Minchan, [auto build test ERROR on v4.5-rc7] [cannot apply to next-20160310] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160311-153649 config: x86_64-nfsroot (attached as .config) reproduce: # save the attached .config to linux build

Hi Minchan, [auto build test ERROR on v4.5-rc7] [cannot apply to next-20160310] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160311-153649 config: x86_64-nfsroot (attached as .config) reproduce: # save the attached .config to linux build

To ease portability headaches, I'd like to support several virtual "components" in llvm-config. Possibilities include: all: Include all LLVM libraries. backend: Include either a working native backend or cbackend. engine: Include a working subclass of ExecutionEngine, either the JIT or interpreter. You could, for example, get a typical set of JIT-related libs using:

At 02:05 PM 8/20/2004, you wrote: >Robert Mykland wrote: >>Dear Chris and Reid: > >Hi Robert. > >>Some other random ideas I've had as I've been sifting through the new >>bytecode format. Please let me know what you think. >>1) ANSI C allows for char to default to unsigned char. This is I guess >>not how it normally is in GCC. If char defaulted

I'm inlining a bunch of C++ code, and I'm ending up with a bunch of basic blocks like this: filter441.i: ; preds = %unwind432.i call void @_ZSt9terminatev( ) unreachable filter453.i: ; preds = %unwind444.i call void @_ZSt9terminatev( ) unreachable It seems like I should be safe to merge these, but I can't find a pass to do so. Going over the open projects page it looks

The only thing that comes to me off the top of my head is to look at the various LLVM tools and applications and see if there are common sets of libraries used by the tools. Ideally we'd want to "llvm-config --libs {toolname}" for each tool where {toolname} is replaced by the virtual component corresponding to the tool. That might be overkill, but if there are multiple tools that

> On May 3, 2019, at 6:25 PM, Nadav Amit <namit at vmware.com> wrote: > >> On Apr 25, 2019, at 4:54 AM, Nadav Amit <namit at vmware.com> wrote: >> >> VMware balloon enhancements: adding support for memory compaction, >> memory shrinker (to prevent OOM) and splitting of refused pages to >> prevent recurring inflations. >> >> Patches

> On May 3, 2019, at 6:25 PM, Nadav Amit <namit at vmware.com> wrote: > >> On Apr 25, 2019, at 4:54 AM, Nadav Amit <namit at vmware.com> wrote: >> >> VMware balloon enhancements: adding support for memory compaction, >> memory shrinker (to prevent OOM) and splitting of refused pages to >> prevent recurring inflations. >> >> Patches

everyone-- I'm confused about what I'm seeing in LLVM 2.6, and I have a series of related questions. I can see how to apply attributes to function parameters and return values when defining and declaring functions, but I don't see how to do it for function type definitions. It's certainly absent from the OCaml bindings. I'm also not seeing it in the C-langauge bindings over