Re: [RFC][V2] RISC-V: Support -mcmodel=large.

[Palmer Dabbelt <palmer@dabbelt.com>]

On Wed, 20 Dec 2023 10:25:00 PST (-0800), jeffreyalaw@gmail.com wrote:
>
>
> On 12/20/23 11:21, Palmer Dabbelt wrote:
>
>>> 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).
> Agreed.  And note that de-duplication is mostly implemented without need
> for the target to do anything.  I was kindof amazed to see some of the
> places it kicked in on other ports I've worked with.

I think all we'd need from GCC is some way to get the "this load is a 
constant pool address that can be messed with" relocation in there, the 
linker would do all the heavy lifting.  That's probably just a new 
assembler pseudo, so pretty much nothing on the compiler side of things.

>>> 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?
> I was pondering a one-off by turning on the large code model by default,
> then doing a bootstrap & regression test in QEMU.  But integrated into
> CI is even better.

OK, let's just add it to CI -- it'd be essentially the same testing, 
just it'll stick around.

>
> Jeff