[llvm] [RISCV] Use QC_E_LI to materialise addresses (PR #155819)

[Sam Elliott via llvm-commits]

lenary wrote:

> > @topperc it would be good to understand your feelings about this (even without a full review). I've been wary of changing the materialisation sequences so far, but this gets us a measurable code size improvement - customer images are seeing a 4-8% improvement (sorry, we were comparing over a few commits, rather than just this one).
> > These numbers are using our linker which has relaxations for `qc.e.li` (to `qc.li`, `c.lui`, or a gp-relative `addi`) - but not relaxations that turn `lui+addi` into `qc.e.li` or something smaller (which end up needing lots of constraints, including what effectively is a one-use check on the `lui`).
> 
> This patch looks like it would lose out on folding the ADDI into load/store instructions. Is there another patch for that or do you get code size savings without it?

We get code size savings with exactly this patch, and no modifications/changes to MergeBaseOffset. My hypothesis is that before relaxation, you get lots more loads/stores with zero offsets, which compress (whereas before, the loads/stores contained a symbol reference so had to be close to GP or zero to get any savings after relaxation), and then the images fit within 20 bits, so you mostly end up with (for example) `qc.li; c.lw` (6 bytes) where otherwise you would have got `lui; lw` (8 bytes).

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