On Fri, Aug 09, 2024 at 04:35:32PM +0100, Richard Sandiford wrote:
>
> But what I mean is: the code could just be:
>
> od = lookup_operand_data (&d->operand[0]);
> /* Brute force substring search. */
> for (; od; od = od->eq_next)
> {
> i = 1;
> while (1)
> {
>
Xianmiao Qu writes:
> On Wed, Aug 07, 2024 at 03:17:24PM +0100, Richard Sandiford wrote:
>> Looks like a nice speed-up thanks.
>>
>> A couple of general points:
>>
>> * Could you try using the more type-safe hash-table.h, instead of hashtab.h?
>> Similarly inchash.h for the hashing.
>>
>> * A
On Wed, Aug 07, 2024 at 03:17:24PM +0100, Richard Sandiford wrote:
> Looks like a nice speed-up thanks.
>
> A couple of general points:
>
> * Could you try using the more type-safe hash-table.h, instead of hashtab.h?
> Similarly inchash.h for the hashing.
>
> * Although this wasn't always the
Xianmiao Qu writes:
> With the increase in the number of modes and patterns for some
> backend architectures, the place_operands function becomes a
> bottleneck in the speed of genoutput, and may even become a
> bottleneck in the overall speed of building the GCC project.
> This patch aims to acce
With the increase in the number of modes and patterns for some
backend architectures, the place_operands function becomes a
bottleneck in the speed of genoutput, and may even become a
bottleneck in the overall speed of building the GCC project.
This patch aims to accelerate the place_operands funct
