On Wed, 20 Dec 2023 10:12:04 PST (-0800), jeffreya...@gmail.com wrote:


On 12/20/23 11:05, Palmer Dabbelt wrote:
On Wed, 20 Dec 2023 09:55:48 PST (-0800), jeffreya...@gmail.com wrote:


On 12/18/23 00:46, KuanLin Chen wrote:
Hi Jeff,

Sorry for this missing.
I've removed riscv_asm_output_pool_epilogue because the pool
beginning is always aligned from FUNCTION_BOUNDARY.
Please find attached. Thank you.
Thanks. I regression tested this on rv64gc without any issues and fixed
up the ChangeLog a bit.  Pushed to the trunk.  Thanks for your patience.

Looks like the psABI PR is still open
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/388>?

I guess there's no hard psABI dependency here, we're just doing constant
pools so there's no new assembler/linker stuff that's strictly
necessary.  I'm fine just ignoring the psABI as it's a pretty miserable
place to try and get things done, we're started doing that where we can
elsewhere as well.
Yea, the implementation relies largely on just pushing stuff into the
constant pool, so we're largely independent ABI stuff with the likely
exception being relocations.

Ya, but I think we'd only need the relocations if we were going to try relaxing stuff. We'd kicked around some ideas there: we could de-duplicate constant pools or inline smaller constants. That's all way to complex to try and get into this upcoming binutils release, though (doubly so with this LEB128 ABI break we're still trying to deal with).

So I think we can just punt on all that for a bit. We've got bigger fish to fry.

In theory (and I did not test this), it should be possible to use large
code model codegen in a smaller mode and it should interoperate.  I
seriously pondered doing that as an additional test, then figured I had
other higher priority items on my list.

IMO we should test that. At least the common case of a medlow libc linked into medany programs should be easy.

+Patrick: let's add some configs to the CI for this?

So maybe we should just close that PR?
I'll let Kito chime in on that.

WFM, I try to stay as far away from that as possible ;)


jeff

Reply via email to