Tim Armstrong has posted comments on this change. Change subject: IMPALA-4302,IMPALA-2379: constant expr arg fixes ......................................................................
Patch Set 4: (11 comments) http://gerrit.cloudera.org:8080/#/c/4838/4//COMMIT_MSG Commit Message: Line 18: arguments for ScalarFnCall expressions on both the codegen'd and > missing words Done PS4, Line 36: temporary > automatic? at least I would have understood this a little quicker with tha Done http://gerrit.cloudera.org:8080/#/c/4838/4/be/src/exprs/agg-fn-evaluator.cc File be/src/exprs/agg-fn-evaluator.cc: PS4, Line 158: ", > is it worth differentiating these messages to make debugging easier? Can't hurt. http://gerrit.cloudera.org:8080/#/c/4838/4/be/src/exprs/anyval-util.h File be/src/exprs/anyval-util.h: PS4, Line 297: The returned AnyVal is not initialized. > this sentence is repeated Done http://gerrit.cloudera.org:8080/#/c/4838/4/be/src/exprs/expr-context.h File be/src/exprs/expr-context.h: PS4, Line 66: fragment > do you mean fragment instance? It's kind-of unclear what the direction here is. There's a FRAGMENT_LOCAL concept in the udf interface that this corresponds to, so I think this is consistent at the moment (although maybe it should be FRAGMENT_INSTANCE_LOCAL everywhere). http://gerrit.cloudera.org:8080/#/c/4838/4/be/src/exprs/scalar-fn-call.cc File be/src/exprs/scalar-fn-call.cc: PS4, Line 188: fragment > fragment or fragment instance? Reworded to avoid making the distinction and be clearer. It's not clear that the FRAGMENT_LOCAL terminology is accurate, but I think that's out of scope for this fix. PS4, Line 189: cases > not sure what this sentence is saying. what cases? Reworded to be clearer. It's copied when the ExprContext is cloned. Line 205: // children. > do we document the calling convention somewhere? I think a brief explanatio Updated the comment. The UDF calling convention is in udf/udf.h and the contents of the buffers are in udf/udf-internal.h PS4, Line 340: optimise out the buffer > is this also enabling constant propagation for constant args, or was that a The constant was propagated but the side-effect of storing to the varargs buffer couldn't be optimised out. PS4, Line 370: Either no varargs or arguments before varargs begin > this comment seems unnecessary with the new conditional Done http://gerrit.cloudera.org:8080/#/c/4838/4/be/src/runtime/free-pool.h File be/src/runtime/free-pool.h: Line 73: size = std::max<int64_t>(8, size); > seems fine, but why is it required? Not required but it's pointless making smaller allocations, since it's aligned to 8 bytes by the MemPool anyway. Added a comment -- To view, visit http://gerrit.cloudera.org:8080/4838 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I45c3ed8c9d7a61e94a9b9d6c316e8a53d9ff6c24 Gerrit-PatchSet: 4 Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-Owner: Tim Armstrong <tarmstr...@cloudera.com> Gerrit-Reviewer: Dan Hecht <dhe...@cloudera.com> Gerrit-Reviewer: Michael Ho Gerrit-Reviewer: Tim Armstrong <tarmstr...@cloudera.com> Gerrit-HasComments: Yes
