Hi,
I've spent the last weeks working on my LLVM compilation patchset. In
the course of that I *heavily* revised it. While still a good bit away
from committable, it's IMO definitely not a prototype anymore.
There's too many small changes, so I'm only going to list the major
things. A good bit of
Hi,
I've spent the last weeks working on my LLVM compilation patchset. In
the course of that I *heavily* revised it. While still a good bit away
from committable, it's IMO definitely not a prototype anymore.
There's too many small changes, so I'm only going to list the major
things. A good bit of
On Wednesday, January 24, 2018 8:20:38 AM CET Andres Freund wrote:
> As the patchset is large (500kb) and I'm still quickly evolving it, I do
> not yet want to attach it. The git tree is at
> https://git.postgresql.org/git/users/andresfreund/postgres.git
> in the jit branch
>
> https://git.post
Hi,
On 2018-01-24 22:35:08 +0100, Pierre Ducroquet wrote:
> I tried to build on Debian sid, using GCC 7 and LLVM 5. I used the following
> to compile, using your branch @3195c2821d :
Thanks!
> $ export LLVM_CONFIG=/usr/bin/llvm-config-5.0
> $ ./configure --with-llvm
> $ make
>
> And I had the
Hi,
On 2018-01-24 14:06:30 -0800, Andres Freund wrote:
> > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as
> > a C
> > ++ API in llvm/IR/DebugInfo.h.
>
> Hm, I compiled against 5.0 quite recently, but added the stripping of
> debuginfo lateron. I'll add a fallback met
On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet wrote:
> In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as a C
> ++ API in llvm/IR/DebugInfo.h.
The LLVM APIs don't seem to be very stable; won't there just be a
continuous stream of similar issues?
Pinning major postgres
Hi,
On 2018-01-24 22:33:30 -0800, Jeff Davis wrote:
> On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet wrote:
> > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as
> > a C
> > ++ API in llvm/IR/DebugInfo.h.
>
> The LLVM APIs don't seem to be very stable; won't there ju
On Tue, Jan 23, 2018 at 11:20 PM, Andres Freund wrote:
> Hi,
>
> I've spent the last weeks working on my LLVM compilation patchset. In
> the course of that I *heavily* revised it. While still a good bit away
> from committable, it's IMO definitely not a prototype anymore.
Great!
A couple high-le
Hi!
On 2018-01-24 22:51:36 -0800, Jeff Davis wrote:
> A couple high-level questions:
>
> 1. I notice a lot of use of the LLVM builder, for example, in
> slot_compile_deform(). Why can't you do the same thing you did with
> function code, where you create the ".bc" at build time from plain C
> cod
On Thursday, January 25, 2018 7:38:16 AM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-24 22:33:30 -0800, Jeff Davis wrote:
> > On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet
wrote:
> > > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only
> > > as a C ++ API in llvm/IR/De
On 24.01.2018 10:20, Andres Freund wrote:
Hi,
I've spent the last weeks working on my LLVM compilation patchset. In
the course of that I *heavily* revised it. While still a good bit away
from committable, it's IMO definitely not a prototype anymore.
There's too many small changes, so I'm only
Hi,
On 2018-01-25 10:00:14 +0100, Pierre Ducroquet wrote:
> I don't know when this would be released,
August-October range.
> but the minimal supported LLVM
> version will have a strong influence on the availability of that feature. If
> today this JIT compiling was released with only LLVM 5/
Hi,
On 2018-01-25 18:40:53 +0300, Konstantin Knizhnik wrote:
> As far as I understand generation of native code is now always done for all
> supported expressions and individually by each backend.
Mostly, yes. It's done "always" done, because there's cost based checks
whether to do so or not.
>
Hi,
I've spent the last weeks working on my LLVM compilation patchset. In
the course of that I *heavily* revised it. While still a good bit away
from committable, it's IMO definitely not a prototype anymore.
Below are results on my system for Q1 TPC-H scale 10 (~13Gb database)
Options
Hi,
Thanks for testing things out!
On 2018-01-26 10:44:24 +0300, Konstantin Knizhnik wrote:
> Also I noticed that parallel execution didsables JIT.
Oh, oops, I broke that recently by moving where the decisition about
whether to jit or not is. There actually is JITing, but only in the
leader.
On 26.01.2018 11:23, Andres Freund wrote:
Hi,
Thanks for testing things out!
Thank you for this work.
One more question: do you have any idea how to profile JITed code?
There is no LLVMOrcRegisterPerf in LLVM 5, so jit_profiling_support
option does nothing.
And without it perf is not able
On Thu, Jan 25, 2018 at 11:20:28AM -0800, Andres Freund wrote:
> On 2018-01-25 18:40:53 +0300, Konstantin Knizhnik wrote:
> > Another question is whether it is sensible to redundantly do
> > expensive work (llvm compilation) in all backends.
>
> Right now we kinda have to, but I really want to get
Hi,
On 2018-01-26 13:06:27 +0300, Konstantin Knizhnik wrote:
> One more question: do you have any idea how to profile JITed code?
Yes ;). It depends a bit on what exactly you want to do. Is it
sufficient to get time associated with the parent caller, or do you need
instruction-level access.
> T
On Wed, Jan 24, 2018 at 11:02 PM, Andres Freund wrote:
> Not entirely sure what you mean. You mean why I don't inline
> slot_getsomeattrs() etc and instead generate code manually? The reason
> is that the generated code is a *lot* smarter due to knowing the
> specific tupledesc.
I would like to
Hi,
On 2018-01-26 18:26:03 -0800, Jeff Davis wrote:
> On Wed, Jan 24, 2018 at 11:02 PM, Andres Freund wrote:
> > Not entirely sure what you mean. You mean why I don't inline
> > slot_getsomeattrs() etc and instead generate code manually? The reason
> > is that the generated code is a *lot* smart
Hi,
On Fri, Jan 26, 2018 at 6:40 PM, Andres Freund wrote:
>> I would like to see if we can get a combination of JIT and LTO to work
>> together to specialize generic code at runtime.
>
> Well, LTO can't quite work. It relies on being able to mark code in
> modules linked together as externally vi
Hi,
On 2018-01-26 22:52:35 -0800, Jeff Davis wrote:
> The version of LLVM that I tried this against had a linker option
> called "InternalizeLinkedSymbols" that would prevent the visibility
> problem you mention (assuming I understand you correctly).
I don't think they're fully solvable - you can
On Sat, Jan 27, 2018 at 1:20 PM, Andres Freund wrote:
> b) The optimizations to take advantage of the constants and make the
>code faster with the constant tupledesc is fairly slow (you pretty
>much need at least an -O2 equivalent), whereas the handrolled tuple
>deforming is faster tha
Hi,
On 2018-01-27 16:56:17 -0800, Jeff Davis wrote:
> On another topic, I'm trying to find a way we could break this patch
> into smaller pieces. For instance, if we concentrate on tuple
> deforming, maybe it would be committable in time for v11?
Yea, I'd planned and started to do so. I actually
On Sat, Jan 27, 2018 at 5:15 PM, Andres Freund wrote:
>> Also, I'm sure you considered this, but I'd like to ask if we can try
>> harder make the JIT itself happen in an extension. It has some pretty
>> huge benefits:
>
> I'm very strongly against this. To the point that I'll not pursue JITing
> f
On Thursday, January 25, 2018 8:12:42 PM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-25 10:00:14 +0100, Pierre Ducroquet wrote:
> > I don't know when this would be released,
>
> August-October range.
>
> > but the minimal supported LLVM
> > version will have a strong influence on the availabil
On Thursday, January 25, 2018 8:02:54 AM CET Andres Freund wrote:
> Hi!
>
> On 2018-01-24 22:51:36 -0800, Jeff Davis wrote:
> > Can we store the bitcode in pg_proc, simplifying deployment and
> > allowing extensions to travel over replication?
>
> Yes, we could. You'd need to be a bit careful tha
Hi,
On 2018-01-27 22:06:59 -0800, Jeff Davis wrote:
> > infeasible because quite freuquently both non-JITed code and JITed code
> > need adjustments. That'd solve your concern about
>
> Can you explain further?
There's already a *lot* of integration points in the patchseries. Error
handling need
Hi,
On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote:
> I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM documentation
> is
> really lacking when it comes to porting from version x to x+1.
> The only really missing part I found is that in 3.9, GlobalValueSummary has
> no
> fla
On Monday, January 29, 2018 10:46:13 AM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote:
> > I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM
> > documentation is really lacking when it comes to porting from version x
> > to x+1.
> > The only re
On 26.01.2018 22:38, Andres Freund wrote:
And without it perf is not able to unwind stack trace for generated
code.
You can work around that by using --call-graph lbr with a sufficiently
new perf. That'll not know function names et al, but at least the parent
will be associated correctly.
W
Hi,
On 2018-01-29 15:45:56 +0300, Konstantin Knizhnik wrote:
> On 26.01.2018 22:38, Andres Freund wrote:
> > And without it perf is not able to unwind stack trace for generated
> > > code.
> > You can work around that by using --call-graph lbr with a sufficiently
> > new perf. That'll not know fun
On Mon, Jan 29, 2018 at 1:36 AM, Andres Freund wrote:
> There's already a *lot* of integration points in the patchseries. Error
> handling needs to happen in parts of code we do not want to make
> extensible, the defintion of expression steps has to exactly match, the
> core code needs to emit the
Hi,
On 2018-01-29 10:28:18 -0800, Jeff Davis wrote:
> OK. How about this: are you open to changes that move us in the
> direction of extensibility later? (By this I do *not* mean imposing a
> bunch of requirements on you... either small changes to your patches
> or something part of another commit
On 01/24/2018 08:20 AM, Andres Freund wrote:
> Hi,
>
> I've spent the last weeks working on my LLVM compilation patchset. In
> the course of that I *heavily* revised it. While still a good bit away
> from committable, it's IMO definitely not a prototype anymore.
>
> There's too many small chang
Hi,
On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
> Hi, I wanted to look at this, but my attempts to build the jit branch
> fail with some compile-time warnings (uninitialized variables) and
> errors (unknown types, incorrect number of arguments). See the file
> attached.
Which git hash are y
On 01/29/2018 10:57 PM, Andres Freund wrote:
> Hi,
>
> On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
>> Hi, I wanted to look at this, but my attempts to build the jit branch
>> fail with some compile-time warnings (uninitialized variables) and
>> errors (unknown types, incorrect number of argu
On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
> On 01/29/2018 10:57 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
> >> Hi, I wanted to look at this, but my attempts to build the jit branch
> >> fail with some compile-time warnings (uninitialized var
On 01/29/2018 11:17 PM, Andres Freund wrote:
> On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
>> On 01/29/2018 10:57 PM, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
Hi, I wanted to look at this, but my attempts to build the jit branch
fail w
Hi,
On 2018-01-29 23:49:14 +0100, Tomas Vondra wrote:
> On 01/29/2018 11:17 PM, Andres Freund wrote:
> > On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
> >> $ llvm-config --version
> >> 5.0.0svn
> >
> > Is thta llvm-config the one in /usr/local/include/ referenced by the
> > error message above
On 01/29/2018 11:49 PM, Tomas Vondra wrote:
>
> ...
>
> and that indeed changes the failure to this:
>
> Writing postgres.bki
> Writing schemapg.h
> Writing postgres.description
> Writing postgres.shdescription
> llvmjit_error.cpp: In function ‘void llvm_enter_fatal_on_oom()’:
> llvmjit_error.c
Hi,
On 2018-01-30 00:16:46 +0100, Tomas Vondra wrote:
> FWIW I've installed llvm 5.0.1 from distribution package, and now
> everything builds fine (I don't even need the configure tweak).
>
> I think I had to build the other binaries because there was no 5.x llvm
> back then, but it's too far bac
Hi,
On Mon, Jan 29, 2018 at 10:40 AM, Andres Freund wrote:
> Hi,
>
> On 2018-01-29 10:28:18 -0800, Jeff Davis wrote:
>> OK. How about this: are you open to changes that move us in the
>> direction of extensibility later? (By this I do *not* mean imposing a
>> bunch of requirements on you... eithe
On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote:
> It's an optional dependency, and it doesn't increase build time that
> much... If we were to move the llvm interfacing code to a .so, there'd
> not even be a packaging issue, you can just package that .so separately
> and get errors if somebo
On Wed, Jan 24, 2018 at 2:20 AM, Andres Freund wrote:
> == Error handling ==
>
> There's two aspects to error handling.
>
> Firstly, generated (LLVM IR) and emitted functions (mmap()ed segments)
> need to be cleaned up both after a successful query execution and after
> an error. I've settled on
Hi,
On 2018-01-30 13:57:50 -0500, Robert Haas wrote:
> > When a libstdc++ new or LLVM error occurs, the handlers set up by the
> > above functions trigger a FATAL error. We have to use FATAL rather than
> > ERROR, as we *cannot* reliably throw ERROR inside a foreign library
> > without risking cor
On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund wrote:
>> That bites, although it's probably tolerable if we expect such errors
>> only in exceptional situations such as a needed shared library failing
>> to load or something. Killing the session when we run out of memory
>> during JIT compilation
Robert Haas writes:
> Unfortunately, that has the pretty significant downside that a lot of
> people who actually want the postgresql-server-jit package will not
> realize that they need to install it, which sucks. But I think it
> might still be the better way to go. Anyway, it's for individua
Hi,
On 2018-01-30 15:06:02 -0500, Robert Haas wrote:
> On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund wrote:
> >> That bites, although it's probably tolerable if we expect such errors
> >> only in exceptional situations such as a needed shared library failing
> >> to load or something. Killing th
On 01/30/2018 12:24 AM, Andres Freund wrote:
> Hi,
>
> On 2018-01-30 00:16:46 +0100, Tomas Vondra wrote:
>> FWIW I've installed llvm 5.0.1 from distribution package, and now
>> everything builds fine (I don't even need the configure tweak).
>>
>> I think I had to build the other binaries because
On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote:
> On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote:
> > It's an optional dependency, and it doesn't increase build time
> > that much... If we were to move the llvm interfacing code to a
> > .so, there'd not even be a packaging issue
Hi,
On 2018-01-30 22:57:06 +0100, David Fetter wrote:
> On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote:
> > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote:
> > > It's an optional dependency, and it doesn't increase build time
> > > that much... If we were to move the llvm inter
Hi,
On 2018-01-30 13:46:37 -0500, Robert Haas wrote:
> On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote:
> > It's an optional dependency, and it doesn't increase build time that
> > much... If we were to move the llvm interfacing code to a .so, there'd
> > not even be a packaging issue, you c
On Tue, Jan 30, 2018 at 02:08:30PM -0800, Andres Freund wrote:
> Hi,
>
> On 2018-01-30 22:57:06 +0100, David Fetter wrote:
> > On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote:
> > > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote:
> > > > It's an optional dependency, and it doesn
> On Jan 30, 2018, at 2:08 PM, Andres Freund wrote:
>
> With things like apt recommends and such I don't think this is a huge problem.
I don’t believe there is a similar widely-supported dependency type in yum/rpm,
though. rpm 4.12 adds support for Weak Dependencies, which have
Recommends/Sug
On Wed, Jan 31, 2018 at 11:57 AM, Andres Freund wrote:
> On 2018-01-30 13:46:37 -0500, Robert Haas wrote:
>> On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote:
>> > It's an optional dependency, and it doesn't increase build time that
>> > much... If we were to move the llvm interfacing code to
On 2018-01-31 14:42:26 +1300, Thomas Munro wrote:
> I'm just starting to look at this (amazing) work, and I don't have a
> strong opinion yet. But certainly, making it easy for packagers to
> put the -jit stuff into a separate package for the reasons already
> given sounds sensible to me. Some sy
On Wed, Jan 31, 2018 at 3:05 PM, Andres Freund wrote:
> On 2018-01-31 14:42:26 +1300, Thomas Munro wrote:
>> I'm just starting to look at this (amazing) work, and I don't have a
>> strong opinion yet. But certainly, making it easy for packagers to
>> put the -jit stuff into a separate package for
Hi,
On 2018-01-31 15:48:09 +1300, Thomas Munro wrote:
> On Wed, Jan 31, 2018 at 3:05 PM, Andres Freund wrote:
> > I'm not quite sure I understand. You mean have it display whether
> > available? I think my plan is to "just" set jit_expressions=on (or
> > whatever we're going to name it) fail if t
On 31.01.2018 05:48, Thomas Munro wrote:
This seems to be a valid complaint. I don't think you should be
(indirectly) wrapping Types.h in extern "C". At a guess, your
llvmjit.h should be doing its own #ifdef __cplusplus'd linkage
specifiers, so you can use it from C or C++, but making sure
On 1/30/18 21:55, Andres Freund wrote:
> I'm open to changing my mind on it, but it seems a bit weird that a
> feature that relies on a shlib being installed magically turns itself on
> if avaible. And leaving that angle aside, ISTM, that it's a complex
> enough feature that it should be opt-in the
On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut
wrote:
> On 1/30/18 21:55, Andres Freund wrote:
>> I'm open to changing my mind on it, but it seems a bit weird that a
>> feature that relies on a shlib being installed magically turns itself on
>> if avaible. And leaving that angle aside, ISTM, t
On Tue, Jan 30, 2018 at 5:57 PM, Andres Freund wrote:
> Given that we need a shared library it'll be best buildsystem wise if
> all of this is in a directory, and there's a separate file containing
> the stubs that call into it.
>
> I'm not quite sure where to put the code. I'm a bit inclined to a
Hi,
On 2018-01-31 11:53:25 -0500, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut
> wrote:
> > On 1/30/18 21:55, Andres Freund wrote:
> >> I'm open to changing my mind on it, but it seems a bit weird that a
> >> feature that relies on a shlib being installed magically turn
Hi,
On 2018-01-31 11:56:59 -0500, Robert Haas wrote:
> On Tue, Jan 30, 2018 at 5:57 PM, Andres Freund wrote:
> > Given that we need a shared library it'll be best buildsystem wise if
> > all of this is in a directory, and there's a separate file containing
> > the stubs that call into it.
> >
> >
On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote:
>> The first one is a problem that's not going to go away. If the
>> problem of JIT being enabled "magically" is something we're concerned
>> about, we need to figure out a good solution, not just disable the
>> feature by default.
>
> That's
On 2018-01-31 14:45:46 -0500, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote:
> >> The first one is a problem that's not going to go away. If the
> >> problem of JIT being enabled "magically" is something we're concerned
> >> about, we need to figure out a good solution
On Wed, Jan 31, 2018 at 2:49 PM, Andres Freund wrote:
>> We could do that, but I'd be more inclined just to let JIT be
>> magically enabled. In general, if a user could do 'yum install ip4r'
>> (for example) and have that Just Work without any further database
>> configuration, I think a lot of p
On 1/31/18 13:34, Andres Freund wrote:
> That's a fair argument, and I don't really have a good answer to it. We
> could have a jit = off/try/on, and use that to signal things? I.e. it
> can be set to try (possibly default in version + 1), and things will
> work if it's not installed, but if set to
On 1/31/18 14:45, Robert Haas wrote:
> We could do that, but I'd be more inclined just to let JIT be
> magically enabled. In general, if a user could do 'yum install ip4r'
> (for example) and have that Just Work without any further database
> configuration,
One way to do that would be to have a s
On 2018-02-01 08:46:08 -0500, Peter Eisentraut wrote:
> On 1/31/18 14:45, Robert Haas wrote:
> > We could do that, but I'd be more inclined just to let JIT be
> > magically enabled. In general, if a user could do 'yum install ip4r'
> > (for example) and have that Just Work without any further data
On Wed, Jan 31, 2018 at 1:45 PM, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote:
>>> The first one is a problem that's not going to go away. If the
>>> problem of JIT being enabled "magically" is something we're concerned
>>> about, we need to figure out a good solutio
On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik
wrote:
> The same problem takes place with old versions of GCC: I have to upgrade GCC
> to 7.2 to make it possible to compile this code.
> The problem in not in compiler itself, but in libc++ headers.
How can I get this branch to compile on ub
On 2018-02-01 09:32:17 -0800, Jeff Davis wrote:
> On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik
> wrote:
> > The same problem takes place with old versions of GCC: I have to upgrade GCC
> > to 7.2 to make it possible to compile this code.
> > The problem in not in compiler itself, but in l
On Fri, Feb 2, 2018 at 2:05 PM, Andres Freund wrote:
> On 2018-02-01 09:32:17 -0800, Jeff Davis wrote:
>> On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik
>> wrote:
>> > The same problem takes place with old versions of GCC: I have to upgrade
>> > GCC
>> > to 7.2 to make it possible to comp
Another small thing which might be environmental... llvmjit_types.bc
is getting installed into ${prefix}/lib here, but you're looking for
it in ${prefix}/lib/postgresql:
gmake[3]: Entering directory '/usr/home/munro/projects/postgres/src/backend/lib'
/usr/bin/install -c -m 644 llvmjit_types.bc '/h
On Fri, Feb 2, 2018 at 5:11 PM, Thomas Munro
wrote:
> Another small thing which might be environmental... llvmjit_types.bc
> is getting installed into ${prefix}/lib here, but you're looking for
> it in ${prefix}/lib/postgresql:
Is there something broken about my installation? I see simple
arithm
On Thu, Feb 1, 2018 at 5:05 PM, Andres Freund wrote:
> Just to understand: You're running in the issue with the header being
> included from within the extern "C" {}? Hm, I've pushed a quick fix for
> that.
>
> Other than that, you can compile with both gcc or clang, but clang needs
> to be avail
On Fri, Feb 2, 2018 at 7:06 PM, Jeff Davis wrote:
> /usr/include/c++/5/cmath:505:22: error: conflicting declaration of C
> function ‘long double
> ...
> /usr/include/c++/5/cmath:926:3: error: template with C linkage
I suspect you can fix these with this change:
+#ifdef __cplusplus
+}
+#endif
#i
On Thu, Feb 1, 2018 at 10:09 PM, Thomas Munro
wrote:
> On Fri, Feb 2, 2018 at 7:06 PM, Jeff Davis wrote:
>> /usr/include/c++/5/cmath:505:22: error: conflicting declaration of C
>> function ‘long double
>> ...
>> /usr/include/c++/5/cmath:926:3: error: template with C linkage
>
> I suspect you can
Hi,
On 2018-02-02 18:22:34 +1300, Thomas Munro wrote:
> Is there something broken about my installation? I see simple
> arithmetic expressions apparently compiling and working but I can
> easily find stuff that breaks... so far I think it's anything
> involving string literals:
That definitely s
On 2018-02-01 22:20:01 -0800, Jeff Davis wrote:
> Thanks! That worked, but I had to remove the "-stdlib=libc++" also,
> which was causing me problems.
That'll be gone as soon as I finish the shlib thing. Will hope to have
something over the weekend. Right now I'm at FOSDEM and need to prepare
a ta
Hi,
On 2018-02-02 18:22:34 +1300, Thomas Munro wrote:
> The clang that was used for bitcode was the system /usr/bin/clang,
> version 4.0. Is it a problem that I used that for compiling the
> bitcode, but LLVM5 for JIT? I actually tried
> CLANG=/usr/local/llvm50/bin/clang but ran into weird failu
On Thu, Feb 1, 2018 at 8:16 PM, Thomas Munro
wrote:
> On Fri, Feb 2, 2018 at 2:05 PM, Andres Freund wrote:
>> On 2018-02-01 09:32:17 -0800, Jeff Davis wrote:
>>> On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik
>>> wrote:
>>> > The same problem takes place with old versions of GCC: I have t
On 2018-02-09 09:10:25 -0600, Merlin Moncure wrote:
> Question: when watching the compilation log, I see quite a few files
> being compiled with both O2 and O1, for example:
>
> clang -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels
> -Wmissing-format-attr
On Wed, Jan 31, 2018 at 8:53 AM, Robert Haas wrote:
> As far as the second one, looking back at what happened with parallel
> query, I found (on a quick read) 13 back-patched commits in
> REL9_6_STABLE prior to the release of 10.0, 3 of which I would qualify
> as low-importance (improving document
On Thu, Jan 25, 2018 at 9:40 AM, Konstantin Knizhnik
wrote:
> As far as I understand generation of native code is now always done for all
> supported expressions and individually by each backend.
> I wonder it will be useful to do more efforts to understand when compilation
> to native code should
On Sun, Feb 11, 2018 at 10:00 AM, Merlin Moncure wrote:
> I tested several queries in my application that had >30 second compile
> times against a one second run time,. Not being able to manage when
> compilation happens is making it difficult to get a sense of llvm
> performance in the general c
On 2018-02-13 13:43:40 -0500, Robert Haas wrote:
> On Sun, Feb 11, 2018 at 10:00 AM, Merlin Moncure wrote:
> > I tested several queries in my application that had >30 second compile
> > times against a one second run time,. Not being able to manage when
> > compilation happens is making it diffic
On Wednesday, January 24, 2018 8:20:38 AM CET Andres Freund wrote:
> As the patchset is large (500kb) and I'm still quickly evolving it, I do
> not yet want to attach it. The git tree is at
> https://git.postgresql.org/git/users/andresfreund/postgres.git
> in the jit branch
>
> https://git.post
Hi,
On 2018-01-24 22:35:08 +0100, Pierre Ducroquet wrote:
> I tried to build on Debian sid, using GCC 7 and LLVM 5. I used the following
> to compile, using your branch @3195c2821d :
Thanks!
> $ export LLVM_CONFIG=/usr/bin/llvm-config-5.0
> $ ./configure --with-llvm
> $ make
>
> And I had the
Hi,
On 2018-01-24 14:06:30 -0800, Andres Freund wrote:
> > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as
> > a C
> > ++ API in llvm/IR/DebugInfo.h.
>
> Hm, I compiled against 5.0 quite recently, but added the stripping of
> debuginfo lateron. I'll add a fallback met
On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet wrote:
> In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as a C
> ++ API in llvm/IR/DebugInfo.h.
The LLVM APIs don't seem to be very stable; won't there just be a
continuous stream of similar issues?
Pinning major postgres
Hi,
On 2018-01-24 22:33:30 -0800, Jeff Davis wrote:
> On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet wrote:
> > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as
> > a C
> > ++ API in llvm/IR/DebugInfo.h.
>
> The LLVM APIs don't seem to be very stable; won't there ju
On Tue, Jan 23, 2018 at 11:20 PM, Andres Freund wrote:
> Hi,
>
> I've spent the last weeks working on my LLVM compilation patchset. In
> the course of that I *heavily* revised it. While still a good bit away
> from committable, it's IMO definitely not a prototype anymore.
Great!
A couple high-le
Hi!
On 2018-01-24 22:51:36 -0800, Jeff Davis wrote:
> A couple high-level questions:
>
> 1. I notice a lot of use of the LLVM builder, for example, in
> slot_compile_deform(). Why can't you do the same thing you did with
> function code, where you create the ".bc" at build time from plain C
> cod
On Thursday, January 25, 2018 7:38:16 AM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-24 22:33:30 -0800, Jeff Davis wrote:
> > On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet
wrote:
> > > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only
> > > as a C ++ API in llvm/IR/De
On 24.01.2018 10:20, Andres Freund wrote:
Hi,
I've spent the last weeks working on my LLVM compilation patchset. In
the course of that I *heavily* revised it. While still a good bit away
from committable, it's IMO definitely not a prototype anymore.
There's too many small changes, so I'm only
Hi,
On 2018-01-25 10:00:14 +0100, Pierre Ducroquet wrote:
> I don't know when this would be released,
August-October range.
> but the minimal supported LLVM
> version will have a strong influence on the availability of that feature. If
> today this JIT compiling was released with only LLVM 5/
Hi,
On 2018-01-25 18:40:53 +0300, Konstantin Knizhnik wrote:
> As far as I understand generation of native code is now always done for all
> supported expressions and individually by each backend.
Mostly, yes. It's done "always" done, because there's cost based checks
whether to do so or not.
>
1 - 100 of 176 matches
Mail list logo