similar to: [LLVMdev] (Function) attributes documentation

Hi Matthijs, On Oct 6, 2008, at 9:23 AM, Matthijs Kooijman wrote: > Hi all, > > due to the recent changes regarding paramater/function/return type > attributes, > I think the documentation around that could use some improvement. In > particular, I see the following problems: > * The section "Functions" in the LangRef has a large textual > description >

Hi Devang, the improvements you made are good, I think the docs are a lot clearer now. I stil have a few more points, though. > > * The section "Functions" in the LangRef has a large textual description > > about how it should look, but no definition of syntax, or even a few > > examples of the syntax. This makes it very hard to read. > > This description

On Oct 7, 2008, at 3:12 AM, Matthijs Kooijman wrote: > Hi Devang, > > the improvements you made are good, I think the docs are a lot > clearer now. I > stil have a few more points, though. > >>> * The section "Functions" in the LangRef has a large textual >>> description >>> about how it should look, but no definition of syntax, or even

Hi all, I've been discussing parameter attributes and their impact on first-class struct parameters. Duncan and I came to the conclusion that the only attribute that could be applied to structs currently, is the inreg attribute. However, since there is no support anywhere for that currently (transformation passes and backends?), it might be better to disallow the inreg attribute for struct

Hi all, Last week I implemented samba a sa file server and domain controller for more than 150 computers (Win 2000 and XP). Everything is working just fine. However, computer science faculty wanted a share for each course in which students can upload their homework once done and teacher download them for correction. Yet, students can have the right to write on that share but not delete the work

On Tue, Jul 8, 2008 at 2:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Hi all, > > I've been discussing parameter attributes and their impact on first-class > struct parameters. Duncan and I came to the conclusion that the only attribute > that could be applied to structs currently, is the inreg attribute. However, > since there is no support anywhere for

On Mar 1, 2010, at 09:56, james woodyatt wrote: > On Mar 1, 2010, at 04:43, Duncan Sands wrote: >> >> Where exactly? I don't see it in the online version. > > See <http://llvm.org/docs/LangRef.html#t_function> and look at the second example: > > float (i16 signext, i32 *) * > > Pointer to a function that takes an i16 that should be sign extended

On Mar 1, 2010, at 04:43, Duncan Sands wrote: > [I wrote:] >> >> Nevertheless, the LLVM Language Reference document suggests, in the examples for the Function Types section, that parameter attributes are part of function types. > > Where exactly? I don't see it in the online version. See <http://llvm.org/docs/LangRef.html#t_function> and look at the second

On Mon, Mar 1, 2010 at 8:20 PM, james woodyatt <jhw at conjury.org> wrote: > On Mar 1, 2010, at 09:56, james woodyatt wrote: >> On Mar 1, 2010, at 04:43, Duncan Sands wrote: >>> >>> Where exactly?  I don't see it in the online version. >> >> See <http://llvm.org/docs/LangRef.html#t_function> and look at the second example: >> >>  

Ok, here is the patch again... I also included fixes for the bits that originally gave my mailer fits... Two votes for orange, so I went with orange... Doing diffs in .: --- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800 +++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800 @@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char * Result +=

On Mar 31, 2009, at 12:04 PM, Rafael Espindola wrote: >> Did you see this Ali? >> http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt > > Would you mind adding it to SVN? Would make it easier > to comment on. In particular, it would be nice to add > examples for X86 (caller extends. High bits undefined > in the callee) and PPC (callee extends). Sure, I checked

Hi all, I've also been developing an interest in using IR annotations for my compiler. Some discussion with Bart turns out that he has implemented some code to parse the llvm.globals.annotations array, but in no way integrated or reusable. We've spent some thought about how this could be done properly, which I will share here. Firstly, however, I was wondering about the format of the

Hi, I'm trying to annotate certain functions in C code, and do something with these functions in my LLVM pass. I annotate the C code like this: int __attribute__((annotate("annot"))) function() { This nicely gets added to the LLVM bitcode in an @llvm.global.annotations global. Now I had hoped that it'd be easy to extract a list of functions annotated with my annotation

On Mar 16, 2011, at 5:58 AM, Ken Dyck wrote: > In SelectionDAGBuilder::visitRet(), there is this bit of code: > > // FIXME: C calling convention requires the return type to be promoted > // to at least 32-bit. But this is not necessary for non-C calling > // conventions. The frontend should mark functions whose return values > // require promoting

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

> Did you see this Ali? > http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt Would you mind adding it to SVN? Would make it easier to comment on. In particular, it would be nice to add examples for X86 (caller extends. High bits undefined in the callee) and PPC (callee extends). And I still don't understand why in short y(); int z() { return ((int)y() << 16) >>

On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > Promoting the return value is unsafe for bool returns on x86-64, which in the latest revision of the ABI only guarantees that the top 7 bits of the 8-bit register are 0. My comment is a bit off, because the question of what type to make the return value is somewhat orthogonal to the question of which zext assert we should add. Cameron

On Wed, Mar 16, 2011 at 12:35 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > >> Promoting the return value is unsafe for bool returns on x86-64, which >> in the latest revision of the ABI only guarantees that the top 7 bits of >> the 8-bit register are 0. > > My comment is a bit off, because the question

Hi all I have a project where LLVM annotations could be very useful. My current understanding of LLVM in general is still limited, hence a nice interface to annotations or sample code that uses annotations would help me to get started. I was wondering what happened to the proposal for a better interface to handling of annotations, which has been discussed in this thread back in July.

Hi All, I've finally implemented my proposed changes to the testing documentation. I think I fixed up the naming everywhere, but I did only a single pass over the document, so I might have missed something. Review welcome :-) It is now recommended to put the test suite in "projects/test-suite" instead of "projects/llvm-test". I've also updated the configure script and