similar to: [LLVMdev] Variables and/or identifiers?

Ok, I just tried the patch with some modifications (added msvc target and used WIN32 instead of __MINGW32__ for preprocessor) and everything worked beautifully. Thanks for the help! On Mon, 7 Mar 2005 20:45:40 -0500, Vyacheslav Akhmechet <coffeemug at gmail.com> wrote: > Reid, > > This patch won't work for me. I compile llvm toolset with MSVC Express > (hence __MINGW32__

Reid, This patch won't work for me. I compile llvm toolset with MSVC Express (hence __MINGW32__ won't be defined for me at compile time). I only try to feed the generated assembly into gcc (pretty much gnu assembler, I suppose). I don't use mingw tools at the earlier stage. However it's obvious for me how to modify the code now (just add MSVC at that line), thanks! I'll try it

Vyacheslav, I've tracked down the change and I have a fix for you to test. The attached patch should be applied to the CVS head (version 1.132) of X86AsmPrinter.cpp in llvm/lib/Target/X86. The patch just includes MINGW targets in the same set of choices that it makes for Cygwin. Could you please try the patch and let me know if it solves your problem? If it does, I'll commit the patch.

I successfully compiled CVS HEAD yesterday on my win32 machine using Visual C++ Express (2005). I also have Mingw tools installed. I wrote a simple hello world application and generated native assembly code using llvm. When I tried to feed the code into GCC, it rejected it with "junk at the end of line" error messages. Shouldn't GCC be able to assemble this code? I realize win32 port

what's the semantics for setCC if one of the operands is NULL pointer? %ptr=alloc int seteq int*, %pt, NULL what's the result for the second instruction? How about setne, setlt, setgt, setle, and setge? Thanks! Jianzhong

> a) Make all functions the same type. For example, make them all return > void, take a vector of parameters as the first argument, and a vector > for return values as the second argument. This is something I was considering. I guess I'll end up going with this option. > I don't see how this is a specific challenge with LLVM. It seems to me > that this is a challenge that

I recently ran into the following problem. I'm prototyping a compiler for a dynamically typed language in which functions are first class objects. Assuming I have something like this: if(rand() > 5) i = define(x, y, z) { return x + y + z; } else i = define(x, y) { return x + y; } At this point I cannot know the type of 'i' at compile time. At runtime 'i' is a

Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. Reid. On Mon, 2005-03-07 at 16:39, Vyacheslav Akhmechet wrote: > Ok, I got home so I have more details. Here's the

Evan, The problem is that I do not know the type of a target function at compile time. If you consider my code example, I don't know the type of 'i' until runtime (in fact, I can't even know a possible range of types 'i' may assume). Thanks, - Slava. On 4/21/05, Evan Jones <ejones at uwaterloo.ca> wrote: > On Thu, 2005-21-04 at 09:31 -0400, Vyacheslav Akhmechet

Ok, I got home so I have more details. Here's the sample C program: ----------------- C program --------------- #include <stdio.h> int main() { printf("hello world\n"); return 0; } ------------- end C program ------------- This is compiled using llvm online demo into the following llvm code (target removed): ----------------- LLVM code -------------- deplibs

if I write: int z, x; ... z = (x >= k); -- where k is a constant The compiler always wants to translate this into: z = (x > (k-1)); In general this can often lead to better code (and it does for Mips 16 for sure), except at the boundary condition where k==-32768 Then it creates the literal -32769 which cannot be placed in a simple immediate field. That creates a lot of extra code for

On Mon, 7 Mar 2005, Vyacheslav Akhmechet wrote: > I successfully compiled CVS HEAD yesterday on my win32 machine using > Visual C++ Express (2005). I also have Mingw tools installed. I wrote > a simple hello world application and generated native assembly code > using llvm. When I tried to feed the code into GCC, it rejected it > with "junk at the end of line" error

On Thu, 2005-21-04 at 11:34 -0400, Vyacheslav Akhmechet wrote: > I disagree. If I could push a bunch of arguments on a stack (or > specify a list of arguments, etc.) and just use a "call" instruction > with a pointer to a memory address I wouldn't run into this problem. > This is a specific challenge with LLVM because it is strictly typed. Ah! Right. You can't

Before I file a bug, I thought I'd check to make sure something hasn't changed. Stacker used to work in 1.2, now it fails on six tests. All six tests pertain to use of the SetLT, SetGT, SetLE, and SetGE SetCondInst. In my test programs they all fail, regardless of the values. The *only* thing I've done to Stacker is to change the base type involved in the comparison from int to long.

On Thu, 2005-21-04 at 09:31 -0400, Vyacheslav Akhmechet wrote: > At this point I cannot know the type of 'i' at compile time. At > runtime 'i' is a structure that contains a type and a function > pointer. What I can't figure out is how to cast my llvm function > pointer to an appropriate function type. I cannot know until runtime > what the type will be.

> I'm confused. My understanding is that Visual C++ Express does not > include Visual Studio, which is required to build LLVM. Well, Visual C++ Express is a cut down version of Visual Studio. I'm not sure about exact differences between editions but Visual C++ Express does read the .sln files and comes with an excellent C++ compiler. I didn't encounter any problems building llvm

LLVM, What is the status of the InductionVariable "semi-pass"? I have tested it out on spec benchmarks, and while it does correctly identify some of the variables, it fails to recognize most. Typically the following scenario arises a_loop: ... %tmp.19 = load int* %bsLive %tmp.20 = add int %tmp.19, -8 store int %tmp.20, int* %bsLive %tmp.5 = setgt int %tmp.20, 0 br bool %tmp.5, label

Hello, is there any documentation for LLVM codebase other than produced by doxygen? The reason I'm asking is that doxygen docs are (1) not very complete at the moment, as lot of classes don't even have a description (2) is generally not the best way to get high-level view of a big codebase. As an example, consider this code: %tmp.1 = setgt int %i, 0 br bool %tmp.1, label

This is from 'early JIT tests' thread on comp.lang.misc. Given :- int ltst(int x) { int i, j; j=0; for(i=0; i<x; i++)j++; return(j); } This is from the online LLVM compiler. AND It does not seem to optimize it down ! ; ModuleID = '/tmp/webcompile/_24843_0.bc' target datalayout = "e-p:32:32" target endian = little target pointersize = 32 target triple =

> Did you actually try the previous patch? If you compiled llvm-gcc with > mingw, it should work, regardless of the compiler you use to compile > the LLVM X86 backend with. I didn't build llvm-gcc. I just used the front end provided by the online demo on LLVM's webpage.