similar to: [LLVMdev] ocaml bindings

On Dec 27, 2009, at 11:41 AM, james woodyatt wrote: > everyone-- > > The OCaml bindings need help again. Please attach this as a .patch file and I'd be happy to apply it for you, -Chris > > 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 > +++

On Tue, Feb 23, 2016 at 10:55 AM, Chandler Carruth <chandlerc at gmail.com> wrote: >> Part of the challenge here is to specify the attribute in a way that >> allows inlining, but not IPA without inlining. In fact, maybe it is >> best to not call it "interposable" at all? > > > Yea, this is something *very* different from interposable. GCC and other >

On Mon, Feb 22, 2016 at 11:18 PM, Chandler Carruth <chandlerc at gmail.com> wrote: >> # step A: Introduce an `interposable` function attribute >> >> We can bike shed on the name and the exact specification, but the >> general idea is that you cannot do IPA / IPO over callsites calling >> `interposable` functions without inlining them. This attribute will

On Monday 26 November 2007 20:05, Gordon Henriksen wrote: > On Nov 26, 2007, at 14:18, Jon Harrop wrote: > > On Monday 26 November 2007 16:21, Gordon Henriksen wrote: > >> Unfortunately, even if the bindings were more strongly typed, it > >> would still be structurally possible to build invalid LLVM code, so > >> you've just got to take care not to violate

On Nov 26, 2007, at 14:18, Jon Harrop wrote: > On Monday 26 November 2007 16:21, Gordon Henriksen wrote: >> > >> Unfortunately, even if the bindings were more strongly typed, it >> would still be structurally possible to build invalid LLVM code, so >> you've just got to take care not to violate the invariants, then >> use the verifier as a

Dear LLVM developers, Our team has developed an LLVM-based protection mechanism that (i) prevents control-flow hijack attacks enabled by memory corruption errors and (ii) has very low performance overhead. We would like to contribute the implementation to LLVM. We presented this work at the OSDI 2014 conference, at several software companies, and several US universities. We received positive

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tom Stellard > Sent: 19 September 2014 01:36 > To: Sanjay Patel > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] predicates vs. requirements [TableGen, > X86InstrInfo.td] > > On Thu, Sep 18, 2014 at 03:25:07PM -0600, Sanjay Patel wrote: >

I tried to add an 'OptForSize' requirement to a pattern in X86InstrSSE.td, but it appears to be ignored. However, the condition was detected when specified as a predicate. So this doesn't work: def : Pat<(v2f64 (X86VBroadcast (loadf64 addr:$src))), (VMOVDDUPrm addr: $src)>, *Requires<[OptForSize**]>*; But this does: * let Predicates = [OptForSize]

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:

Hi, I'm trying to understand better how linker_private (and friends) work. From what I can understand from the manual (http://llvm.org/docs/LangRef.html#linkage_linker_private), it seems that a linker_private function cannot be removed by the optimizers. Only the linker can discard the symbol. However, I tested with 'opt -O1' and a function with *no users* is removed. Same

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

---------- 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

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 10/2/19 5:12 PM, Hal Finkel wrote: On 10/1/19 12:35 AM, Serge Pavlov via llvm-dev wrote: Hi all, This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND' as well as some other

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

Thank You. But I cannot find your mentioned function LoopVectorizationCostModel::computeFeasibleMaxVF(bool OptForSize, unsigned ConstTripCount). I am using LLVM 4. I have been trying to get the required code portion in LoopVectorize.cpp file. But I am unable to debug this. each time i debug it, it returns me vectorized IR in gdb. My goal is simple when i mention my target name in opt it should

Specifying -no-implicit-float prevents LLVM from using non-GPR registers for purely integer operations. This is useful for operating systems (such as Wind River's VxWorks) that support tasks that do not save all registers on context switch. This presents an interesting problem for variadic functions that may optionally take non-integer arguments (e.g. printf style functions). Should non-GPR

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

Hi Akira! > > Does the current loop vectorizer inquire about the SIMD capabilities of the target architecture when it decides whether it is profitable to vectorize a loop? Yes, it uses a cost model to determine the profitability of vectorization. At the moment only x86 provides the necessary hooks that are needed for calculating the costs. We may need to change the cost defaults to