Just FYI. This patch does something to gcc.target/mips/madd-8.c, and
gcc.target/mips/msub-8.c.
-PASS: gcc.target/mips/madd-8.c -O2 scan-assembler \tmul\t
-PASS: gcc.target/mips/madd-8.c -O2 scan-assembler-not \tmadd\t
-PASS: gcc.target/mips/madd-8.c -O2 scan-assembler-not \tmflo\t
-PAS
On Mon, Jun 24, 2024 at 9:38 PM Segher Boessenkool
wrote:
>
> I didn't see this before. Sigh.
>
> On Tue, Jan 02, 2024 at 09:47:11AM +, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> > >> This patch adds a c
I didn't see this before. Sigh.
On Tue, Jan 02, 2024 at 09:47:11AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> >> This patch adds a combine pass that runs late in the pipeline.
> >
> > But it is not. It i
On Wed, Oct 25, 2023 at 2:49 AM Richard Sandiford
wrote:
>
> This patch adds a combine pass that runs late in the pipeline.
> There are two instances: one between combine and split1, and one
> after postreload.
>
> The pass currently has a single objective: remove definitions by
> substituting int
On 1/10/24 06:01, Richard Sandiford wrote:
So to get an idea for expectations: would it be a requirement that a
GCC 15 submission is enabled unconditionally and all known issues in
the ports fixed?
I don't think we need to fix those latent port issues as a hard
requirement. I try to balance
On 1/10/24 06:35, Richard Biener wrote:
I think x86 maintainers could opt to disable the pass - so it would
be opt-out. It's reasonable to expect them to fix the backend given
there's nothing really wrong with the new pass, it just does
something that wasn't done before at that point?
That's
On Wed, 10 Jan 2024, Richard Sandiford wrote:
> Just a note that, following discussion on IRC, I'll pull this for
> GCC 14 and resubmit for GCC 15.
>
> There was also pushback on IRC about making the pass opt-in.
> Enabling it for x86_64 would mean fixing RPAD to use a representation
> that is mo
Just a note that, following discussion on IRC, I'll pull this for
GCC 14 and resubmit for GCC 15.
There was also pushback on IRC about making the pass opt-in.
Enabling it for x86_64 would mean fixing RPAD to use a representation
that is more robust against recombination, but as you can imagine, it
On 1/8/24 12:11, Richard Sandiford wrote:
Thanks. That led me to the following, which seems a bit more plausible
than my first attempt. I'll test it on aarch64-linux-gnu and
x86_64-linux-gnu. Does it look OK?
It looks reasonable to me. I'm going to send another failure (ICE in
finalize_
Jeff Law writes:
> On 1/8/24 09:59, Richard Sandiford wrote:
>> This is a bit of a hopeful stab, but is the problem that recog_data still
>> had the previous contents of insn 3674, and so extract_insn_cached wrongly
>> thought that it doesn't need to do anything? If so, does something like:
>>
>
On 1/8/24 09:59, Richard Sandiford wrote:
This is a bit of a hopeful stab, but is the problem that recog_data still
had the previous contents of insn 3674, and so extract_insn_cached wrongly
thought that it doesn't need to do anything? If so, does something like:
diff --git a/gcc/recog.cc
Jeff Law writes:
> On 1/8/24 04:52, Richard Sandiford wrote:
>> Jeff Law writes:
>>> The other issue that's been in the back of my mind is costing. But I
>>> think the model here is combine without regards to cost.
>>
>> No, it does take costing into account. For size, it's the usual
>> "sum u
On 1/8/24 04:52, Richard Sandiford wrote:
Jeff Law writes:
The other issue that's been in the back of my mind is costing. But I
think the model here is combine without regards to cost.
No, it does take costing into account. For size, it's the usual
"sum up the before and after insn costs
Jeff Law writes:
> The other issue that's been in the back of my mind is costing. But I
> think the model here is combine without regards to cost.
No, it does take costing into account. For size, it's the usual
"sum up the before and after insn costs and see which one is lower".
For speed, the
On 1/5/24 10:35, Richard Sandiford wrote:
Jeff Law writes:
On 10/24/23 12:49, Richard Sandiford wrote:
This patch adds a combine pass that runs late in the pipeline.
There are two instances: one between combine and split1, and one
after postreload.
So have you done any investigation on cas
Jeff Law writes:
> On 10/24/23 12:49, Richard Sandiford wrote:
>> This patch adds a combine pass that runs late in the pipeline.
>> There are two instances: one between combine and split1, and one
>> after postreload.
> So have you done any investigation on cases caught by your new pass
> between
On 10/24/23 12:49, Richard Sandiford wrote:
This patch adds a combine pass that runs late in the pipeline.
There are two instances: one between combine and split1, and one
after postreload.
So have you done any investigation on cases caught by your new pass
between combine and split1 to chara
Segher Boessenkool writes:
> Hi!
>
> On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
>> This patch adds a combine pass that runs late in the pipeline.
>
> But it is not. It is a completely new thing, and much closer to
> fwprop than to combine, too.
Well, it is a combine pass.
Hi!
On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> This patch adds a combine pass that runs late in the pipeline.
But it is not. It is a completely new thing, and much closer to
fwprop than to combine, too.
Could you rename it to something else, please? Something less con
19 matches
Mail list logo
