search for: whitequark

On 2016-01-30 07:39, Eric Christopher wrote: > On Fri, Jan 29, 2016 at 8:38 PM whitequark <whitequark at whitequark.org> > wrote: > >> On 2016-01-30 07:36, Eric Christopher wrote: >>> It's known to be failing right now because of recent changes, but >> I'm >>> curious why that bot has ocaml installed for the bindings? >> >>...

On Fri, Jan 29, 2016 at 8:38 PM whitequark <whitequark at whitequark.org> wrote: > On 2016-01-30 07:36, Eric Christopher wrote: > > It's known to be failing right now because of recent changes, but I'm > > curious why that bot has ocaml installed for the bindings? > > I would guess because I've been a...

...}if >> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/ >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- whitequark

Hi all, It looks like I ended up reviewing most C API patches over the last few years. There's currently no code owner listed for the C API. I'd like to take it so that contributors know to tag me as a reviewer. Any objections? -- whitequark

Ah, that's why Clang is obsessively pushing them into return by reference? On Thu, May 24, 2018 at 6:29 PM, whitequark <whitequark at whitequark.org> wrote: > On 2018-05-25 00:39, Alexandre Isoard via llvm-dev wrote: > >> Hello, >> >> I see here: https://llvm.org/docs/LangRef.html#ret-instruction >> >> That the return instruction must only return values of first class >...

Hi all, We quickly talked with whitequark on IRC about this. I think he makes a good candidate. I also wrote and reviewed a lot of code in there, so if that's needed I can be in there. In any case, I voutch for whitequark. Amaury Séchet 2018-04-12 0:54 GMT+02:00 whitequark via llvm-dev <llvm-dev at lists.llvm.org>: > Hi all...

...m.stackrestore intrinsic. It is only legal to pass a value returned by stacksave to stackrestore. If you need more control, consider @llvm.read_register and @llvm.write_register intrinsics, which allow arbitrary manipulation of the stack pointer (but, I think, will inhibit optimizations more). -- whitequark

On Thu, May 10, 2018 at 10:35 PM, whitequark <whitequark at whitequark.org> wrote: > On 2018-05-11 02:28, Andrew Kelley via llvm-dev wrote: > >> In the Zig frontend, we know at compile-time the entire call graph. >> This means we know stack size for all functions and therefore the >> upper bound stack usage. &gt...

...ser used targets (think MSP430) may outright assert. My understanding is that calling an intrinsic that returns a struct is defined (and never needs a ret instruction), but returning a struct from user code (which does need a ret instruction) is not, which is why LangRef is written like that. -- whitequark

Hello, I see here: https://llvm.org/docs/LangRef.html#ret-instruction That the return instruction must only return values of first class types, which would exclude struct and arrays. But some llvm instrinsics do return struct, and it does not seems to be enforced on any function. Is that restriction lifted and the documentation not up to date? Can we return arrays? I see the same restriction

...pass and all we need to do is port these patches to trunk llvm. I'd be happy to help with this effort. -Aditya ________________________________ From: Nikita Popov <nikita.ppv at gmail.com> Sent: Thursday, January 31, 2019 3:46 PM To: Vedant Kumar Cc: llvm-dev; Reid Kleckner; Aditya K; whitequark at whitequark.org; Teresa Johnson; Duncan P. N. Exon Smith; Jessica Paquette Subject: Re: Status of the function merging pass? On Thu, Jan 31, 2019 at 8:52 PM Vedant Kumar <vsk at apple.com<mailto:vsk at apple.com>> wrote: Hi, I'm interested in finding ways to reduce code size. LL...

Hello folks. I'm very interested in improving LLVM's OCaml bindings. I have several nontrivial patches sitting on llvm-commits for several weeks, and so far there's been little interest in them. Could someone with a good understanding of OCaml please take a look at these? 1) http://llvm-reviews.chandlerc.com/D1925 Every other function in OCaml bindings accepts context

(readding llvmdev) On Sun, Nov 3, 2013 at 1:40 AM, Peter Zotov <whitequark at whitequark.org>wrote: > Sean Silva писал 03.11.2013 09:22: > >> On Sat, Nov 2, 2013 at 9:04 PM, Peter Zotov <whitequark at whitequark.org> >> wrote: >> >> Hello folks. >>> >>> I'm very interested in improving LLVM's OCaml binding...

In the Zig frontend, we know at compile-time the entire call graph. This means we know stack size for all functions and therefore the upper bound stack usage. Recursive calls can have a runtime-decided stack usage, and therefore I am adding a frontend feature that will heap-allocate memory to use for some function calls. The idea is that recursion adds cycles to the call graph, and we know at

...e more widely used. They're great tools! lit is, in fact, packaged separately--it is available on PyPI. FileCheck isn't; there is a similar tool on PyPI, called OutputCheck, which I have used extensively for similar jobs (matching compiler IR) but I like it much less than FileCheck. -- whitequark

Hello everyone, First of all, this is my first posting here, so feel free to tell me if I'm asking the wrong questions in the wrong place. I've discovered that the target triple normalization which used to be done at all times on sys::getDefaultTargetTriple() has been removed, due to the fact that most users of this function explicitly call Triple::normalize() on its result. This has

...> anyone for > any reason. Everything else in this post aside, if everyone who seriously believes the above leaves the project, it will inevitably improve the code quality a lot, so I hope that happens. Might not be quite the intent behind adopting a CoC, but hey, I'll take it! -- whitequark

On 7 May 2018 at 11:10, whitequark via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> The act of committing world-class technology expertise into a project, >> does not >> come with strings attached, such as an obligation to interact with anyone >> for >> any reason. > > Everything else in...

...f tree backend, however, it may cause > misoptimisation if the backend dev do not activate these opcodes via > setOperationAction and rely on them for some of their optimizations. Thanks for heads up, this will impact the OR1K backend. Is there any guidance for migrating to U*O/*CARRY? -- whitequark

These opcodes have been deprecated about a year ago, but still in use in various backend. In https://reviews.llvm.org/D47422 I would like to change the behavior of the backend to not enable the use of these opcodes by default. The opcode remains usable by any backend that wish to use them, but that should limit the situation where newer backend just use them as they are enabled by default. This