similar to: Ownership of C API

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, > > It looks like I ended up reviewing most C API

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

On 2018-05-30 16:57, Amaury Séchet via llvm-dev wrote: > 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

No objections from me to make it run later. I didn't see the potential conflicts when I added that code. Delayed combine, custom lowering, or DAGToDAGISel all seem like viable options to me. On Mon, Aug 26, 2019 at 2:04 PM Roman Lebedev <lebedev.ri at gmail.com> wrote: > I have previously posted these two patches: > > [X86][CodeGen][NFC] Delay `combineIncDecVector()` from

Hi all, As you knwo already, I'm trying to change DAGCombiner so that it process the nodes in topological order. Doing so is not difficult per se, but this creates various improvements and regression to the existing test suite. I'd like to work through as many of the regressions as possible ahead of time. One source of such regressions is combineIncDecVector in the X86 backend. It

I think DAGToDAG is too late because the build_vector has already been turned into a constant pool load by then so it’s a little difficult to get back. Maybe we can delay it to !DCI.isBeforeLegalizeOps()? That would at least let the first DAG combine and the post type legalization DAG combine see the add, 1. +Sanjay as well From: Amaury Séchet <deadalnix at gmail.com> Sent: Monday, August

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? >> >> I would

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 asking for OCaml to be installed > for quite some time

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

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 asking for OCaml to be installed for quite some time :) > > -eric > > On Fri, Jan 29, 2016 at 8:34 PM Dmitri Gribenko via llvm-dev > <llvm-dev at

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. >> >> [snip] >> 1. Is there a way to

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. > > [snip] > 1. Is there a way to accomplish this with existing LLVM API? You should use the @llvm.stacksave and @llvm.stackrestore intrinsic. It is only legal

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

On 2019-01-24 20:17, David Greene via llvm-dev wrote: > alexp via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> I have a project which uses llvm, but is (at least not yet) a >> contribution / not in the source tree of llvm. >> Is it a good idea (e.g. instead of using boost test framework) to use >> the llvm testsuite related tools in this case? > >

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

Hi Nikita, Glad to hear that Rust code can benefit a lot from this. I have put patches to enable merge-similar functions with thinLTO. https://reviews.llvm.org/D52896 etc. <https://reviews.llvm.org/D52896> This is more powerful than existing merge-functions pass and all we need to do is port these patches to trunk llvm. I'd be happy to help with this effort. -Aditya

On 2018-05-07 07:46, Unnamed Poster via llvm-dev 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 this post aside, if everyone who seriously believes the above leaves the project, it will inevitably improve the code quality

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 this post aside, if everyone who seriously believes the > above

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

(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 bindings. I have