> Am 15.11.2025 um 12:33 schrieb Jeff Law <[email protected]>:
> 
> 
> 
>> On 11/14/25 8:09 AM, Richard Biener wrote:
>> The testcases from PR121744 and PR121685 fail to be optimized when
>> the method with the access based on 'this' is inlined.  The following
>> adds an early loop-invariant motion pass to combat this.  I have
>> added a knob on PHI-motion as I think this is neither wanted early
>> nor in the places we call LIM on-demand on a function.
>> I've mass-edited the testsuite to get rid of UNRESOLVEDs, extra
>> fails are the following, sofar not looked at in detail.  I'm looking
>> for general comments on adding LIM early.
>> Bootstrapped and tested on x86_64-unknown-linux-gnu (with the following
>> extra FAILs).
>> +FAIL: c-c++-common/restrict-2.c  -std=gnu++17  scan-tree-dump-times lim3 
>> "Moving statement" 11
>> +FAIL: g++.dg/tree-ssa/pr117123.C  -std=gnu++17  scan-tree-dump-times 
>> optimized "if " 3
>> +FAIL: gcc.dg/loop-unswitch-1.c scan-tree-dump unswitch "unswitching loop"
>> +FAIL: gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile_estimate 
>> "Disambiguating loop" 5
>> +XPASS: gcc.dg/tree-ssa/pr111003.c scan-tree-dump-not optimized "foo"
>> +FAIL: gcc.dg/tree-ssa/pr83403-2.c scan-tree-dump-times lim3 "Executing 
>> store motion of" 10
>> +FAIL: gcc.dg/tree-ssa/ssa-lim-13.c scan-tree-dump-times lim3 "Moving 
>> statement" 2
>> +FAIL: gcc.dg/tree-ssa/ssa-lim-19.c scan-tree-dump-times lim3 "out of loop 
>> 1" 3
>> +FAIL: gcc.dg/tree-ssa/ssa-lim-19.c scan-tree-dump-times lim3 "out of loop 
>> 2" 4
>> +FAIL: gcc.dg/tree-ssa/ssa-lim-22.c scan-tree-dump-times lim3 "out of loop 
>> 1" 3
>> +FAIL: gcc.dg/tree-ssa/ssa-lim-22.c scan-tree-dump-times lim3 "out of loop 
>> 3" 4
>> +FAIL: gcc.dg/tree-ssa/ssa-lim-3.c scan-tree-dump lim3 "Moving 
>> statement.*global.x.*out of loop 1"
>> +FAIL: gcc.dg/tree-ssa/ssa-lim-7.c scan-tree-dump lim3 "Moving statement"
>> +FAIL: gcc.dg/vect/pr69783.c -flto -ffat-lto-objects  scan-tree-dump vect 
>> "improved number of alias checks from [0-9]* to 2"
>> +FAIL: gcc.dg/vect/pr69783.c scan-tree-dump vect "improved number of alias 
>> checks from [0-9]* to 2"
>> +FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects  scan-tree-dump-times 
>> vect "vectorized 1 loops" 1
>> +FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect "vectorized 1 loops" 1
>> +FAIL: gcc.dg/vect/vect-simd-17.c -flto -ffat-lto-objects  scan-tree-dump 
>> vect "vectorized 1[1-2] loops"
>> +FAIL: gcc.dg/vect/vect-simd-17.c scan-tree-dump vect "vectorized 1[1-2] 
>> loops"
>> +FAIL: gfortran.dg/vect/O3-pr49957.f   -O   scan-tree-dump vect "vectorized 
>> 1 loops"
>> +FAIL: gfortran.dg/vect/fast-math-pr37021.f90   -O   scan-tree-dump vect 
>> "vectorized 2 loops"
>>    * passes.def: Add early loop-invariant motion pass.
>>    * tree-ssa-loop-manip.h (loop_invariant_motion_in_fun): Add flag
>>    for PHI-motion.
>>    * tree-ssa-loop-im.cc (pass_lim::set_pass_param): New method.
>>    (pass_lim::early_p): New member.
>>    (pass_lim::execute): Do not run store-motion or phi-motion early.
>>    Exit early when there are no loops.
>>    (loop_invariant_motion_in_fun): New flag for PHI-motion, pass down.
>>    (compute_invariantness): Likewise, guard PHI-motion.
>>    * gimple-loop-iterchange.cc (pass_linterchange::execute): Do
>>    not perform PHI-motion when doing invariant motion.
>>    * gimple-loop-jam.cc (tree_loop_unroll_and_jam): Likewise.
>>    * c-c++-common/restrict-2.c: Scan lim3 dump instead of lim2 dump.
> No strong opinions.  I don't tend of think of LIM as a costly pass.  So if 
> it's solving real problems I wouldn't object.

In principle the dependence analysis part of LIM is quadratic, but I have not 
seen actual cases in a long time where it would outcompete FRE or PRE in terms 
of compile time (but IIRC we do not put hard limits on the max work it does).

I will look at the actual test fallout then.

Richard 

> 
> jeff

Reply via email to