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.5555 0.9066 0.2762
Nice. So how large is the tables, aka what’s the effect on .rodata of cc1?
Definitely nice. Given how much time is spent compiling the insn-emit
family on RISC-V I'd bet we'll be able to see a dip in the
bootstrap+regression test times. Right now it's sitting right at 24hrs
on my overclocked BPI, and any improvement that gets is consistently
under 24hrs is meaningful.
One nice thing about the old way is that you can set breakpoints on the gen_*
routines. Can the tables be annotated with comments so it’s easy to lookup the
part for a particular .md entry and is there a place to break on conditional on
some table index to simulate the old way?
Yeah, the number of gen_* routines is unchanged, and it's still possible
to set breakpoints on them.
That was my understanding, debugging initial codegen with strategic
breakpoints in gen_foo should still work just fine.
I did wonder about removing the out-of-line gen_* functions where possible
and adding the encoding to the recog_data array instead. But it would
still be necessary to define the gen_* routines as at least macros or
inline functions, since the target code can expect gen_* routines to exist
for any non-* named pattern, even optab ones. Doing that did sound like it
would hurt debuggability and might be counterproductive in size terms too.
It'd definitely hurt debugging.
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.
jeff
