search for: platformindependent

Thanx for a prompt reply. I will definitely try llvm 2.8 as per your suggestion. However Step 1 and Step 2 are working for me in case of a simple hello world program on arm processor . Similarly I am able to run a GTK application on arm. However while running wxGTKwidget app it crashes while allocation of memory. As I mentioned earlier, If I explicitly allocate memory using new operation then

Hello everybody, I'm currently developing my own small operating system as a hobby project in my free time. Until now, I'm using gcc and the binutils to compile my C++ code. I want to try something new and try to use llvm with clang as a C(++) frontend as a compiler. Unfortunately I couldn't find any information about how I can use clang and llvm in a freestanding environment without

On Apr 7, 2010, at 5:07 PM, Andreas Galauner wrote: > > shouldn't be necessary with llvm since I can just translate the bitcode > to any native architecture http://llvm.org/docs/FAQ.html#platformindependent Dan

...memory using new > operation then everything works fine. Please let me know why do we actually > fail without using new, that to a arbitrary pointer which is never used in > the program. x86 and ARM have different ABIs, so you was just lucky. You can read e.g. http://llvm.org/docs/FAQ.html#platformindependent for more information. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...LLVM IR is portable, but it uses ILP32 No, it doesn't use this. > It seems it already assigned their sizes mapping with types. > How can it be portable? Isn't it been written there? Everything depends on how you generated the IR. You might find this link http://llvm.org/docs/FAQ.html#platformindependent useful. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...LP32 > No, it doesn't use this. > > > It seems it already assigned their sizes mapping with types. > > How can it be portable? Isn't it been written there? > Everything depends on how you generated the IR. > You might find this link > http://llvm.org/docs/FAQ.html#platformindependent useful. > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University > -- Best regards, Wen-Han (Nowar) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/...

I thought the LLVM IR is target independent and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. -Timo -----Ursprüngliche Nachricht----- Von: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

Dear all, I cannot find the answer of this question. We all know LLVM IR is portable, but it uses ILP32 and record the target layout within the IR. target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64 :64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-linux-gnu" It seems it already assigned

...but is otherwise target independent. This does *not* mean that you can convert C to LLVM IR in a target independent way. C code may contain "#ifdef __ppc__". Now what? Or how about "switch (x) { case sizeof(int): ... }". This question is a FAQ: http://llvm.org/docs/FAQ.html#platformindependent LLVM IR is portable in the sense that it will run the same on any platform. C is portable in the sense that you can detect things about the platform so you may correct for them. It turns out that these are two fundamentally incompatible paradigms. Some LLVM optimizations take advantage of the...

...that I had to be aware of when updating Icedtea to support LLVM 2.8. > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > Hi The platformindependent OpenJDK/IcedTea Shark JIT have been updated to support LLVM 2.8. Here are the icedtea externalproj doc_section for inclusion in the release notes : -Xerxes *<!--=========================================================================-->* *<div class=**"doc_subsection"**>* *...

...ions so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. > > I've been looking forward to the day that LLVM can be used for cross-architecture development, myself. FYI, http://llvm.org/docs/FAQ.html#platformindependent applies to clang just as much as llvm-gcc. Dan

...le? For example, the sizeof of a C struct of one int and one char > is resolved into 8 and not 5, but for some platforms out there 5 might be > the correct answer. Will the "target datalayout" information in the IR file > affect this in any way? See http://llvm.org/docs/FAQ.html#platformindependent . If you're dealing with C code, it isn't too hard to add a new target to clang; send an email to cfe-dev if you need help with that. The "target datalayout" information is purely a hint to the optimizers. > 2. What is that "target triple" as appears in the IR code...

Hi all, A few different though somewhat related questions here. I'm really grateful for your answers! 1. From a previous question I know that sizeof's are resolved into literals early in the front-end before IR is even emitted. It seems that they are resolved into whatever value is correct for the host machine. But if one wishes to then take the IR and emit assembly code for some other

Hi All, I've finished the first draft of the 2.8 release notes: http://llvm.org/docs/ReleaseNotes.html Please feel free to commit improvements and enhancements. There are "a lot" of changes that went into 2.8, but I think I've scraped most of them out of the commits. However, it is also highly likely that I missed something, so if I missed your favorite feature, please speak

Stripf, Timo wrote: > I thought the LLVM IR is target independent and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. > > I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. > > -Timo LLVM IR is very target dependent. The IR knows about things

Hi all! Is it possible to use LLVM bitcode format for storing cross-platform plugins (for example, sound synths)? Can newest LLVM understand bitcode from previous versions? Thanks! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100227/d1bab909/attachment.html>

If your project works with LLVM 2.7 and you want it included in the release notes, please email me a blurb to include ASAP. -Chris

...checked for x86 bytecode on ARM :) > This would > mean that we cannot have platform independent bytecodes as found in case of > java. We would be grateful to you for any comment on this. That's correct. C/C++ are not target neutral languages. You can read http://llvm.org/docs/FAQ.html#platformindependent for some more info. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 23/02/11 19:26, Chris Lattner wrote: [...] > This request is completely orthogonal to the proposal. If you generate target independent LLVM IR, you don't have to put a triple into the IR. This isn't going to change. Unfortunately clang doesn't appear to be aware of this. It's forcing me to specify a triple (or at least, I haven't discovered a way of generating

I have some broad newbie questions about LLVM and its language front-ends with regard to cross targeting: I assume LLVM IR and bitcode are machine independent, yet bitcode files encode an arch triple. Why? Is it just a hint for subsequent lowering phases, or it it a recommended target? Does IR/bitcode produced by a front-end configured for ARM differ from bitcode for, say PowerPC or x86?