similar to: [LLVMdev] API design

On Sun, 1 Jul 2007, Nick Lewycky wrote: > I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to > see what would happen, and it's been a complete disaster. > > The major problem is the use of this API: > > new CallInst(V, &Args[0], Args.size()); > > repeated throughout LLVM. When Args is empty, Args[0] is invalid, even > if the next

On Monday 02 July 2007 16:26, Chris Lattner wrote: > On Sun, 1 Jul 2007, Nick Lewycky wrote: > > I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to > > see what would happen, and it's been a complete disaster. Well, that's a bit harsh, isn't it? It's finding bugs, just like it's supposed to. :) I believe I've started to run into

> > I'd like to get the extra checks working so that they can help find our > > more subtle bugs. Any idea what we should do here? > > I don't really have a good idea, but I also don't want to significantly > uglify the sourcebase... #define V_CALLINST(V, Args) new CallInst(V, Args.size() == 0 ? NULL : &Args[0], Args.size()) :p -Keith

On Mon, 2 Jul 2007, David A. Greene wrote: >>> - Changing the API >>> a) Template it to take two iterators. This causes code size bloat. > > This seems like the right solution to me. Unless llvm is running on > extremely limited memory embedded systems, the extra code space > shouldn't be an issue. Code size is always an issue. What specifically are you

Nick Lewycky <nicholas at mxc.ca> writes: > Hi, > > I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to > see what would happen, and it's been a complete disaster. > > The major problem is the use of this API: > > new CallInst(V, &Args[0], Args.size()); Forgive me if I'm missing something, but why is it assumed that &Args[0]

On Tue, 2007-07-03 at 09:04 +1200, Keith Bauer wrote: > > > I'd like to get the extra checks working so that they can help find our > > > more subtle bugs. Any idea what we should do here? > > > > I don't really have a good idea, but I also don't want to significantly > > uglify the sourcebase... > > #define V_CALLINST(V, Args) new CallInst(V,

On Tuesday 03 July 2007 00:44, Chris Lattner wrote: > On Mon, 2 Jul 2007, David A. Greene wrote: > >>> - Changing the API > >>> a) Template it to take two iterators. This causes code size bloat. > > > > This seems like the right solution to me. Unless llvm is running on > > extremely limited memory embedded systems, the extra code space > >

On Monday 02 July 2007 23:24, David A. Greene wrote: > > > - Changing the API > > > a) Template it to take two iterators. This causes code size bloat. > > This seems like the right solution to me. Unless llvm is running on > extremely limited memory embedded systems, the extra code space > shouldn't be an issue. It turns out this wasn't quite a simple as

On Wed, 4 Jul 2007, David A. Greene wrote: > On Monday 02 July 2007 23:24, David A. Greene wrote: >>>> - Changing the API >>>> a) Template it to take two iterators. This causes code size bloat. >> >> This seems like the right solution to me. Unless llvm is running on >> extremely limited memory embedded systems, the extra code space >>

On Thu, 5 Jul 2007, David Greene wrote: >>> We should just keep the existing constructor, so this isn't a problem. >>> These clients don't have the "dereference end" problem. >> >> Duh. >> >> Yep, ok, this sounds good. > > Grr. That's no so easy either, because it conflicts with the one-argument > specialized constructor.

On Thursday 05 July 2007 11:54, Chris Lattner wrote: > > I've opted for the alternate approach: make all clients pass iterators. > > That is, get rid of the specialized one- and two-argument constructors > > entirely. > That sounds reasonable. Please keep the "Value* + num elements" ctor as > well though. Why? I can't think of a case where a client

On Wednesday 04 July 2007 15:46, Chris Lattner wrote: > > Since array doesn't have begin/end members we'd need some kind of > > specialization for that case. Iterators nicely avoid this issue. > > We should just keep the existing constructor, so this isn't a problem. > These clients don't have the "dereference end" problem. Duh. Yep, ok, this

On Wednesday 04 July 2007 22:37, David A. Greene wrote: > On Wednesday 04 July 2007 15:46, Chris Lattner wrote: > > > Since array doesn't have begin/end members we'd need some kind of > > > specialization for that case. Iterators nicely avoid this issue. > > > > We should just keep the existing constructor, so this isn't a problem. > > These

Greetings, Lang and other JITters, Last week I moved our Orc v2-based app from top-of-tree to the new 11.x branch, and it no longer handles C++ code containing OpenMP directives correctly. More specifically, if I JIT compile a function containing OpenMP parallel/for pragmas, using a release version of LLVM, the code compiles and seems to work, but if I try to write the module's bitcode to

On Wednesday 04 July 2007 14:57, Chris Lattner wrote: > > template<typename InputIterator> > > CallInst(Value *Func, InputIterator ArgBegin, InputIterator ArgEnd, > > const std::string &Name = "", Instruction *InsertBefore = 0, > > Is it acceptable to just make the template argument be the container? > That way you could pass: > >

Hi everyone, Nick and Philip suggested something yesterday that I'd also thought about: supporting attributes on values (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140908/234323.html). The primary motivation for this is to provide a way of attaching pointer information, such as noalias, nonnull and dereferenceable(n), to pointers generated by loads. Doing this for pointers

Hi Geoff, Nothing in that backtrace leaps out at me. Based on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here,

Apologies for the noop question in advance (just getting started with LLVM), and I'm not entirely sure if this is the right list to post to. is it? I have some lambda functions as member variables that I want to have my LLVM language make calls to. I've added a mapping to them, but this doesn't seem to enable LLVM to resolve the functions. I asked on stackoverflow but the suggestion

On May 15, 2009, at 10:52 AM, Gordon Henriksen wrote: > On 2009-05-15, at 07:26, David Greene wrote: > >> On Friday 15 May 2009 05:50, Jay Foad wrote: >>> >> >>>> The one major thing to be aware of is that it isn't safe to use >>>> &V[0] when V is an empty std::vector >>> >>> Oh dear. That's a bit of a flaw in the

Hi, That patch was from an ongoing effort to consolidate OpenMP generation in clang. If memory serves the implementation there is still a little incomplete. It's supposed to use types from OMPConstants rather than ones it defined itself and the methods used to create the functions shouldn't need to be static. However attempting this caused a lot of errors so there might be an underlying