On Wed, Nov 26, 2025 at 8:26 AM H.J. Lu <[email protected]> wrote:
> > > The reasons for try_combine_insn are that
> > >
> > > 1. When general_operand is called, instruction info isn't available.
> > > 2. Only recog_for_combine_1 calls init_recog_no_volatile and
> > > tries memory operands.
> > But if we make stores work sensibly, then we no longer need the
> > instruction, right? It's the mere need to track the instruction that
> > seems rather hokey/hackish to me right now.
> >
> > jeff
>
> For
>
> volatile unsigned char u8;
>
> void test (void)
> {
> u8 = u8 + u8;
> u8 = u8 - u8;
> }
>
> When volatile store is allowed, we generate
>
> (insn 8 7 9 2 (parallel [
> (set (mem/v/c:QI (symbol_ref:DI ("u8") [flags 0x2]
> <var_decl 0x7fe9719d6e40 u8>) [0 u8+0 S1 A8])
> (ashift:QI (mem/v/c:QI (symbol_ref:DI ("u8") [flags
> 0x2] <var_decl 0x7fe9719d6e40 u8>) [0 u8+0 S1 A8])
> (const_int 1 [0x1])))
> (clobber (reg:CC 17 flags))
> ])
> "/export/gnu/import/git/gitlab/x86-gcc-test/gcc/testsuite/gcc.dg/pr86617.c":7:6
> 1139 {*ashlqi3_1}
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
>
> on x86 which leads to
>
> salb u8(%rip)
>
> instead of 2 loads. Without the instruction, we don't know if a
> memory reference
> should be allowed for stores.
combine pass doesn't handle volatiles correctly in all cases, this is
the reason I think this propagation should be done in late-combine. We
are interested only in propagations of memory loads/stores into
instructions, and late-combine does exactly that.
Uros.
