similar to: [LLVMdev] StructRetPromotion and linkage

Hi Rich, > I was thinking about my problem and thought that there might be a good > interim solution. I would like not to clutter my front end with stuff > that will go away. How about a pass that runs before code generation > that changes functions returning structs to void functions with the > return pointer first parameter? On this topic, you should look at the

On May 8, 2008, at 05:50, Matthijs Kooijman wrote: > I've attached two patches. The first, pass-comments.diff adds or > improves the file comments for a number of passes. This patch is > slightly interesting. The second, pass-doc.diff is mostly a yank-put > job and updates Passes.html as follows. Thanks, applied!

Hi all, I've attached two patches. The first, pass-comments.diff adds or improves the file comments for a number of passes. This patch is slightly interesting. The second, pass-doc.diff is mostly a yank-put job and updates Passes.html as follows. I've removed the following passes from the documentation: Lower GC intrinsics, for GCless code generators (-lowergc) Correlated Expression

Hi, I was evaluating all transformation passes and noticed a few things. In particular, I found three passes in the documentation that I can't seem to find any code for. Where these removed? Lower GC intrinsics, for GCless code generators (-lowergc) Correlated Expression Elimination (-cee) Lower select instructions to branches (-lowerselect) Additionally, I found the following passes for

Hi, the ArgumentPromotion pass replaces aggregrate function arguments by multiple individual arguments. The default pass only does this when the aggregrate has 3 or less elements, otherwise the code will be unchanged. I have a need to always promote aggregrate arguments, even when there are a lot of them. The attached patch adds a "maxElements" argument to ArgPromotion's

Chris Lattner wrote: > On Jul 20, 2008, at 10:59 AM, Richard Pennington wrote: > I'm sure the implementation will take the same approach, but it won't > necessarily be ABI compatible. I don't know enough to say at this > point... it may end up being ABI compatible or not depending on > implementation details. Hi Chris, I was thinking about my problem and thought

Hi all, I'm currently running into some problems with instcombine changing the type of alloca instructions. In particular, the PromoteCastOfAllocation looks at any allocation instruction that is used by a bitast. It does a few checks, but basically tries to change the type of the alloca instruction to the type pointed to by the bitcasted type. The current heuristic for determining if this is

> From what I can see comparing 2.3 with TOT, the "cexp" function is > declared like this in 2.3: > > declare i128 @cexp({double, double}* byval) nounwind > > It used to be this: > > declare void @cexp({double, double}* noalias sret, {double, double}* > byval) nounwind The promotion from a void function with an sret argument to a function returning

Hi Nicolas (at least, I suspect your signing of your mail with "Anton" was not intentional :-p), > I assume that's the same as the online demo's "Show LLVM C++ API code" > option (http://llvm.org/demo/)? I've tried that with a structure containing > four floating-point components but it also appears to add them individually > using extract/insert. Maybe

Hi Dan, > The requirement to update all callers' call instructions when a callee > gets a new return value is also present in the current MRV-mechanism > with getresult. It's not been a problem we've worried about so far. I didn't mean you can get away without updating your calllers, I'm just saying it could be a bit easier. > Can you give some background about

Hi Dan, > Yes, the intention is that getresult will be removed once first-class > aggregates are a ready replacement. This won't leave LLVM missing the > concept of returning multiple values; a struct can be thought of as > a container for multiple values. I'm not saying we don't have some way of modeling multiple return values, I'm sayin the explicit concept

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

Hi Syoyo, > I am trying to get a return type of a function(from bitcode file) with > LLVM-C API, but there seems no appropriate API to do that. From my memory, this info is stored in the function type, so you could look at the function's type and get the info there. Looking the the API docs [1], I find that there is a simple method on Function called getReturnType(). You should thus be

Hi Dan, > in the AMD 5.5 What's that? Got a link? Google only finds some kind of golf cart powered by the "Advanced Motors & Drivers 5.5" engine :-) Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:

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.

Hi Matthijs, Changing PromoteCastOfAllocation to not replace aggregate allocas with non-aggregate allocas if they have GEP users sounds reasonable to me. Finding the maximum alignment is sometimes still useful though, so it would be nice to update the alignment field of the alloca even if its type is left unchanged. Dan On Sep 8, 2008, at 8:57 AM, Matthijs Kooijman wrote: > Hi all, >

Hi All, I've been fiddling around with a DenseMap to store cached copies of some result. In short, I'm doing the following: It = Map.find(Key) if (It != Map.end() && It->second != Unknown) Return It->second; // do_stuff return Map[Key] = Result; However, I this requires two lookups in the hash table, which is not so nice. Currently, there is no way to write this down so

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some

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>

On Jul 16, 2008, at 9:58 AM, Matthijs Kooijman wrote: > Hi all, > > once more with the patch inline for easy review. I did not include the > argpromotion pass here, since it's not the main topic of this post. Hi Matthijs, I'd prefer to not turn this into a template. Why not just define a version that takes an array of uint64_t's or something like that? -Chris