[llvm] [GISel][RISCV]Implement indirect parameter passing for large scalars (PR #95429)

[Craig Topper via llvm-commits]

topperc wrote:

> > > > > > > Why don't just do the lowering in the frontend? I.e. return getNaturalAlignIndirect(...) if argument's size exceeds 2xXLEN
> > > > > > 
> > > > > > 
> > > > > > I think we do.
> > > > > 
> > > > > 
> > > > > In case of this code https://godbolt.org/z/bqY5Kd5n8 we don't do that in the frontend. This is the IR after the final step in before the irtranslator:
> > > > 
> > > > 
> > > > I think this is a bug in clang IRGen. The RISC-V code wasn't written to expect int128 for rv32.
> > > 
> > > 
> > > The reason why I did this PR is because one of my teammates was trying to compile Picolib or maybe compiler-rt for RISC-V and it has used 128bit bit shifts. So to compile the projects they needed the `-fforce-enable-int128` flag. Plus also the standard talks about this scenario, so I decided to work on the issue.
> > 
> > 
> > And they're trying to use GlobalISel too?
> 
> No they don't. But shouldn't we convert the full back-end to globalisel? And if we want to do that we also need to pass 128 bit values I think. I know, that a front-end fix would solve it for GlobalISel, but then that front end fix should be introduced to other front-ends like the Rust front-end, the Zig front-end and so on. So I think fixing this in the back-end is better.
> 
> But if you think, that this should really go to the front-end I would be glad to implement that too.

Looks like the clang frontend intentionally defers indirect scalar handling to the backend. I thought maybe -fforce-enable-int128 had just been overlooked. I didn't think there were any scalars larger than 2*XLen for rv32 by default. But I forgot about fp128 and `__BitInt`.

Large `__BitInt` does force indirect in the frontend. Though which sizes is affected by -fforce-enable-int128 which is probably a separate bug.

https://github.com/llvm/llvm-project/pull/95429