search for: llvmbuildgep2

Displaying 4 results from an estimated 4 matches for "llvmbuildgep2".

Did you mean: llvmbuildgep
2019 Dec 16
3
Using "opaque pointers" right now?
I was looking at the talk from 2015 about opaque pointers. Aside from using the new methods (e.g. LLVMBuildGEP2), is there any other way to perpare for this change? And also - is it possible to use something like opaque pointers (that is using a single pointer type) even before the switch has been flipped in LLVM? Christoffer AEGIK / www.aegik.se
2015 Aug 17
2
[LLVMdev] [RFC] Developer Policy for LLVM C API
...u have more person in that thread saying they'd need it and have to do various workaround to get things done without it. > >> - Let's say you remove types from pointers. >> >> This is a change that can be seen coming up. So, one should fairly early >> on add an LLVMBuildGEP2 function that takes the extra type argument. Leave >> the old function name around for now (deprecated), because with the current >> state of LLVM, it can continue to work just fine. >> >> When LLVM is changed to *actually* remove all pointer types in its core, >> then...
2015 Aug 17
6
[LLVMdev] [RFC] Developer Policy for LLVM C API
...keep working. There's no real need to remove the old deprecated functions -- they'll keep working as well as they ever did with the smaller-valued attributes. - Let's say you remove types from pointers. This is a change that can be seen coming up. So, one should fairly early on add an LLVMBuildGEP2 function that takes the extra type argument. Leave the old function name around for now (deprecated), because with the current state of LLVM, it can continue to work just fine. When LLVM is changed to *actually* remove all pointer types in its core, then the LLVMBuildGEP function cannot reasonably...
2015 Aug 17
3
[LLVMdev] [RFC] Developer Policy for LLVM C API
On Sun, Aug 16, 2015 at 10:34 PM, deadal nix via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > 2015-08-16 21:51 GMT-07:00 Eric Christopher <echristo at gmail.com>: >> >> The promise of stability. We don't promise that the C++ API will stay >> stable. >> > > > Why was that promise be made in the first place ? Has it been made in the >