On 5/21/25 5:06 AM, Richard Sandiford wrote:
Jeff Law writes:
Given you know the RTL gen* related thingies better than anyone, I'd say
go forward and if there's any fallout, we can certainly cope with it.
Thanks. I've now pushed the series and the earlier genemit tweaks,
with the discusse
Jeff Law writes:
> Given you know the RTL gen* related thingies better than anyone, I'd say
> go forward and if there's any fallout, we can certainly cope with it.
Thanks. I've now pushed the series and the earlier genemit tweaks,
with the discussed change to mark the operandN arguments as cons
On 5/18/25 2:41 PM, Richard Sandiford wrote:
Target [A] [B] [C]
native aarch64 0.5627 0.9585 0.5677
native x86_64 0.5925 0.9467 0.6377
aarch64-x-riscv64 0. 0.9066 0.2762
Nice. So how large
Richard Biener writes:
>> Am 16.05.2025 um 19:37 schrieb Richard Sandiford :
>>
>> genemit has traditionally used open-coded gen_rtx_FOO sequences
>> to build up the instruction pattern. This is now the source of
>> quite a bit of bloat in the binary, and also a source of slow
>> compile times.
> Am 16.05.2025 um 19:37 schrieb Richard Sandiford :
>
> genemit has traditionally used open-coded gen_rtx_FOO sequences
> to build up the instruction pattern. This is now the source of
> quite a bit of bloat in the binary, and also a source of slow
> compile times.
>
> Two obvious ways of t
genemit has traditionally used open-coded gen_rtx_FOO sequences
to build up the instruction pattern. This is now the source of
quite a bit of bloat in the binary, and also a source of slow
compile times.
Two obvious ways of trying to deal with this are:
(1) Try to identify rtxes that have a simi
