search for: langimpl8

...is any option I can use with X-86 version of > llvm-gcc front end to generate .bc file for sparc backend. Suppose > I have the include files. > Sure you can, but the code won't work in general. See the other thread about arch portability and also: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080929/ceefa36a/attachment.html>

...> > Anyway, I've got your point. sizeof() constant expression is > calculated > during wrong stage of compilation process. Thanks for pointing it out! Yes, not to mention stuff like: #ifdef __i386__ or: case sizeof(foo): This is addressed here: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep Note that this doesn't affect cross compilation: you just need to configure llvm-gcc as a proper cross compiler. This just means that llvm won't magically make your C code portable for you. Real portable languages don't suffer from these problems. -Chris

...nk should point: http://llvm.org/docs/ProgrammersManual.html#TypeResolve It simply goes to the top of the document, probably because something has been deleted or the document has been converted to reST. It is found on the last page of the Kaleidoscope tutorial: http://llvm.org/docs/tutorial/LangImpl8.html. -- Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131123/df76691f/attachment.html>

Hi. I successfully build llvm backend2.3 for sparc/solaris, but failed to build LLVM front end of Sparc/Solaris. I'm wondering if there is any option I can use with X-86 version of llvm-gcc front end to generate .bc file for sparc backend. Suppose I have the include files. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...tions: > > - Is the architecture dependence of LLVM IR only an artifact of llvm- > gcc producing architecture dependent results? No, it inherent to any C compiler. The preprocessor introduces target specific details and things just go downhill from there: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep If you start from a target-independent *language*, you can generate target independent LLVM IR. > - What architecture-specific features are present in the IR that > prevent running the same LLVM bitcode on different architectures? Many things are target independent, but...

Is there a simple example of how to add debug metadata to IR using the C++ API? All I really need right now is the ability to annotate an instruction with line number and file name, although describing variables will be useful later. It's not clear from reading the include files how to "put it all together". Unfortunately, the output of my compiler is getting a little large to

...ing exactly the > size > of a pointer? No. > 2) Assuming the above answer is "no", what's the best way for the > front > end to measure the size of a pointer? It doesn't help for interfacing to C, but you can do things like this: http://llvm.org/docs/tutorial/LangImpl8.html#offsetofsizeof If you want to generate a constant as a Value* in the IR. For emitting the right sized integer type, I'm afraid that your front- end needs to know the size of the integer. If you are willing to accept an ugly hack that works almost always on common targets, you can ju...

For the most part, it appears that writing a front end can be almost entirely platform-independent. For example, my front end doesn't know how big a pointer is, and for the most part doesn't care. All of the platform-specific aspects of compilation have, up to this point, been hidden behind the IR. However, where things get tricky is in calling C functions that take a size_t as a

...> > >> 2) Assuming the above answer is "no", what's the best way for the >> front >> end to measure the size of a pointer? >> > > It doesn't help for interfacing to C, but you can do things like this: > http://llvm.org/docs/tutorial/LangImpl8.html#offsetofsizeof > > If you want to generate a constant as a Value* in the IR. > > For emitting the right sized integer type, I'm afraid that your front- > end needs to know the size of the integer. > > > If you are willing to accept an ugly hack that works almost al...

On 29.09.2008, at 11:53, Jonathan S. Shapiro wrote: > Watching this thread, it occurs to me that the "V" in "LLVM" is > creating > confusion. So far as I know, LLVM is the first project to use > "virtual" > to refer to the instruction set of the intermediate form. I understand > why this labeling made sense (sort of), but it was unfortunate. The

Have I correctly inferred below, how I build IR and debug info for a function type and a function (value), in particular, how to supply the names of the formal parameters? To create a function in llvm IR and give names to its formal parameters, I must: 1. Build a LLVMTypeRef for the type of each formal and the function result. 2. Build a function type using LLVMFunctionType, from the results of

On Nov 11, 2008, at 3:51 PM, Peter Shugalev wrote: > Owen Anderson wrote: >> If you configure it as a cross-compiler for 64-bit x86 Linux and >> feed it >> the appropriate header files, it will produce the same output on any >> platform. However, that output will not be executable on most >> platforms, just on 64-bit x86 Linux. The problems go beyond pointer

Owen Anderson wrote: > What about something much simpler: memcpy'ing an array of structs > around. The number of bytes to be memcpy'd is dependent on the padding > of the struct. Anyway, I've got your point. sizeof() constant expression is calculated during wrong stage of compilation process. Thanks for pointing it out! -- Best Regards Peter Shugalev

Hi, Chris Lattner wrote: > Yes, not to mention stuff like: > > #ifdef __i386__ > > or: > case sizeof(foo): > > This is addressed here: > http://llvm.org/docs/tutorial/LangImpl8.html#targetindep > > Note that this doesn't affect cross compilation: you just need to > configure llvm-gcc as a proper cross compiler. This just means that > llvm won't magically make your C code portable for you. Real portable > languages don't suffer from thes...

Hi, going through the tutorial (http://llvm.org/docs/tutorial/LangImpl8.html) it linked to a post from 2004 (http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt) stating that LLVM does not allow explicit stack management. It also mentioned that this was a deficiency in LLVM, leading me to think that there is a possibility that things have changed s...

> If you want to use llvm-gcc as a cross compiler, you must configure it as > a cross compiler, and compile the output with the appropriate cross > toolchain. LLVM does not implicitly make your code portable, see: > http://llvm.org/docs/tutorial/LangImpl8.html#targetindep > > for example. > > -Chris Hm.. so the C backend works differently if I configure LLVM to be a cross compiler? I am using a cross-compile toolchain as a backend (feeding it the "llc -march c" output), so I'm a bit confused. I'm not looking for a targ...

...is page of the OCaml Kaleidoscope tutorial goes to the C++ version: http://llvm.org/docs/tutorial/OCamlLangImpl3.html. The link to chapter 8 in the first chapter is broken: http://llvm.org/docs/tutorial/OCamlLangImpl1.html#intro. It links to the unvavailable page http://llvm.org/docs/tutorial/OCamlLangImpl8.html. I think it should link to the C++ version at http://llvm.org/docs/tutorial/LangImpl8.html because the page isn't language dependent. Jules -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080424/2f0...

...on-text attachment was scrubbed... Name: LangImpl7.diff Type: text/x-patch Size: 8181 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071113/88e66930/attachment-0001.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: LangImpl8.diff Type: text/x-patch Size: 7479 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071113/88e66930/attachment-0002.bin>

Hi, I'm still working on this problem by first trying code without the Altivec intrinsics. I'm trying to use the cross compiler on the c code outputted by "llc -march c" and have run into this linker problem (spewed by the cross compiler): Command line : error: L0039: reference to undefined symbol .fopen64 in file /tmp/cc4tgLu5.o Command line : error: L0039: reference to

On Nov 11, 2007, at 2:41 PM, Kelly Wilson wrote: > Hey Chris: > > Here are the diffs for the next few chapters of the tutorial that I > have > edited. Nice! You are an excellent editor, I'm impressed. I committed these without any changes here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071112/055566.html Thank you for the help with this. > Please