search for: parse_type

...e symbols in LLVM identically to the current demangler. It also provides a significant performance improvement: it demangles the symbols in LLVM about 3.7 times faster than the current demangler. Also, separating the formatting code from the parser reduces stack usage (the activation frame for parse_type reduced from 416 to 144 bytes on my machine). The stack usage is still pretty bad, but this helps with some of it. Does anyone have any early feedback on the patch? Does this seem like a good direction for the demangler? As far as future plans for this file, I have a few more refactorings and...

...o the current > demangler. It also provides a significant performance improvement: > it demangles the symbols in LLVM about 3.7 times faster than the > current demangler. Also, separating the formatting code from the > parser reduces stack usage (the activation frame for parse_type > reduced from 416 to 144 bytes on my machine). The stack usage is > still pretty bad, but this helps with some of it. > > Does anyone have any early feedback on the patch? Does this seem > like a good direction for the demangler? > > As far as future plans...

On Thu, Sep 3, 2015 at 6:45 PM, Kostya Serebryany <kcc at google.com> wrote: > Did you build the Postgres code with -fsanitize-coverage=... ? Yes: CC = clang CFLAGS = -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -g -O0 -fsanitize=address

...o the current >> demangler. It also provides a significant performance improvement: it >> demangles the symbols in LLVM about 3.7 times faster than the current >> demangler. Also, separating the formatting code from the parser reduces >> stack usage (the activation frame for parse_type reduced from 416 to 144 >> bytes on my machine). The stack usage is still pretty bad, but this helps >> with some of it. >> >> Does anyone have any early feedback on the patch? Does this seem like a >> good direction for the demangler? >> >> As far as futur...

...up.o parser/parser.o parser/parse_agg.o > parser/parse_clause.o parser/parse_coerce.o parser/parse_collate.o > parser/parse_cte.o parser/parse_expr.o parser/parse_func.o > parser/parse_node.o parser/parse_oper.o parser/parse_param.o > parser/parse_relation.o parser/parse_target.o parser/parse_type.o > parser/parse_utilcmd.o parser/scansup.o commands/aggregatecmds.o > commands/alter.o commands/analyze.o commands/async.o > commands/cluster.o commands/comment.o commands/collationcmds.o > commands/constraint.o commands/conversioncmds.o commands/copy.o > commands/createas.o command...