Re: JIT compiling with LLVM v12.2
От | Andres Freund |
---|---|
Тема | Re: JIT compiling with LLVM v12.2 |
Дата | |
Msg-id | 20180326200130.24kngwbw2qe4vge5@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: JIT compiling with LLVM v12.2 (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: JIT compiling with LLVM v12.2
|
Список | pgsql-hackers |
Hi, On 2018-03-25 00:07:11 +1300, Thomas Munro wrote: > I spotted a couple of typos and some very minor coding details -- see > please see attached. Thanks, applying 0001 in a bit. > From 648e303072c77e781eca2bb06f488f6be9ccac84 Mon Sep 17 00:00:00 2001 > From: Thomas Munro <thomas.munro@enterprisedb.com> > Date: Sat, 24 Mar 2018 23:12:40 +1300 > Subject: [PATCH 2/2] Minor code cleanup for llvmjit_wrap.cpp. > > llvm::sys::getHostCPUName()'s result is a llvm::StringRef. Its data() member > function doesn't guarantee a null-terminated result, so we'd better jump > through an extra hoop to get a C string. Hm, I checked, and it's fine, I'm not enthusiastic about this... > It seems better to use LLVMCreateMessage() rather than strdup() to allocate > the copy returned by LLVMGetHostCPUFeatures() and LLVMGetHostCPUName(), > since the contract is that the caller should free it with > LLVMDisposeMessage(). While we can see that LLVMCreateMessage() and > LLVMDisposeMessage() are currently just wrappers for strdup() and free(), > using them symmetrically seems like a good idea for future Windows support, > where DLLs can be using different heap allocators (the same reason we provide > PQfreemem in libpq). I just kept it similar to nearby functions in the LLVM code. > Fix brace style. I tried to keep this as it's submitted to LLVM, I hope we can get rid of them for newer version soon... I think I'll update them to be exactly the same as soon as the upstream patch is applied. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: