On Wed, Nov 26, 2025 at 8:23 PM H.J. Lu wrote:
>
> On Wed, Nov 26, 2025 at 8:00 PM Uros Bizjak wrote:
> >
> > On Wed, Nov 26, 2025 at 12:43 PM H.J. Lu wrote:
> > >
> > > On Wed, Nov 26, 2025 at 5:53 PM Uros Bizjak wrote:
> > > >
> > > > On Wed, Nov 26, 2025 at 10:18 AM H.J. Lu wrote:
> > > > >
On Wed, Nov 26, 2025 at 8:00 PM Uros Bizjak wrote:
>
> On Wed, Nov 26, 2025 at 12:43 PM H.J. Lu wrote:
> >
> > On Wed, Nov 26, 2025 at 5:53 PM Uros Bizjak wrote:
> > >
> > > On Wed, Nov 26, 2025 at 10:18 AM H.J. Lu wrote:
> > > >
> > > > On Wed, Nov 26, 2025 at 3:52 PM Uros Bizjak wrote:
> > >
On Wed, Nov 26, 2025 at 12:43 PM H.J. Lu wrote:
>
> On Wed, Nov 26, 2025 at 5:53 PM Uros Bizjak wrote:
> >
> > On Wed, Nov 26, 2025 at 10:18 AM H.J. Lu wrote:
> > >
> > > On Wed, Nov 26, 2025 at 3:52 PM Uros Bizjak wrote:
> > > >
> > > > On Wed, Nov 26, 2025 at 8:26 AM H.J. Lu wrote:
> > > >
>
On Wed, Nov 26, 2025 at 5:53 PM Uros Bizjak wrote:
>
> On Wed, Nov 26, 2025 at 10:18 AM H.J. Lu wrote:
> >
> > On Wed, Nov 26, 2025 at 3:52 PM Uros Bizjak wrote:
> > >
> > > On Wed, Nov 26, 2025 at 8:26 AM H.J. Lu wrote:
> > >
> > > > > > The reasons for try_combine_insn are that
> > > > > >
>
On Wed, Nov 26, 2025 at 10:53 AM Uros Bizjak wrote:
> > > > 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
On Wed, Nov 26, 2025 at 10:18 AM H.J. Lu wrote:
>
> On Wed, Nov 26, 2025 at 3:52 PM Uros Bizjak wrote:
> >
> > On Wed, Nov 26, 2025 at 8:26 AM H.J. Lu wrote:
> >
> > > > > The reasons for try_combine_insn are that
> > > > >
> > > > > 1. When general_operand is called, instruction info isn't avai
On Wed, Nov 26, 2025 at 3:52 PM Uros Bizjak wrote:
>
> On Wed, Nov 26, 2025 at 8:26 AM H.J. Lu 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_vo
On Wed, Nov 26, 2025 at 8:26 AM H.J. Lu 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
On Wed, Nov 26, 2025 at 8:34 AM Jeff Law wrote:
>
>
>
> On 11/20/25 4:35 PM, H.J. Lu wrote:
>
> >>
> >> The latest version needs to be posted for review, but before you do
> >> that, I few comments on the version I tested from your branch.
> >>
> >> I don't see any good reason to have a target hoo
On 11/20/25 4:35 PM, H.J. Lu wrote:
The latest version needs to be posted for review, but before you do
that, I few comments on the version I tested from your branch.
I don't see any good reason to have a target hook to disable this
behavior since we have a flag to control. If the patch tr
On Thu, Nov 20, 2025 at 8:08 AM Jeff Law wrote:
>
>
>
> On 11/16/25 4:36 PM, H.J. Lu wrote:
> > On Mon, Nov 17, 2025 at 12:38 AM Jeff Law wrote:
> >>
> >>
> >>
> >> On 10/27/25 3:53 PM, H.J. Lu wrote:
> >>
> >>>
> As HJ indicated, I wouldn't expect significant fallout on load/store
> ar
On 11/16/25 4:36 PM, H.J. Lu wrote:
On Mon, Nov 17, 2025 at 12:38 AM Jeff Law wrote:
On 10/27/25 3:53 PM, H.J. Lu wrote:
As HJ indicated, I wouldn't expect significant fallout on load/store
architectures. So the scope of fallout isn't likely to be too terrible.
I was going to throw
On Mon, Nov 17, 2025 at 12:38 AM Jeff Law wrote:
>
>
>
> On 10/27/25 3:53 PM, H.J. Lu wrote:
>
> >
> >> As HJ indicated, I wouldn't expect significant fallout on load/store
> >> architectures. So the scope of fallout isn't likely to be too terrible.
> >>
> >> I was going to throw it in my tester,
On 10/27/25 3:53 PM, H.J. Lu wrote:
As HJ indicated, I wouldn't expect significant fallout on load/store
architectures. So the scope of fallout isn't likely to be too terrible.
I was going to throw it in my tester, but it doesn't apply cleanly on
the trunk.
patching file gcc/recog.cc
Hu
On Tue, Oct 28, 2025 at 9:31 AM Richard Biener
wrote:
>
> On Tue, Oct 28, 2025 at 9:29 AM Richard Biener
> wrote:
> >
> > On Tue, Oct 28, 2025 at 7:03 AM H.J. Lu wrote:
> > >
> > > On Tue, Oct 28, 2025 at 1:26 PM Uros Bizjak wrote:
> > > >
> > > > On Mon, Oct 27, 2025 at 11:56 PM H.J. Lu wrote
On Tue, Oct 28, 2025 at 9:29 AM Richard Biener
wrote:
>
> On Tue, Oct 28, 2025 at 7:03 AM H.J. Lu wrote:
> >
> > On Tue, Oct 28, 2025 at 1:26 PM Uros Bizjak wrote:
> > >
> > > On Mon, Oct 27, 2025 at 11:56 PM H.J. Lu wrote:
> > >
> > > > > > > IMO the -fcombine-op-with-volatile-memory-load is q
On Tue, Oct 28, 2025 at 7:03 AM H.J. Lu wrote:
>
> On Tue, Oct 28, 2025 at 1:26 PM Uros Bizjak wrote:
> >
> > On Mon, Oct 27, 2025 at 11:56 PM H.J. Lu wrote:
> >
> > > > > > IMO the -fcombine-op-with-volatile-memory-load is quite a bad name.
> > > > > > Options should have names that mean someth
On Tue, Oct 28, 2025 at 1:26 PM Uros Bizjak wrote:
>
> On Mon, Oct 27, 2025 at 11:56 PM H.J. Lu wrote:
>
> > > > > IMO the -fcombine-op-with-volatile-memory-load is quite a bad name.
> > > > > Options should have names that mean something to users. As this
> > > > > seems to
> > > > > supposed
On Mon, Oct 27, 2025 at 11:56 PM H.J. Lu wrote:
> > > > IMO the -fcombine-op-with-volatile-memory-load is quite a bad name.
> > > > Options should have names that mean something to users. As this seems
> > > > to
> > > > supposed to be a target opt-in I'd suggest to not expose this to users
> >
On Mon, Oct 27, 2025 at 8:43 PM Richard Biener
wrote:
>
> On Mon, Oct 27, 2025 at 12:16 PM H.J. Lu wrote:
> >
> > On Mon, Oct 27, 2025 at 4:37 PM Richard Biener
> > wrote:
> > >
> > > On Fri, Oct 24, 2025 at 11:25 PM H.J. Lu wrote:
> > > >
> > > > On Fri, Oct 24, 2025 at 10:23 PM Georg-Johann L
On Tue, Oct 28, 2025 at 12:04 AM Jeff Law wrote:
>
>
>
> On 10/27/25 2:37 AM, Richard Biener wrote:
> ?
> >>
> >> There are 2 reasons:
> >>
> >> 1. RISC processors only allow moves with memory. Since this optimization
> >> only applies to other load operations, it is nop for most RISC processor
On 10/27/25 2:37 AM, Richard Biener wrote:
?
There are 2 reasons:
1. RISC processors only allow moves with memory. Since this optimization
only applies to other load operations, it is nop for most RISC processors.
2. Some GCC tests scan compiler assembly outputs which don't expect other
On Mon, Oct 27, 2025 at 12:16 PM H.J. Lu wrote:
>
> On Mon, Oct 27, 2025 at 4:37 PM Richard Biener
> wrote:
> >
> > On Fri, Oct 24, 2025 at 11:25 PM H.J. Lu wrote:
> > >
> > > On Fri, Oct 24, 2025 at 10:23 PM Georg-Johann Lay wrote:
> > > >
> > > > Am 24.10.25 um 15:45 schrieb H.J. Lu:
> > > >
On Mon, Oct 27, 2025 at 4:37 PM Richard Biener
wrote:
>
> On Fri, Oct 24, 2025 at 11:25 PM H.J. Lu wrote:
> >
> > On Fri, Oct 24, 2025 at 10:23 PM Georg-Johann Lay wrote:
> > >
> > > Am 24.10.25 um 15:45 schrieb H.J. Lu:
> > > > For x86, volatile memory can be used as source operand for loads.
On Fri, Oct 24, 2025 at 11:25 PM H.J. Lu wrote:
>
> On Fri, Oct 24, 2025 at 10:23 PM Georg-Johann Lay wrote:
> >
> > Am 24.10.25 um 15:45 schrieb H.J. Lu:
> > > For x86, volatile memory can be used as source operand for loads. Add
> > > -fcombine-op-with-volatile-memory-load to allow operations
On Fri, Oct 24, 2025 at 10:23 PM Georg-Johann Lay wrote:
>
> Am 24.10.25 um 15:45 schrieb H.J. Lu:
> > For x86, volatile memory can be used as source operand for loads. Add
> > -fcombine-op-with-volatile-memory-load to allow operations with volatile
> > memory load:
> >
> > 1. Add a field, try_co
On Fri, Oct 24, 2025 at 4:23 PM Georg-Johann Lay wrote:
> Can it break volatile correctness or so?
I have done some smoke tests with the patched compiler with (gcc -O2):
--cut here--
volatile int m;
int foo (void)
{
int h = m;
int r = m;
asm volatile ("barrier" ::: "memory");
int p = m
On Fri, Oct 24, 2025 at 3:45 PM H.J. Lu wrote:
>
> For x86, volatile memory can be used as source operand for loads. Add
> -fcombine-op-with-volatile-memory-load to allow operations with volatile
> memory load:
>
> 1. Add a field, try_combine_insn, to recog_data_d for the combine pass to
>pas
Am 24.10.25 um 15:45 schrieb H.J. Lu:
For x86, volatile memory can be used as source operand for loads. Add
-fcombine-op-with-volatile-memory-load to allow operations with volatile
memory load:
1. Add a field, try_combine_insn, to recog_data_d for the combine pass to
pass the instruction in
29 matches
Mail list logo
