similar to: [LLVMdev] Weird comment in Linker.h

I don't think this is right. According to llvm documentation: The index types specified for the 'getelementptr' instruction depend on the pointer type that is being indexed into. Pointer and array types can use a 32-bit or 64-bit integer type but the value will always be sign extended to 64-bits. Structure and packed structure types require i32 constants. Evan On Jul 10,

> I suppose to be annoyingly pedantic about it you could require a > network connection for the build, check svn info and svn status and > then set the version string based on whether or not there are local > patches applied to the checkout - but that would probably fall under > neurotic :) Using svnversion (as the original patch does) does exactly this. It outputs the rev

Thanks for the replies, Daniel and Matthijs. I added some code to generate the copy constraint, which I think (in the present form) is wrong (or at best not field sensitive): +void Andersens::visitGetResultInst(GetResultInst &GR) { + if (isa<PointerType>(GR.getType())) + { + // P1 = getresult P2 --> <Copy/P1/P2> +

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

> I'm not sure what you are asking. Of course caller or callee can > always allocate some temporary on the stack and memcpy to it, then > use that copy from then on. The point of byval is that the copy is > made where the ABI mandates it for by-value call parameters. If > you don't need to be ABI compatible then there is no point using > byval: it would be better to

Hi Evan, > I don't think this is right. According to llvm documentation: > > The index types specified for the 'getelementptr' instruction depend on the > pointer type that is being indexed into. Pointer and array types can use a > 32-bit or 64-bit integer type but the value will always be sign extended to > 64-bits. Structure and packed structure types require

Hi all, any comments about this patch? I'd like to get it out of my working copy :-) Gr. Matthijs > Index: lib/VMCore/Type.cpp > =================================================================== > --- lib/VMCore/Type.cpp (revision 53136) > +++ lib/VMCore/Type.cpp (working copy) > @@ -394,9 +394,8 @@ > > bool StructType::indexValid(const Value *V) const { >

Hi all, about a month ago, I've started working on my master's thesis. Since I want to focus on just that work, I've stopped my LLVM work for now. It is unclear whether I will continue my work after graduation, but it seems unlikely. I'll still keep track of LLVM from a personal interest (mostly watching the IRC channel), but I won't have the time to track any mailing lists.

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 27.09.2017 15:44, Stephan Bosch wrote: > Op 9/27/2017 om 2:36 PM schreef Matthijs Kooijman: >> Hey folks, >> >> apologies for the useless subject on my original mail, forgot to update >> it. >> >> Two more bits of info. Here's the log output related to this crash: >> >> dovecot: imap-login: Login: user=<2014>, method=PLAIN,

Hi Hendrik, > -rw-r--r-- 1 hendrik sbox 1328 2008-06-03 10:00 iterator > -rw-r--r-- 1 hendrik sbox 2418 2008-06-03 10:00 iterator.h.in Did you run AutoGen.sh (not sure about case). I think that's needed when compiling from svn, and it should generate the makefiles for building iterator.h. I think. Gr. Matthijs -------------- next part -------------- A non-text attachment was

> Assuming the default value is not a valid entry in your map (for instance, > if you're using pointers), you can do: > > Foo& entry = DenseMap[Key] > if (entry == DefaultValue) > entry = constructNewValue(); The problem here is that the DefaultValue is undefined. However, Chris suggested that the default value, ValueT(), is not undefined but simply zero. However, on

Hi James, > I'm now writing a pass and I wanna ask a question about how to > duplicate the function and add duplicated arguments in llvm, for > example: > > func(int a, char *b) -> func(int a, char *b, int a1, char *b1) > > I'm now stuck at using "getOrInsertFunction" and how to handle > "getArgumentList", please share your opinion, thanks

Hi all, I'm having some trouble building llvm-gcc as of today, with and without bootstrap. The error I get is: /home/kooijman/src/llvm-gcc/obj/./gcc/xgcc -B/home/kooijman/src/llvm-gcc/obj/./gcc/ -B/home/kooijman/src/llvm-gcc/obj/../install/i686-pc-linux-gnu/bin/ -B/home/kooijman/src/llvm-gcc/obj/../install/i686-pc-linux-gnu/lib/ -isystem

Matthijs Kooijman wrote: > Hi, > > after working with llvm for a while, I'm still a little confused with the > meaning of the 'byval' attribute. From the langref: > > "This indicates that the pointer parameter should really be passed by value to > the function. The attribute implies that a hidden copy of the pointee is made > between the caller and the

Hi Prakash, I think this is highly related to PR2527 [1] and PR2451 [2]. I assume you are using LLVM 2.3, since current svn automatically replaces getresult with extractvalue instructions (but doesn't help for Andersen's). In either case, it seems that Andersen's currently has no ready made way to indicate a part of a first-class aggregate (or vector), which is the essence of the

Op 9/27/2017 om 2:36 PM schreef Matthijs Kooijman: > Hey folks, > > apologies for the useless subject on my original mail, forgot to update > it. > > Two more bits of info. Here's the log output related to this crash: > > dovecot: imap-login: Login: user=<2014>, method=PLAIN, rip=217.122.126.195, lip=10.42.0.13, mpid=10569, TLS, session=<IsP37ypaFYHZen7D>

Hi Eli, > That said, clang really should be turning int x2() { return x(0); } > into "define i32 @x2()" rather than "define i32 @x2(...)"; the > function isn't varargs, and marking it as such could lead to wrong > code for exotic calling conventions. I always understood that this is correct per C language specification. For functions that are internal (static),

Hi Chris, > > Wouldn't it be slightly cleaner to mark the distinct objects in the > > LLVM intermediate representation? > That is what I'm suggesting. Each llvm IR global variable would have > its own flag. I think the suggestion is to have a "notmergable" flag instead of a "mergeable" flag. In practice, it doesn't really matter, but I guess

Hi, > If you distribute the GPLed library and the proprietary application > separately, and make sure that they are linked at installation time, the > link step creates a derived work indeed but that's inconsequential > because it isn't redistributed. Interestingly enough, you need a linker at the target system to do that. And guess what this discussion started at :-p Gr.