D26399: [ELF] - Implemented -stats command line option.

Davide Italiano via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 8 23:48:35 PST 2016


On Tue, Nov 8, 2016 at 11:22 PM, George Rimar <grimar at accesssoftek.com> wrote:
>>davide added a comment.
>>
>>ehm, do you know what they use this for? It's supposed to be a debug only options, it shouldn't ship in any release.
>
> No, I don't know. But that definetely is a reason of fail for me:
>
> linking ../lib/libtinfo.so.6.0
> cc -O2 -pipe  -fstack-protector -fno-strict-aliasing  --param max-inline-insns-single=1200 -shared -Wl,-soname,`basename ../lib/libtinfo.so.6.0 .6.0`.6,-stats,-lc -o ../lib/libtinfo.so.6.0 -Wl,-rpath,/usr/local/lib ../obj_s/access.o  ../obj_s/add_tries.o  ../obj_s/alloc_ttype.o  ../obj_s/codes.o  ../obj_s/comp_captab.o  ../obj_s/comp_error.o  ../obj_s/comp_hash.o  ../obj_s/db_iterator.o  ../obj_s/doalloc.o  ../obj_s/entries.o  ../obj_s/fallback.o  ../obj_s/free_ttype.o  ../obj_s/getenv_num.o  ../obj_s/home_terminfo.o  ../obj_s/init_keytry.o  ../obj_s/lib_acs.o  ../obj_s/lib_baudrate.o  ../obj_s/lib_cur_term.o  ../obj_s/lib_data.o  ../obj_s/lib_has_cap.o  ../obj_s/lib_kernel.o  ../obj_s/lib_keyname.o  ../obj_s/lib_longname.o  ../obj_s/lib_napms.o  ../obj_s/lib_options.o  ../obj_s/lib_raw.o  ../obj_s/lib_setup.o  ../obj_s/lib_termcap.o  ../obj_s/lib_termname.o  ../obj_s/lib_tgoto.o  ../obj_s/lib_ti.o  ../obj_s/lib_tparm.o  ../obj_s/lib_tputs.o  ../obj_s/lib_trace.o  ../obj_s/lib_ttyflags.o  ../obj_s/lib_twait.o  ../obj_s/name_match.o  ../obj_s/names.o  ../obj_s/obsolete.o  ../obj_s/read_entry.o  ../obj_s/read_termcap.o  ../obj_s/strings.o  ../obj_s/tries.o  ../obj_s/trim_sgr0.o  ../obj_s/unctrl.o  ../obj_s/visbuf.o  ../obj_s/alloc_entry.o  ../obj_s/captoinfo.o  ../obj_s/comp_expand.o  ../obj_s/comp_parse.o  ../obj_s/comp_scan.o  ../obj_s/parse_entry.o  ../obj_s/write_entry.o  ../obj_s/define_key.o  ../obj_s/hashed_db.o  ../obj_s/key_defined.o  ../obj_s/keybound.o  ../obj_s/keyok.o  ../obj_s/version.o -L../lib -fstack-protector
> /usr/bin/ld: error: unknown argument: -stats
>
> So if we do not want to implement something under -stats, we can try to ignore that flag and retest.

I think ignoring is the best option in this case.

My take is that the output of --stats is too vague to be useful.
Also, please note that this is supposed to be a release build and
--stats should be disabled (I think it should be enabled only for
"developers mode" as users generally cannot care less about exact link
times).

And from a developer point of view, sure, you get link time, but it
doesn't give you any additional information to draw any conclusion
out.

If people miss the feature and open a bug upstream, we should consider
making it more "interesting". That is, we could support something like
opt/clang `-ftime-report` where we have a breakdown so that it's easy
to understand where cycles are spent (reading input files/symbol
resolution/parsing linker script/you name it).

tl;dr: compatibility for debugging options is not something I would
pursue. Compatibility for the output format, even less so.

My $0.02,

--
Davide


More information about the llvm-commits mailing list