similar to: [LLVMdev] How could I hide the visible string?

On Tue, 2004-11-30 at 08:58, Chris Lattner wrote: > On Tue, 30 Nov 2004, Tanu Sharma wrote: > > > I have trouble using the llvm tools.Some of the errors are : > > > > $ llvm-dis prog.bc > > $ llvm-dis: Invalid Top Level Block Length! Type:1, Size:456 (Vers=0, Pos=12) > > Can you explain how you generated this bytecode file? It looks corrupted > or

Hi, > On Mon, 27 Sep 2004, Zhang Qiuyu wrote: > > > 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

On Tue, 30 Nov 2004, Tanu Sharma wrote: > I have trouble using the llvm tools.Some of the errors are : > > $ llvm-dis prog.bc > $ llvm-dis: Invalid Top Level Block Length! Type:1, Size:456 (Vers=0, Pos=12) Can you explain how you generated this bytecode file? It looks corrupted or something. Also, can you send the actual bytecode file itself? Thanks! -Chris >

hi, I want to know what is exact meaning in the following code. target endian-- %struct..TorRec-- %struct.TorRec-- implementation-- ;<sbyte>[#uses=1/0]-- how to explain them in details? Does anyone give me a guide? thanks yueqiang -------------------------------------------------------------- target endian = little target pointersize = 32 %struct..TorRec = type { int, void ()* }

I have an objective-c file, bar.m, that I try to process in the following way generating the error shown below. Any help would be appreciated. I suspect the error is in the first few lines of output. thanks, Todd > cfrontend-g++ -o bar.bc bar.m > llvm2cpp -o bar.cpp bar.bc > g++ -c bar.o bar.cpp > ld -o bar bar.o -l objc -l LLVMCore -l LLVMSupport -l LLVMSystem > ./bar Global

>Right. This looks like it's just a simple bug in llvm2cpp. >CppWriter.cpp:698 contains: > > if (CA->isString() && CA->getType()->getElementType() == >Type::SByteTy) { > Out << "Constant* " << constName << " = ConstantArray::get(\""; > printEscapedString(CA->getAsString()); > //

Thanks for replying, Yes, I think too that the bytecode file is corrupted. This is the file : -------------------------------------------------------------------------------------------------------------------------

> Ok, I am developing an intrinsic instruction and I have the codegen > working (and tested). However, some of the more complex cases of the > intrinsic are reducable to LLVM + simpler cases of the intrinsic. How > would I go about conditionally reducing the intrinsic? I could deal > with the issue in the codegen, but that gets ugly quickly. > > Andrew I suppose you could

Ok, I am developing an intrinsic instruction and I have the codegen working (and tested). However, some of the more complex cases of the intrinsic are reducable to LLVM + simpler cases of the intrinsic. How would I go about conditionally reducing the intrinsic? I could deal with the issue in the codegen, but that gets ugly quickly. Andrew -------------- next part -------------- A non-text

Robert, Thanks for the info, you've confirmed what I was trying to do, but when I compile: ----------------------- #include <stdio.h> int main(int argc, char *argv[]) { printf("yo\n"); return 0; } ----------------------- without "-c" (llvm-gcc t1.c -o t1) the dissassembled bytecode does not call __main: ----------------------- ; ModuleID =

The -c option tells llvm-gcc to build a bytecode file without linking in the LLVM runtime library. This is similar to the -c option for regular gcc, which you use to build multiple separate .o files that you're going to link into a single executable. If you want to build from a single source file, it's easiest just to compile without the -c option. If you're building from

Hello, When I compile a "hello.c" program with a printf in "main" and use llvm-gcc with a "-c" option: llvm-gcc -c t1.c -o t1.bc and then try to compile t1.bc to native using llc & gcc I get a call to "__main" which is undefined. If I don't use the "-c" option: llvm-gcc t1.c -o t1 I don't get a reference to

Well, the complexity only occurs on x86, other archs are simpler. Since this is not used much outside the c library, I can work around it in the library and be satisifed with the simple case. Oh, I suppose I should mention what I was working on. I made a syscall intrinsic with codegen for linux/x86. It seemed a missing peice in having a pure llvm compiled userland (mostly, being able to have a

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

Hello, when I'm compiling test/Programs/SingleSource/UnitTests/2003-05-26-Shorts.c I get LLVM assembler which looks like: int %main(int %argc, sbyte** %argv) { entry: call void %__main( ) %tmp.11 = call ulong %getL( ) ; <ulong> [#uses=16] %tmp.3 = cast ulong %tmp.11 to long ; <long> [#uses= %tmp.5 = cast ulong %tmp.11 to

In a code segment of my pass plugin, I try to gather AliasSets for all StoreInst, LoadInst and CallInst instructions in a function. Some behaviors of the pass puzzled me. Below is the *.ll of the test program which I run the pass on, it was get with "llvm-gcc -Wl,--disable-opt" from a rather simple *.c program. ---------------------------------- ; ModuleID = 'ptralias.bc'

Oh, I appologize that I should not have asked about __main() ---- it appears in FAQ. But the question remains that why call to __main() can alias stack location? I think the memory location pointed by data_X pointers are not visible to __main(). In comparison, calls to printf() do not have similar effect. On 5/14/06, Nai Xia <nelson.xia at gmail.com> wrote: > > In a code segment of

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

Hi Chris, I took a haste look at the "Points-to Analysis in Almost Linear Time" by Steens , your PHD thesis and SteensGaard.cpp in LLVM this afternoon. So I think: 1. Actually the basic algorithm described originally by SteensGaard does not provide MOD/REF information for functions. 2. The context insensitive part of Data Structure Analysis (LocalAnalysis) can be deemed as an

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