Correct some typos in the new JIT code.

Author: Thomas Munro
This commit is contained in:
Andres Freund 2018-03-26 12:58:17 -07:00
parent 32af96b2b1
commit 96b5eac918
4 changed files with 12 additions and 12 deletions

View File

@ -247,7 +247,7 @@ llvm_get_function(LLVMJitContext *context, const char *funcname)
/*
* If there is a pending / not emitted module, compile and emit now.
* Otherwise we migh not find the [correct] function.
* Otherwise we might not find the [correct] function.
*/
if (!context->compiled)
{
@ -266,7 +266,7 @@ llvm_get_function(LLVMJitContext *context, const char *funcname)
addr = 0;
if (LLVMOrcGetSymbolAddressIn(handle->stack, &addr, handle->orc_handle, funcname))
elog(ERROR, "failed to lookup symbol \"%s\"", funcname);
elog(ERROR, "failed to look up symbol \"%s\"", funcname);
if (addr)
return (void *) (uintptr_t) addr;
}
@ -280,11 +280,11 @@ llvm_get_function(LLVMJitContext *context, const char *funcname)
return (void *) (uintptr_t) addr;
#else
if (LLVMOrcGetSymbolAddress(llvm_opt0_orc, &addr, funcname))
elog(ERROR, "failed to lookup symbol \"%s\"", funcname);
elog(ERROR, "failed to look up symbol \"%s\"", funcname);
if (addr)
return (void *) (uintptr_t) addr;
if (LLVMOrcGetSymbolAddress(llvm_opt3_orc, &addr, funcname))
elog(ERROR, "failed to lookup symbol \"%s\"", funcname);
elog(ERROR, "failed to look up symbol \"%s\"", funcname);
if (addr)
return (void *) (uintptr_t) addr;
#endif /* LLVM_VERSION_MAJOR */
@ -540,7 +540,7 @@ llvm_compile_module(LLVMJitContext *context)
if (LLVMOrcAddEagerlyCompiledIR(compile_orc, &orc_handle, smod,
llvm_resolve_symbol, NULL))
{
elog(ERROR, "failed to jit module");
elog(ERROR, "failed to JIT module");
}
LLVMOrcDisposeSharedModuleRef(smod);
}
@ -847,7 +847,7 @@ llvm_resolve_symbol(const char *symname, void *ctx)
char *modname;
/*
* OSX prefixes all object level symbols with an underscore. But neither
* macOS prefixes all object level symbols with an underscore. But neither
* dlsym() nor PG's inliner expect that. So undo.
*/
#if defined(__darwin__)

View File

@ -4,7 +4,7 @@
* LLVM error related handling that requires interfacing with C++
*
* Unfortunately neither (re)setting the C++ new handler, nor the LLVM OOM
* handler are exposed to C. Therefore this file wraps the necesary code.
* handler are exposed to C. Therefore this file wraps the necessary code.
*
* Copyright (c) 2016-2018, PostgreSQL Global Development Group
*
@ -39,12 +39,12 @@ static void fatal_llvm_error_handler(void *user_data, const std::string& reason,
*
* This is necessary for LLVM as LLVM's error handling for such cases
* (exit()ing, throwing std::bad_alloc() if compiled with exceptions, abort())
* isn't compatible with postgres error handling. Thus in section where LLVM
* isn't compatible with postgres error handling. Thus in sections where LLVM
* code, not LLVM generated functions!, is executing, standard new, LLVM OOM
* and LLVM fatal errors (some OOM errors masquerade as those) are redirected
* to our own error handlers.
*
* These error handlers FATAL, because there's no reliable way from within
* These error handlers use FATAL, because there's no reliable way from within
* LLVM to throw an error that's guaranteed not to corrupt LLVM's state.
*
* To avoid disturbing extensions using C++ and/or LLVM, these handlers are

View File

@ -1984,7 +1984,7 @@ llvm_compile_expr(ExprState *state)
isnull;
/*
* At this point aggref->aggno is not yet set (it's setup
* At this point aggref->aggno is not yet set (it's set up
* in ExecInitAgg() after initializing the expression). So
* load it from memory each time round.
*/
@ -2020,7 +2020,7 @@ llvm_compile_expr(ExprState *state)
/*
* At this point aggref->wfuncno is not yet set (it's
* setup in ExecInitWindowAgg() after initializing the
* set up in ExecInitWindowAgg() after initializing the
* expression). So load it from memory each time round.
*/
v_wfuncnop = l_ptr_const(&wfunc->wfuncno,

View File

@ -8,7 +8,7 @@
* low chance of definitions getting out of sync, this file lists types and
* functions that directly need to be accessed from LLVM.
*
* When LlVM is first used in a backend, a bitcode version of this file, will
* When LLVM is first used in a backend, a bitcode version of this file will
* be loaded. The needed types and signatures will be stored into Struct*,
* Type*, Func* variables.
*