similar to: [LLVMdev] Duplicate assignment in LLVM?

Volodya, I think you may need to update your CFE and rebuild. I compiled the test using my local build and I didn't get the results you see below. I'm also very surprised to see this output. The first %tmp.11 should have been %tmp.1 .. not sure how it got corrupted. In any event, the attachment is obviously generated by code that runs quite differently because the virtual register names

Reid Spencer wrote: > Volodya, > > I think you may need to update your CFE and rebuild. I compiled the test > using my local build and I didn't get the results you see below. I'm > also very surprised to see this output. The first %tmp.11 should have > been %tmp.1 .. not sure how it got corrupted. In any event, the > attachment is obviously generated by code that runs

Okay, let me test with exactly your options and I'll let you know what I get. Reid. On Wed, 7 Jul 2004 19:53:15 +0400 Vladimir Prus <ghost at cs.msu.su> wrote: > Reid Spencer wrote: >> Volodya, >> >> I think you may need to update your CFE and rebuild. I compiled the test >> using my local build and I didn't get the results you see below. I'm

Okay, I've replicated your results, but I don't think there's an error here, its just not nice output from the disassembler. The first %tmp.ll is of type long. The second one is of type short. I think that's valid for LLVM. That is, the SSA form depends on both the type and name of the virtual register. In any event, llvm-as seems to compile the llvm-dis output just fine. Make

Hi LLVM-dev! I'm having problems figuring out how to do variable sized structs in LLVM (which are neccessary for PyPy's LLVM backend, on which I'm working). I'm trying to do the equivalent of struct array { long refcount; long length; long items[1]; }; in LLVM, where the items array can be arbitrarily long. I guess that the struct definition should

>> Is there a pass that will transform this: >> %cc = seteq ushort %val, 0 >> >> into this: >> %cc = cast ushort %val to bool >> >> Would instcombine be the logical place to do this? >> >> In my situation, this bool value feeds a select instruction. Because >> casting inverts the condition, the select would have to switch the

Carl, The thing you're missing is that LLVM's primitive types have well known, fixed sizes that are not target dependent. A ulong is 8 bytes. A uint is 4 bytes. A ushort is 2 bytes. Etc. and always. There are also methods in LLVM to help you deal with the size of a type in bits and bytes. In particular you might want to note the following methods: Type::isSized Type::getPrimitiveSize

Distinguished LLVM Creators, I've been looking through the bytecode representation of the type definition table and had a few questions about it. There's an enum in Types.h that defines all bytecodes that represent the primitive types and a few other necessary things: 0 = 0x00 = Void 1 = 0x01 = Bool 2 = 0x02 = UByte 3 = 0x03 = SByte 4 = 0x04 = UShort (16 bits) 5 = 0x05 =

Hello, I'm having problems with the following LLVM instruction %tmp.0.i = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ...... The first argument in function call, sbyte* getelementptr ([11 x sbyte]* %.str_1..... appears to be ConstantExpression*, and my backend does not support ConstantExpression yet. I probable can implement

Hi, Try as I might, I just cannot get Dir.create_junction to work with FFI in the ffi branch of the win32-dir project. The problem is the REPARSE_JDATA_BUFFER struct. I''m just not sure how to set those members, specifically, the PathBuffer member. The target looks good, it''s UTF-16LE encoded, but I can''t make it work, despite trying several ways of defining the struct,

Hi, I'm trying to compile and run the following code-snippet: implementation uint %fie(uint* %x) { %e = getelementptr uint* %x, int 1 ; %f = load uint* %e ret uint 3 } int %main(int %argc, sbyte** %argv) { %z = malloc uint, uint 10 %g = call uint %fie(uint* %z) ret int 0 } But the getelementptr instruction gives a segmentation fault. Have I misunderstood its use? I

Hi! Hmm, ok. I'm using the 1.2 release. Found out that it worked when using long to index getelementptr, but not when using uint, int or ulong. But then I'll try with the CVS code instead. Thank you. , Tobias On Sat, 12 Jun 2004, Reid Spencer wrote: > Hi Tobias, > > I tried your test program on the latest CVS code. Everything worked > fine. > > Can you tell me which

Hi Tobias, I tried your test program on the latest CVS code. Everything worked fine. Can you tell me which version of LLVM you're using? Reid. On Sat, 2004-06-12 at 08:26, Tobias Nurmiranta wrote: > Hi, > > I'm trying to compile and run the following code-snippet: > > implementation > > uint %fie(uint* %x) { > %e = getelementptr uint* %x, int 1 > ;

Hi all, I just checked in a series of patches that makes some substantial changes to the LLVM getelementptr instruction. In particular, in LLVM 1.2 and earlier, the getelementptr instruction required index operands for structure types to be 'ubyte' constants and index operands for sequential types to be 'long' values. This had several problems, most notably that it was

Hi Reid, On Mon, Jun 20, 2005 at 07:08 -0700, Reid Spencer wrote: > The thing you're missing is that LLVM's primitive types have well known, > fixed sizes that are not target dependent. A ulong is 8 bytes. A uint is > 4 bytes. A ushort is 2 bytes. Etc. and always. Don't aligning rules make it hard to compute the size of a whole struct from the sizes of it's members?

On Thu, 17 Jun 2004, Vladimir Prus wrote: > I'm having problems with the following LLVM instruction > > %tmp.0.i = call int (sbyte*, ...)* > %printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ...... > > The first argument in function call, > > sbyte* getelementptr ([11 x sbyte]* %.str_1..... > > appears to be ConstantExpression*, and my

Dear Chris and Reid: 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 to unsigned char several things would be possible. Single char constants that are defined would be almost always stored

Hi Chris, Congrats on getting this taken care of finally. I know its something you've wanted to do since 1.0. I have one question. How does LLVM disambiguate between a uint used for a structure and a uint used for an array? My assumption is that LLVM is aware of the type of the thing being indexed all the way through the dereference so it doesn't really matter what index type is being

When I increased COLS to the point where the loop could no longer be unrolled, the selection dag code generator generated effectively the same code as the default X86 code generator. Lots of redundant imul/movl/addl sequences. It can't clean it up either. Only unrolling all nested loops permits it to be optimized away, regardless of code generator. Jeff Cohen wrote: > I noticed

Hi, Is there a way to modify the string such as char a or char b? Could I use the way like "Replace an instruction with another Value" in Programm Manual? In fact, what I am interested in is string with visible expression, not all string, and I am trying to hide the orignal string by using simple way like XOR.. Is there a way to reorder the basic blocks? Thanks. Qiuyu C Source