similar to: [LLVMdev] linker_private* linkage

This patch introduces a the new "linker_private_weak" linkage type. Why a new linkage type? The idea behind the "linker" linkage types is that they are used by the linker and then discarded. I.e., the symbols won't show up in the final linked image. In that regard, all "linker" linkage types are inherently "private". The "linker" linkages are

On Jun 30, 2010, at 1:36 PM, Bill Wendling wrote: > This patch introduces a the new "linker_private_weak" linkage type. > > Why a new linkage type? The idea behind the "linker" linkage types is that they are used by the linker and then discarded. I.e., the symbols won't show up in the final linked image. In that regard, all "linker" linkage types are

On Jun 30, 2010, at 9:52 PM, Chris Lattner wrote: > On Jun 30, 2010, at 1:36 PM, Bill Wendling wrote: > >> I implemented the new linkage to have its own prefix from linker_private. As it currently stands, the symbol's prefix ("l") is the same for "linker_private" and "linker_private_weak". If this will always be the case, then I can remove the code

On Fri, Dec 19, 2014 at 12:56 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > However, I think this would set a bad precedent. There's nowhere else > (that I know of) where we accept two versions of assembly. The > LLParser is relatively easy to work with because it doesn't have that > kind of historical baggage. I can think of two precedents:

---------- Forwarded message ---------- From: charles quarra <charllsnotieneningunputocorreo at gmail.com> Date: 2012/12/13 Subject: error while linking modules with exception handling demo code To: llvmdev at cs.uiuc.edu Hi, I am building a module X with an arithmetic function foo, a module Y with an arithmetic function foo2 that invokes foo. For the invocation be a proper one (being

everyone-- The OCaml bindings need help again. diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800 +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Sun Dec 27 11:38:15 2009 -0800 @@ -42,13 +42,18 @@ | External | Available_externally | Link_once + | Link_once_odr | Weak +

Hi Duncan, >> #include<stdio.h> >> #include<string.h> >> >> int main(int argc, char** argv){ >> >> char a[8] = "aaaaaaa"; >> char b[8] = "bbbbbbb"; >> >> char *c = (char*) malloc(sizeof(char)*(strlen(a)+strlen(b)+1)); >> memcpy(c, a, strlen(a)); >> memcpy(c + strlen(a), b, strlen(b) + 1); >>

Hi Pablo, I can reproduce this with the supplied IR. It is related to the use of __memcpy_chk. As far as I can see it is a bug in lli or the LLVM code generators. Can you please open a bugreport, attaching the LLVM IR. Ciao, Duncan. On 23/01/12 17:00, Pablo Barrio wrote: > Hi Duncan, >>> #include<stdio.h> >>> #include<string.h> >>> >>> int

Sorry, we really screwed up the server migration. Alive is now working again and should be fixed for good :) Permalinks are still missing; we are working on recovering those. Apologies again for all the trouble. Nuno -----Original Message----- From: Sanjay Patel Sent: Monday, October 2, 2017 5:10 PM Subject: Re: [llvm-dev] Where did Alive go? I still can't use the web app - spins for

Craig I know it's a pain compared to the web interface but Alive is pretty easy to install and run from a shell. John On 9/22/17 11:41 AM, Craig Topper via llvm-dev wrote: > And now rise4fun.com <http://rise4fun.com> doesn't work at all? > > ~Craig > > On Wed, Sep 20, 2017 at 9:53 AM, Nuno Lopes <nunoplopes at sapo.pt > <mailto:nunoplopes at

And now rise4fun.com doesn't work at all? ~Craig On Wed, Sep 20, 2017 at 9:53 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Alive is now working again. There was a migration to a new server. > Permalinks are still being copied from backup; they will work again > shortly as well. (I would probably not create new ones since they may get > replaced while the copy is in

Alive is now working again. There was a migration to a new server. Permalinks are still being copied from backup; they will work again shortly as well. (I would probably not create new ones since they may get replaced while the copy is in flux). Nuno Citando Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org>: > I'm investigating; thanks for the heads up. Sorry for the

Hey Scott, There has been quite a lot of research on capture tracking (aka escape analysis) for Java and other dynamic languages. See e.g.: https://wiki.openjdk.java.net/display/HotSpot/EscapeAnalysis http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html http://dl.acm.org/citation.cfm?doid=320384.320386 Nuno -----Original Message----- From: Scott Egerton via

On Jun 4, 2012, at 10:37 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > So here is a new proposal: > > !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } The parameters are a separate metadata array or the alloc_size metadata is variable length? You'll probably want to write up some docs for the website on how this is supposed to be laid out and work. -eric

On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > >On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: > >>>> Thank you all for your replies. > >>>> So here seems to be an agreement that the documentation for > >>>> PartialAlias is incorrect. > >>>>

Definitely have a look at the current analyses: - llvm/Transforms/IPO/FunctionAttrs.cpp - llvm/Transforms/IPO/InferFunctionAttrs.cpp Also, study the semantics of these attributes, starting with the docs: http://llvm.org/docs/LangRef.html#function-attributes Also, grep the LLVM sources for test cases that use the attributes to see examples on how they are used for optimization. Finally, have a

We have these transforms from funnel shift to a simpler shift op: // fshl(X, 0, C) -> shl X, C // fshl(X, undef, C) -> shl X, C // fshl(0, X, C) -> lshr X, (BW-C) // fshl(undef, X, C) -> lshr X, (BW-C) These were part of: https://reviews.llvm.org/D54778 In all cases, one operand must be 0 or undef and the shift amount is a constant, so I think these are safe.

>> On Thu, Mar 1, 2018 at 2:08 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> We can do "add %x, undef" => "undef" because for any value of %x, we can >> always find a value that when added to %x produces any value in the >> domain of integers. >> >> This is not the case with floats since with some inputs, e.g., NaNs, we

On Sat, Jun 27, 2015 at 2:16 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > At least in C/C++ that's UB, yes. So you cannot map every turing machine to a valid C/C++ program then. :) Also, does this mean that "daemon" programs that run continuously till they're killed by the OS (using a mechanism that is not visible in C) are effectively undefined? -- Sanjoy >

On Tue, Jun 7, 2016 at 4:02 PM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (+CC LLVM dev - I'd dropped it in my original reply unintentionally and > just noticed.) > > On 06/07/2016 01:35 PM, Philip Reames wrote: > >> (This was written in a rush. There may be mistakes; if so I'll try to >> correct later.) >> >> At the