search for: llvm_attribute_deprecated

Hi All, During a discussion about instruction scheduling in LLVM [1], I realize that class PostRASchedulerList actually is deprecated. The documentation of instruction scheduling is pretty poor, so I cannot find such information. Removing the obsoleted class might be too aggressive. I am wondering if we can mark the class as deprecated [2] (seems C++14 feature required), or at least making a

...s > old, and the old version doesn't work with current LLVM trunk. > > In many, many cases it is almost zero effort for the person making the > chance in LLVM to split it up into a sequence of logical changes: > > 1) Add the new API. > 2) Use it in llvm-project. > 3) Add LLVM_ATTRIBUTE_DEPRECATED to the old API. > 4) Remove the old API. > > 1-3 could be in a single commit, but having a few weeks between them > and point 4 helps _massively_. > I don't see this as a "almost zero effort", I see this as a potentially *heavy* effort actually. I am also fairly wary...

...LVM trunk. > >> > >> In many, many cases it is almost zero effort for the person making the > >> chance in LLVM to split it up into a sequence of logical changes: > >> > >> 1) Add the new API. > >> 2) Use it in llvm-project. > >> 3) Add LLVM_ATTRIBUTE_DEPRECATED to the old API. > >> 4) Remove the old API. > >> > >> 1-3 could be in a single commit, but having a few weeks between them > >> and point 4 helps _massively_. > > > > > > I don't see this as a "almost zero effort", I see this as a...

The Developer Policy document (https://llvm.org/docs/DeveloperPolicy.html) contains a Section "C API Changes". There is no corresponding section for C++ API Changes. LLVM is somewhat different from most libraries in that the main language is C++ but the C++ API is not guaranteed to be stable in any shape or form from what I understand. I think it would be useful to have a "C++ API

...> old, and the old version doesn't work with current LLVM trunk. > > In many, many cases it is almost zero effort for the person making the > chance in LLVM to split it up into a sequence of logical changes: > > 1) Add the new API. > 2) Use it in llvm-project. > 3) Add LLVM_ATTRIBUTE_DEPRECATED to the old API. > 4) Remove the old API. > > 1-3 could be in a single commit, but having a few weeks between them > and point 4 helps _massively_. > > It allows us to keep compiling against LLVM trunk in our CI, while one > person goes and fixes up our use of the API (which w...

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

> 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