Oh, yep, I got it.

• Replace pass before BranchRelaxation

• Upstream review fixes(2)

Gently ping

• Upstream review fixes

Gentle ping

• Fix typo

Gentle ping

Gentle ping

• [SeparateConstOffsetFromGEP] Fix ignoring condition

Maybe you could take a look at one big regression in MicroBenchmarks/LCALS/SubsetALambdaLoops/lcalsALambda.test:BM_PRESSURE_CALC_LAMBDA/5001

The results for X86

Tests: 2900
Short Running: 2325 (filtered out)
Remaining: 575
Metric: exec_time

Ok, I got your concerns about flag, I've checked the test-suite results also on X86 (they are attached below). There was no real regressions. Microbenchmarks results that are in top of regressions aren't reproducable and on other runs I've made they have another result. Of course, I have no opportunity to check all backends.

• [InstCombiner][Test] Removed flag from test

• [InstCombiner] Removed flag to turn off the new type of canonization

Ping

I decided to make flag turned off by default, because even if SeparateConstOffsetFromGEP doesn't change anything EarlyCSE and LICM can change and this isn't always useful.

We already have an implementation of this general transform -- shouldn't it be sufficient to relax only this condition? https://github.com/llvm/llvm-project/blob/7dc18a62e40e241019ec77e70f01bc41d39ab748/llvm/lib/Transforms/InstCombine/InstCombinePHI.cpp#L537 (At least for the basic case.)

I added this under the flag and run subset of test-suite with flag turned on.
The comparasion results are in cycles (got by perf).

@nikic, thank you! I've rewritten this modification in InstCombine.

[InstCombiner] Add option to replace PHI of GEPs with GEP with PHI as index

• Added Scalar to CMakeLists
• [RISCV] Turn off SeparateConstOffsetFromGEP by default

Fix review

Refactoring

• [SimplifyCFG] Added flag to control creation of PHI nodes with entity elements

• [SimplifyCFG] Added flag to control creation of PHI nodes with entity elements

• [SeparateConstOffsetFromGEP] Fix comparator for map with GEP bases

Run one more time benchmarks from test-suite.

• Added Scalar to CMakeLists

Are you seeing any instances of worse code in any of the tests / benchmarks you're looking at?

Now clang for RISC-V doesn't use offset addressing in generated assembly. Example from Dhrystone

 addiw   a0, s1, 5
 slli    a1, a0, 0x2
 add     a2, s4, a1
 sw      s2, 0(a2)
 addiw   a3, s1, 6
 slli    a3, a3, 0x2
 add     a3, a3, s4
 sw      s2, 0(a3)
 addiw   a3, s1, 35
 slli    a3, a3, 0x2
add     a3, a3, s4
sw      a0, 0(a3)

It's inefficient because we can use offsets.
Adding this pass allows to generate the next code

    addiw   a4, a2, 5
    slli    a5, a2, 2
    add a0, a0, a5
    sw  a3, 20(a0)
    sw  a3, 24(a0)
    sw  a4, 140(a0)
...

SeparateConstOffsetFromGEPPass is used to solve this problem in targets with limited addressing modes.

Separate part with pass modification

This should be two patches, one changing the pass and one enabling for RISC-V.

Sorry, I had to provide the context at the beginning.

Rebased against precommited tests

Rebased against precommited tests

In D53565#1298612, @homerdin wrote:

I tried out -DTEST_SUITE_SUBDIRS=SingleSource/Benchmarks/Misc. It gets the desired smaller build tree, but ends up missing lit.local.cfg in SingleSouce so the tests fail.

Please, could someone review these changes?
Or may be add other reviewers if I choose wrong people?

In D22501#551507, @alexfh wrote:

This patch brings up a number of questions:

1. What's your use case? Optimizing tests by replacing a known number of check lines with repeated patterns? Or is the number of patterns you expect not known in advance?

Both first and second case.

2. Are there possible usages of this feature in LLVM tests already?

I don't know LLVM tests well to answer this question.

3. How is this going to interact with [[@LINE]]?

I used FileCheck Match function in loop, so it will be real LINE value. I don't change matching.

There is problem with STL, their realization of regular expressions doesn't match start and end of line in basic mode and there is no multiline mode. There is the issue 2343 in http://cplusplus.github.io/LWG/lwg-toc.html.
There is opportunity to split text by lines and match each line separately, but I think this is a hack, and I think it'll slow FileCheck.

Ok, I'll try to use STL regex.

Patch without modifiers for pattern parameters and using pattern and variables inside definition of other patterns.

As I understood most of users prefer to change library to have support of \b assert. But, I think, this decision is quite important and can be made only by he contributor of FileCheck. I don't know how this suggestion can be done. Or I can try to change library and create a patch with this changes?

What are our options with the regex library? Is there a newer version of the one we are currently using that we could upgrade to (and that supports \b)?

Are quotes necessary for parameters? Everything is string in FileCheck.
Using patterns and variables was in old grammer. I thought that we only change syntax, so I added this feature too.
Ok, I'll remove this from this patch. But then I want to add using patterns and variables in definitions later. On my opinion these features are quite useful.

Change syntax to new one suggested by Vedant Kumar.

In D22353#535691, @alexfh wrote:

Why not add more words to check lines to make them more strict? BTW, does FileCheck support {{\b}}?

In D22403#491468, @aprantl wrote:

They are also both placeholders for a pattern. Can you give an example where it is useful to tell the difference between a use of a pattern and a use of a plain old variable? Does it make the test more readable?
I'm not saying that we have to share the syntax, but adding more syntax increases the cognitive load on testcase authors and we should make sure we are doing it for the right reasons.

I made new mode and made experiment turned it on for all LLVM tests.
Result:

Expected Passes    : 15810
Expected Failures  : 125
Unsupported Tests  : 195
Unexpected Passes  : 4
Unexpected Failures: 1128

Replace set of new CHECK directives to new -check-word option

In D22403#489895, @aprantl wrote:

Is there a benefit in (or need for) distinguishing between variable uses and pattern uses, or could we piggyback the existing syntax?

There is difference between patterns and variables so we should understand where variable is, where pattern is.

As for pattern variables, I really think this review would benefit if we could split out pattern variables into a separate review. I didn't yet understand how pattern variables are supposed to work: Is \:(variable)\=(value) supposed to be an argument to a pattern use that immediately precedes it? Or is it modifying global state similar to regular variable definition in FileCheck? If the latter is the case, why does it come after the pattern in the example? In the former case, wouldn't it be better to have syntax that looks more like passing in an argument?

There is a suggestion to add new option, which will change standart behaviour to word-matchinf instead of addding new set of CHECKs directives. What about this idea?

About syntax.
There is an idea to do as you advised.
Suggested new syntax:
[['#template_name]] - use of template 'template_name'. It can occur in CHECK-PATTERN line, when description of one template includes other templates described before. (Without quote, I don't know how escape # here)
[[:Variable_name]] - template variable with name 'variable_name'
[[:variable_name=value]] - current value of template variable(it's needed when you use template with variables).
Is this syntax better? Should I do such way?

In D22403#488644, @aprantl wrote:

Using CHECK-lines to define meta-variables without checking anything diverges from FileCheck's usual behavior.