RFR: 8320682: [AArch64] C1 compilation fails with "Field too big for insn" [v3]

[Andrew Haley]

On Fri, 8 Dec 2023 19:56:24 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I think a 1MB upper bound is sensible for all platforms (see my other comment below). I'll add a comment explaining the choice, thanks. Please let me know if you think a larger bound is more suitable. In that case, we should also apply @theRealAph's improved aarch64 fix above for `const2reg` (or set a platform-specific bound of 1MB for aarch64).
>
> I don't know what a typical nmethod size is for C1, but I can imagine hitting the 1MB limit by doing something like stress testing with increased inlining limits.  Or maybe very large initialization methods in the future thanks to Leyden AOT or computed constants?  So I guess I'm leaning slightly towards fixing the aarch64 issue now.

it's not a single AArch64 issue, though, it's a few places. I have a particular hatred for dead code (or in this case nearly-dead code) paths  that only get exercised in weird test cases. If we insist that  methods may be > 1MB we can't use the compact ADR and LDR forms of relative addressing. To solve this problem, if it is one, we either put up with inefficiencies for no reason other than to make test cases work, or we generate different code especially for such cases. 

We could use something like relaxation, where we first generate methods optimistically then fall back to less-efficient forms, but again that's make-work for test cases.

I know it's "only C1" but every little helps. Efficient systems are made of thousands of tiny optimizations, each one of which is to small to make a measurable difference on its own.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16951#discussion_r1421394837