Redundant constants in coremark crc8 for RISCV/aarch64 (no-if-conversion)

[Jeff Law]

On 10/19/22 01:46, Richard Biener wrote:
> On Wed, Oct 19, 2022 at 5:44 AM Jeff Law via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> On 10/18/22 20:09, Vineet Gupta wrote:
>>> On 10/18/22 16:36, Jeff Law wrote:
>>>>>> There isn't a great place in GCC to handle this right now.  If the
>>>>>> constraints were relaxed in PRE, then we'd have a chance, but
>>>>>> getting the cost model right is going to be tough.
>>>>> It would have been better (for this specific case) if loop unrolling
>>>>> was not being done so early. The tree pass cunroll is flattening it
>>>>> out and leaving for rest of the all tree/rtl passes to pick up the
>>>>> pieces and remove any redundancies, if at all. It obviously needs to
>>>>> be early if we are injecting 7x more instructions, but seems like a
>>>>> lot to unravel.
>>>> Yup.  If that loop gets unrolled, it's going to be a mess.  It will
>>>> almost certainly make this problem worse as each iteration is going
>>>> to have a pair of constants loaded and no good way to remove them.
>>> Thats the original problem that I started this thread with. I'd
>>> snipped the disassembly as it would have been too much text but
>>> basically on RV, Coremark crc8 loop of const 8 iterations gets
>>> unrolled including extraneous 8 insns pairs to load the same constant
>>> - which is preposterous. Other arches side-step by using if-conversion
>>> / cond moves, latter currently WIP in RV International. x86 w/o
>>> if-convert seems OK since the const can be encoded in the xor insn.
>>>
>>> OTOH given that gimple/tree-pass cunroll is doing the culprit loop
>>> unrolling and introducing redundant const 8 times, can it ne addressed
>>> there somehow.
>>> tree_estimate_loop_size() seems to identify constant expression, not
>>> just an operand. Can it be taught to identify a "non-trivial const"
>>> and hoist/code-move the expression. Sorry just rambling here, most
>>> likely non-sense.
> On GIMPLE all constants are "simple".
>
>> Oh, cunroll.  There might be a distinct flag for complete unrolling.
> At -O3 we peel completely, there's no flag to disable that.
>
>> I really expect something like Click's work is the way forward.
>> Essentially when you VN the function you'll identify those constants and
>> collapse them all down to a single instance.  Then the GCM phase will
>> kick in and find a place to put the evaluation so that you have one and
>> only one.
> I'd say postreload gcse would be a place to do that.  At least when
> there's no available hardreg CSEing likely isn't going to be a win.

That's an interesting idea.  Do it aggressively post-reload when we know 
there's a register available.   Vineet, that seems like it's worth 
investigation.

jeff