similar to: Language Changes in 3.7 and beyond

Function has its own FunctionType* member as well as a Type* member that it inherits from GlobalValue. The latter can be mutated but not the former, leading to potential strange inconsistencies. While I realize using mutateType is probably going to trigger a bunch of "you're doing it wrong" replies, it seems like mutateType, as a necessary evil, should be virtual and do the right

There are two C++ signatures for CreateConstGEP1_32: Value * CreateConstGEP1_32 (Value *Ptr, unsigned Idx0, const Twine &Name="") Value * CreateConstGEP1_32 (Type *Ty, Value *Ptr, unsigned Idx0, const Twine &Name="") I'm assuming that this means that the caller can supply the expected type, and get error checking or casting? Or choose to not supply the

Thanks David. I ended up trying this over the weekend (see https://github.com/llvm-project/llvm-project/compare/ master...pcc:pointertype). It ended up being a net reduction in code size so seems like a useful cleanup even independent of the typeless pointer work, I'll see if I can send a patch to the list. FWIW I think this directly helps towards the migration because we would have a clearer

Hi all, An oddity that has existed for a long time in the IR is that PointerType derives from SequentialType. Per subject I propose to make PointerType derive from Type for a couple of reasons: - Values of type PointerType are unlike the other SequentialTypes (arrays and vectors) in that they do not hold values of the element type. By moving PointerType we can unify certain aspects of how the

On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given thiscall calling convention to methods by > default. > > I think the last bug blocking us to support the new abi has just been > fixed.

Seems pretty plausible to me - my only question would be whether it's worth the churn to do this intermediate step before finishing off typeless pointers (granted, I've stalled out on that for nearly a year, admittedly - but good to have extra hands/incentives - there's still a fair bit of work to do though, so understandable if it might not be useful to block progress on other things

As someone who used the LLVM C API for an experiment back in 2009ish (porting the SBCL lisp compiler to target LLVM as a backend -- never finished), I thought it was great that LLVM provided the C API. I was sad that it wasn't properly updated to include support for all the newly introduced IR features, though. (E.g. atomics). I tried to send patches for some of that stuff a while later, but

LLVM Weekly - #1, Jan 6th 2014 ============================== Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. I've been a long time lurker on the LLVM and Clang mailing lists and have been using LLVM extensively in my PhD research for the past 4 years. I thought it might be worthwhile to

Hi all, Recently I have implemented a transformation pass based on LLVM3.5 and its function is to duplicate the function's argument list in a bytecode file and replace all use of original function with modified function. In LLVM3.5, the pass can work properly. However, when I tried to transplant the pass to LLVM3.9, the error "Argument value does not match function argument type!"

The 3.6 release is drawing nearer, but the release notes could still use a lot of improvement: LLVM: https://github.com/llvm-mirror/llvm/blob/release_36/docs/ReleaseNotes.rst Clang: https://github.com/llvm-mirror/clang/blob/release_36/docs/ReleaseNotes.rst The good news is that they can be updated all the way up until release. If you have a patch for the release notes, commit it directly to the

On 18 May 2016, at 07:45, Alex Denisov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi everybody, > > I do write some Clang/LLVM related articles on my blog[1][2], and I will be happy to write for LLVM’s blog. > > However, I can’t omit bike-shedding :) > > Forgive me my directness, but current blog doesn’t look like something close to 2016. > > The

Mingw switched abis with the release of gcc 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now mingw (like msvc) given thiscall calling convention to methods by default. I think the last bug blocking us to support the new abi has just been fixed. The question now is how to switch. The attached patches simply switch llvm and clang to the new ABI. This is similar to what

OK. I will do some experiments with (1) on Power PC. Will update this email chain about the results. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/f05c1bad/attachment.html>

On Tue, Mar 22, 2016 at 1:41 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Sorry I should have been more clear (writing to many email in parallel) > > You're right. I was adding a +1 to you here. > > Especially I wrote "unless there is an acknowledgement that typeless > pointers won't be there before a couple of years" with the PassManager in >

On Tue, Mar 22, 2016 at 7:33 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Mar 22, 2016, at 4:15 PM, Ehsan Amiri via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > James, > > I think (1) reduces the number of "do-not-see-through-bitcast" bugs that > we need to uncover and fix between now and the time that typeless pointer > is

But not what David was stating, unless I misread? I was specifically responding to David's wording: "If we're talking about making an optimization able to ignore the bitcast instructions - yes, that work is unnecessary & perhaps questionable given the typeless pointer work. Not outright off limits, but the same time might be better invested in moving typeless pointers

This is roughly what I wrote... > On Mar 22, 2016, at 1:31 PM, Philip Reames <listmail at philipreames.com> wrote: > > I feel very strongly that blocking work on making optimization bitcast-ignorant on the typeless pointer work would be a major mistake. Unless we expected the typeless pointer work to be concluded within the near term (say 3-6 months maximum), we should not block

Thanks. *Phillip, *As Hal said I do not think (1) is a very large item. Please let me know if I am mistaken. *David *I think (1) is more inline with typeless pointer work than (2). Contributing to typeless pointer work will be great, but given its unknown time frame we cannot stop fixing existing problems. Of course, we should follow an approach consistent with the long-term solution. On Tue,

Sorry for my delay responding, finally caught up on my email to this point and read through the whole thread. First and foremost: we should *definitely* not sit on our hands and wait for typeless pointers to arrive. However, we also shouldn't (IMO) take on lots of technical debt instead of working on causing typeless pointers to arrive sooner. But I don't think any of the options here are

I feel very strongly that blocking work on making optimization bitcast-ignorant on the typeless pointer work would be a major mistake. Unless we expected the typeless pointer work to be concluded within the near term (say 3-6 months maximum), we should not block any development which would be accepted in the typeless pointer work wasn't planned. In my view, this is one of the largest