Added a Bye project in examples/
Fixed linking of plugins into core tools
Fixed dependency issue

Fix test requires + asan calls

@chandlerc any chance you could have a look at this?

Update test according to @kcc remark.

LGTM then, please get another feedback though, I'm not comfortable with that code area

@vitalybuka / @kcc : up?

Following @yln question, improve the CHECK of the associated test case

• Test added
• Comment added
• make the change more localized, closer to the origin of the issue

check-asan works just fine

@kcc tested on the bug test case and it now raises a decent error, not tested on compiler-rt test suite (yet)

@Meinersbur your comment and my devs crossed, but this should be fine. This update enables new PM static plugin support for clang, something that was lacking to polly previously. I've tested it a bit and it builds fine with static setup, still need to test it with more config.

@mehdi_amini up ;-)

Thanks @jkorous for the fast review o/

Mostly documentation update + helper function renaming.

LGTM. Can you add a test case in lit/tests for that?

@beanz : In addition to your suggested changes, I've renamed the cmake utility into add_llvm_pass_plugin to match other functions from AddLLVM.cmake

Using @beanz idea, provide an option to add_llvm_executable to declare it as receiving plugins, which provides lower coupling with actual plugins

In D61446#1532848, @Meinersbur wrote:

Just an idea: We could avoid the explicit calls to 'initializeXYZPass' in opt/bugpoint/clang by adding Polly.cpp as a source file or object library to the executables. This would guarantee that its static initializer is called without dynamic library.

@Meinersbur Itested with the following configuration

• do not set category for positional argument

remove category of positional argument

@mehdi_amini up :-)

• get Rid of the constraint on initializePasses : it can be registered suing a static constructor, no need to clutter the API with it

• make it possible for client code to speicify the registration function for new PM, thanks @philip.pfaffe for the hint. @Meinersbur this should be ok now.

Take into account @philip.pfaffe remarks and improve support for new PM.

@beanz turns out the depdendency problem was just a matter of moving the register_llvm_extension call at the top of the file.

@philip.pfaffe : NewPM integeration actually works thanks to `Register${Name}Passes(llvm::PassBuilder &PB)`. It's already used by Polly for NewPM integration and we mimic that.

• reorder registration to make sure options are correctly taken into account
• make LINK_POLLY_INTO_TOOLS obsolete in favor of just using LLVM_LINK_POLLY_INTO_TOOLS

Update comment + force reduced memory consumption.

• provide minimal documentation
• fix testing configuration
• validate locally with both shared and static libraries, using monorepo or tool layout
• update sample https://sergesanspaille.fedorapeople.org/bye.tgz

LGTM

I wonder if the LTO pass pipeline shouldn't honor the existing EP_EarlyAsPossible extension point?

Diff updated with context

@mehdi_amini up :-)

@kwk: looks like you're still compiling with clang-7, this patch is to be applied on the master version of LLVM/clang, then you can install it and use it to recompile llvm/lld with coverage info.

For reference, the output before filtering (but after categorization)

For reference, unfiltered output:

LGTM with respect to Python 2/3 compat, can't tell for the functionality though.

@Meinersbur up!

@jhenderson , @ddunbar : I've checked the callgraph of llvm-as, and none of theses flags are actually reachable:

@Meinersbur thanks a lot for the feedback. I was only testing with the new project layout, so it's nice you tested with the legacy layout.
I've updated the diff accordingly, it now compiles fine on my Linux box with both old-style and new-style layout.

Following a remark from @jhenderson , and in order to make sure the options filtered out are not relevant, I've been running a clang-based script to compute the application callgraph, registering all calls to `llvm::cl` commands and their parent.

For reference, toe output of -help with and without filtering:

Therefore, I recommend removing the SubCommand parameter from this API and always using cl::TopLevelSubCommand.

@hintonda / @beanz : I've been thinking about this, and I'm now convinced that this review is probably not the good approach. What we need is a good way to track which options are actually important for a given binary, correctly set the categories of each option and *reallyhide* the others. So I'll pause this review and start working on sanitizing the output of several tools until I get a better understanding of the actual API needs.

@beanz

I expect that we will want to use cl::HideUnrelatedOptions in a lot more places to clean up other tool help messages.

That's indeed the plan.

@lebedev.ri doc updated.

Updated with clang-formated diff

@hintonda I've updated the patch taking your advices into account. I took a step ahead and applied the non-conservative signature change for cl::HideUnrelatedOptions

@hintonda this looks better that way, for sure.

It was added in D7100, and I think the rational was to hide implementation details.