User Details
- User Since
- Apr 18 2016, 7:25 AM (329 w, 1 d)
Today
Oh, yep, I got it.
- Replace pass before BranchRelaxation
- Upstream review fixes(2)
Yesterday
Gently ping
Mon, Aug 1
- Upstream review fixes
Fri, Jul 29
Wed, Jul 27
Gentle ping
- Fix typo
Tue, Jul 26
Gentle ping
Gentle ping
Mon, Jul 18
- [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
Thu, Jul 14
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
Tue, Jul 12
- Added Scalar to CMakeLists
- [RISCV] Turn off SeparateConstOffsetFromGEP by default
Fix review
Refactoring
Jul 3 2022
- [SimplifyCFG] Added flag to control creation of PHI nodes with entity elements
- [SimplifyCFG] Added flag to control creation of PHI nodes with entity elements
Jun 29 2022
- [SeparateConstOffsetFromGEP] Fix comparator for map with GEP bases
Jun 28 2022
Run one more time benchmarks from test-suite.
Jun 20 2022
- Added Scalar to CMakeLists
Are you seeing any instances of worse code in any of the tests / benchmarks you're looking at?
Jun 16 2022
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.
Jun 15 2022
Separate part with pass modification
Jun 14 2022
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
Nov 15 2018
Nov 14 2018
Please, could someone review these changes?
Or may be add other reviewers if I choose wrong people?
Oct 23 2018
Sep 26 2016
Both first and second case.
- Are there possible usages of this feature in LLVM tests already?
I don't know LLVM tests well to answer this question.
- 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.
Sep 25 2016
Sep 19 2016
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.
Sep 16 2016
Ok, I'll try to use STL regex.
Sep 15 2016
Patch without modifiers for pattern parameters and using pattern and variables inside definition of other patterns.
Sep 14 2016
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?
Sep 13 2016
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)?
Sep 10 2016
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.
Sep 8 2016
Change syntax to new one suggested by Vedant Kumar.
Sep 1 2016
Jul 21 2016
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
Jul 20 2016
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?