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 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 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 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 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 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
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 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:
> 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 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
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 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 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
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 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
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 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 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 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 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 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 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 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 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
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.
> >
> >
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
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
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 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 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
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 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
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 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 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 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
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
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
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
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
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
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
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
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 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
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
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
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
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-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: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
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 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
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/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 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 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 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 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
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
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
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
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
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 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
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 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-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
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 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
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 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 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
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
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.
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,
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,
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/
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
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
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 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: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 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 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
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
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,
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
88 matches
Mail list logo