Besides, we don't have compilation issues in crossing-compiling (with segment
intrinsics).
But I do agree we need to address such issue.
As far as I known, GCC compile insn-emit in single thread single core.
Can we multi-thread && multi-core to compile it to speed up the compilation?
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-05-25 11:43
To: Palmer Dabbelt; Vineet Gupta
CC: kito.cheng; gcc-patches; Kito Cheng; Patrick O'Neill; Jeff Law; macro;
juzhe.zh...@rivai.ai
Subject: Re: RISC-V Bootstrap problems
On 5/24/23 17:13, Palmer Dabbelt wrote:
> On Wed, 24 May 2023 16:12:20 PDT (-0700), Vineet Gupta wrote:
[ ... big snip ... ]
>>
>> Never mind. Looks like I found the issue - with just trial and error and
>> no idea of how this stuff works.
>> The torture-{init,finish} needs to be in riscv.exp not rvv.exp
>> Running full tests now.
>
> Thanks!
Marginally related. I was able to bisect the "hang" when 3-staging the
trunk on RISC-V with qemu user mode emulation.
So it wasn't actually hanging, but after the introduction of segment
intrinsics the compilation time for insn-emit explodes -- previously I
could do a full 3-stage bootstrap, build the glibc & the kernel, then
test c/c++/fortran in ~10 hours.
Now just building insn-emit.o alone takes ~10 hours in that environment.
I suspect (but have not yet confirmed) that we should see a huge
compile-time spike in cross builds as well, though obviously it won't be
as bad since we're not using qemu emulation.
Clearly something isn't scaling well. I don't know if we've got a crazy
large function in there, a crazy number of functions or something that's
just triggering a compile-time scaling problem. Whatever it is, we
probably need to address it.
jeff
