[GitHub] Add description to llvm::instcombine label to cover instsimplify / vectorcombine as well

[RKSimon]

CC @nikic @dtcxzyw

As explained here: https://llvm.org/docs/InstCombineContributorGuide.html#pick-the-correct-optimization-pass

Would it be OK to use the github label llvm::InstCombine to refer to the sibling passes as well:

    InstructionSimplify: For folds that do not create new instructions (either fold to existing value or constant).
    InstCombine: For folds that create or modify instructions.
    AggressiveInstCombine: For folds that are expensive, or violate InstCombine requirements.
    VectorCombine: For folds of vector operations that require target-dependent cost-modelling.

or would you prefer they all have separate labels?

The doc also refers to:

    ConstantFolding: For folding instructions with constant arguments to a constant. (Mainly relevant for intrinsics.)
    ValueTracking: For analyzing instructions, e.g. for known bits, non-zero, etc. Tests should usually use -passes=instsimplify.

But these probably should use the llvm::analysis label?

[nikic]

For PRs we already cover InstSimplify:

llvm-project/.github/new-prs-labeler.yml

Lines 627 to 633 in 529662a

	llvm:instcombine:
	- llvm/lib/Analysis/InstructionSimplify.cpp
	- llvm/lib/Transforms/InstCombine/**
	- llvm/include/llvm/Transforms/InstCombine/
	- llvm/include/llvm/Analysis/InstructionSimplify.h
	- llvm/test/Transforms/InstCombine/**
	- llvm/test/Transforms/InstSimplify/**

We should probably also cover AggressiveInstCombine.

I'm less sure about VectorCombine -- I think that one is a bit different and mostly maintained by other people than InstCombine. But no strong opinion either way.

[RKSimon]

OK - we can add a llvm::vectorcombine label easily enough - I'll add a llvm::instcombine description covering InstCombine/InstSimplify/AggressiveInstCombine