similar to: Explicitly spelling out the lack of stability for the C++ API in the Developer Policy?

Hi Nicolai, I think there are two distinct, somewhat loosely connected questions here: 1. Spelling out the (existing, implicit) policy explicitly in the documentation. 2. What the actual policy is and potentially changing it to make things easier for downstream. I started this thread with the intention of tackling 1 and not 2. I think the conversation around 2 is much harder as it will require

On Thu, Jul 23, 2020 at 8:29 AM Nicolai Hähnle via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Varun, > > On Wed, Jul 22, 2020 at 2:17 AM Varun Gandhi via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > * Stability Guarantees: The C++ API is does not guarantee any stability. > Changes may be made without any notice about deprecation and alternate APIs

On Fri, Jul 24, 2020 at 9:35 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > On Fri, Jul 24, 2020 at 12:14 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > On Thu, Jul 23, 2020 at 8:29 AM Nicolai Hähnle via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Varun, > >> > >> On Wed, Jul 22, 2020 at 2:17 AM Varun Gandhi via llvm-dev

Something that would be good to get clarity on: The RISC-V backend recently had a bugfix patch that got backported to the 10.0.1 branch. The original patch introduced a new virtual method in TargetLowering.h, and the backported patch [1] was rewritten to avoid changing the ABI of libLLVM.so. This feels like some kind of policy decision about the C++ ABI beyond "it's entirely

Hi all, At the dev meeting I promised to update everyone on where my work with opaque pointers is right now. It's taken me a while, but at least it's the same year! Current Status ============== I've put two branches up at https://github.com/TNorthover/llvm-project: "opaque-ptr" which has most of the real work so far; and "opaque-ptr-always" that additionally has

On 9/7/20 4:48 PM, Nicolai Hähnle wrote: > Hi Johannes, > > > On Mon, Sep 7, 2020 at 11:17 PM Johannes Doerfert > <johannesdoerfert at gmail.com> wrote: >> >> > As a separate comment, I don't find the reference to the C++ spec in >> >> > https://reviews.llvm.org/D86233 to be informative enough. Whenever >> >> > that

I agree, improving this makes sense. Alexander, I don’t think that “LLVM_DEFAULT_AS_PARAM” is the right way to go, I would just remove the “ = 0” default parameter entirely. -Chris > On Jul 23, 2020, at 11:02 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Alex, > > I'd be very much in favor of this, thanks for pushing ;) > > On Wed,

> pointers. If you're writing a front-end this probably means you need > to keep your AST's representation of element types alongside LLVM > pointer Values in your own data-structures Yeah, that’s no problem - the type is needed for signed/unsigned integer distinctions anyway. There’s no getting around having one’s own type hierarchy. >> And also - is it possible to use

for example I want to insert a new machine bb “before” a specific machine bb. or split a mbb and keep the later one as the original one. (to keep the label/Blackadder's correct t) (or keep other property of mbb) so I need to transfer the original mbb's predecessor to the new mbb. Nicolai Hähnle <nhaehnle at gmail.com> 於 2020年3月13日 週五 23:57 寫道： > On Fri, Mar 13, 2020 at

Has anyone tried out reviewable.io yet? It integrates with GitHub pull requests, but provides a separate UI for doing the review which promises to fix a lot of the issues encountered with Github's review interface. Some of the things it claims to support which seem like important additions: - Tracking the resolved status of each discussion point - Rebasing a PR without losing review history.

Hi, I think lit.py’s current behavior is somewhat unintuitive in the presence of -v (and not using -vv), so I’m proposing that it be changed. Current behavior: -v: Prints all the substituted lines, not clear which line failed :( -vv: Prints all the lines up to and including the line that failed :) Option 1: -v: Prints only the failing line :) -vv: Same as today. :) -vvv (new): Prints all the

Hello all, I recently finished merging the last 3.5 months of upstream changes into our CHERI LLVM fork and would like to suggest something to both simplify our future merges and also avoid bugs for targets such as AVR that use non-zero pointer address spaces. We make extensive use of address spaces: all our pointers (CHERI capabilities) use address space 200 instead of the default zero to

On 22.08.2018 13:29, Ryan Taylor wrote: > The example starts as SPIR-V with the NoContraction decoration flag on > the fmul. > > I think what you are saying seems valid in that if the user had put the > flag on the fadd instead of the fmul it would not contract and so in > this example the user needs to put the NoContraction on the fadd though > I'm not sure

Conditional on the target supporting cmov? Though that's probably not optimal. On Wed, Feb 5, 2020, 7:47 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > Hi Ryan, > > On Mon, Feb 3, 2020 at 7:08 PM Ryan Taylor via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > SimplifyCFG FoldTwoEntryPhiNode looks to simplify all 2 entry phi nodes > in a block, if it

The LLVM incubator projects have been using github PRs for reviews and so far haven't really seen any significant issues. The biggest confusion so far has not been with reviews but with the difference between "rebase and merge" and "squash and mere". We have used basically 3 different processes: Method 1: start a review with one commit on a new branch (typically in a

Any comments at all on this? Chandler perhaps? I've since dug a bit further, and it seems like the template-based solution wouldn't work anyway because DLL loading on Windows can't do the required commoning. So the general approach taken in https://reviews.llvm.org/D62802 seems to be the only technically viable path forward, though it would still be good to get an outside look at the

Uh-oh: Failed to publish: GitHub error 404 on POST https://api.github.com/repos/llvm/mlir-npcomp/pulls/42/reviews: Not Found (The llvm organization may need to authorize Reviewable as an accepted third party application.) Can an admin take the suggested action on the mlir-npcomp project in the LLVM org? I've followed the instructions in this help doc

On Mon, Aug 3, 2020 at 7:00 PM David Blaikie <dblaikie at gmail.com> wrote: > I don't have much personal interest here - but my understanding was > that there was/is a fair bit of pushback to fragmenting the > communications channels to discord before there's a more general > buy-in to switch over across the project? (perhaps I'm misremembering > the previous

Per the recent (seeming) consensus regarding incubating new projects under the LLVM organization, I would like to trial the process by requesting to incubate mlir-npcomp <https://github.com/google/mlir-npcomp>. The project is still quite young and has been primarily developed part time by myself and Sean Silva over the last ~2 months. We set it up following discussion of a Numpy/Scipy op set

Are all the records collected as they are parsed, with template parameter substitution and lets, and *then*, after all records are collected, a "pass" is made to calculate the inter-field expressions? Once I understand this, I will add a section to the new guide to explain it. I presume it is the case that this behavior should be publicized. It also appears to be the case that a record