similar to: PtrToInt in array initializer

Simple tool to parse a fits-stream from stdout. Signed-off-by: Arne Jansen <sensille@gmx.net> --- The idea of the btrfs send stream format was to generate it in a way that it is easy to receive on different platforms. Thus the proposed name FITS, for Filesystem Incremental Backup Stream. We should also build the tools to receive the stream on different platforms. As a place to collect

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

Sanjoy Das wrote: > In your > example, foo will have to treat its argument differently depending on > whether it is a GC pointer or not. In practice, this is not true of many functions that don't call other functions. Take the example of a simple "print" function that takes a void * to cast and print, type_int to determine what to cast to: why should it care about whether

Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV().

Hi, I just found out that it's not practical to mark only some pointers for GC. Consider: %a = i8 addrspace(1)* malloc(...) %b = i8* alloca(...) The issue then becomes that routine functions declared: declare i1 foo(i8 addrspace(1)*) have a choice of accepting either gc'able or non-gc'able pointers. Is there no way to have a reasonable mix of both? Ram

The following series implements libxl_domain_config_init as per the libxl API requirement that each type has an init function. The first function does this in an open coded manner and is proposed for Xen 4.2. The second function is RFC only since it moves the definition of this type into the IDL and makes the required infrastructure updates to enable this. I think this is more 4.3 material at

Here's a sketch of what I am proposing for ConstantBuilder. I'd like feedback on naming conventions, doc comments, etc. //===-- llvm/Support/ConstantBuilder.h - Builder for Constants --*- C++ -*-===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. //

Aaron Gray wrote: > I think I might have found a bug in the exection engine's 'constants > folding'. > > Basically APInt's parameters are the wrong way round. > > Line 577 for lib/ExecutionEngine/ExecutionEngine.cpp :- > > case Instruction::PtrToInt: { > GenericValue GV = getConstantValue(Op0); > uint32_t PtrWidth =

Hi, Is it correct to convert, %196 = load i32* %195, align 8 ; <i32> [#uses=1] %197 = zext i32 %196 to i64 ; <i64> [#uses=1] %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1] %199 = add i64 %198, %197 ; <i64> [#uses=1] %200 = inttoptr i64 %199 to i8* ; <i8*>

Hi, > > Is it correct to convert, > > %196 = load i32* %195, align 8 ; <i32> [#uses=1] > %197 = zext i32 %196 to i64 ; <i64> [#uses=1] > %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1] > %199 = add i64 %198, %197 ; <i64> [#uses=1] > %200 = inttoptr i64 %199 to i8*

On Wed, Feb 29, 2012 at 11:00 AM, Dillon Sharlet <dsharlet at gmail.com> wrote: > Hello, > > I am working on an application of LLVM where I would strongly prefer that > getelementptr not be lowered into pointer arithmetic by any passes other > than my own. I'm writing a ModulePass. > > I am observing a situation where I compile a C++ file with no optimization >

What kind of C or C++ code will emit a "ptrtoint" op? Also, what causes i1 to be emitted? Tia. Reed

I think I might have found a bug in the exection engine's 'constants folding'. Basically APInt's parameters are the wrong way round. Line 577 for lib/ExecutionEngine/ExecutionEngine.cpp :- case Instruction::PtrToInt: { GenericValue GV = getConstantValue(Op0); uint32_t PtrWidth = TD->getPointerSizeInBits(); GV.IntVal = APInt(PtrWidth,

Hi, all When I read the document of IR on llvm.org, I found two instructions, "ptrtoint" and load. Load, I think, is : when after allocating some bytes in memory and storing some data into it, we could use load to get the data, like this: %0 = alloca i32 store i32 5, i32* %0 %1 = load i32* %0 so, the type of %1 is i32, and the value is 5, right? And "ptrtoint" is:we cast it

This code is generated for va_arg. %6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**> [#uses=1] %7 = load i8** %6, align 8 ; <i8*> [#uses=1] %8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0 ; <%struct.__va_list_tag*> [#uses=1] %9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;

Hello, I am working on an application of LLVM where I would strongly prefer that getelementptr not be lowered into pointer arithmetic by any passes other than my own. I'm writing a ModulePass. I am observing a situation where I compile a C++ file with no optimization and I get code as I would expect that uses getelementptr. However, if I enable optimization with -O3, *some* of my

Thanks. So what about a fragment like this: (taken from fast-isel.ll in X86 ) define void @ptrtoint_i1(i8* %p, i1* %q) nounwind { %t = ptrtoint i8* %p to i1 store i1 %t, i1* %q ret void } TIA. On 09/29/2014 02:16 PM, Duncan P. N. Exon Smith wrote: >> On Sep 29, 2014, at 1:51 PM, reed kotler <rkotler at mips.com> wrote: >> >> What kind of C or C++ code will emit

On Mon, Apr 4, 2011 at 7:10 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/4/2011 6:45 PM, Eli Friedman wrote: >> >> On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> >>  wrote: >>> >>>> Hi, >>>> Is it correct to convert, >>>>   %196 = load i32* %195, align 8                

> As with many things in the C and C++ specifications, this has very > little relationship to real-world code. The biggest example I've seen > that violates this rule is the way that the FreeBSD kernel implements > per-CPU storage, but in a fairly ad-hoc analysis of existing C/C++ code > we found quite a few cases where subtraction occurred between objects. Hello David, If C

On Mon, Sep 8, 2014 at 4:22 PM, Dan Gohman <dan433584 at gmail.com> wrote: > It looks a little silly to say this in the case of the integer constant 5, > and there are some semantic gray areas around extra-VM allocation, but the > same thing happens if the add were adding a dynamic integer value, and then > it's difficult to find a way to separate that case from the constant