Browse Source
* cranelift: Specialize StackAMode::FPOffset The StackAMode::FPOffset address mode was always used together with fp_to_arg_offset, to compute addresses within the current stack frame's argument area. Instead, introduce a new StackAMode::ArgOffset variant specifically for stack addresses within the current frame's argument area. The details of how to find the argument area are folded into the conversion from the target-independent StackAMode into target-dependent address-mode types. Currently, fp_to_arg_offset returns a target-specific constant, so I've preserved that constant in each backend's address-mode conversion. However, in general the location of the argument area may depend on calling convention, flags, or other concerns. Also, it may not always be desirable to use a frame pointer register as the base to find the argument area. I expect some backends will eventually need to introduce new synthetic addressing modes to resolve argument-area offsets after register allocation, when the full frame layout is known. I also cleaned up a couple minor things while I was in the area: - Determining argument extension type was written in a confusing way and also had a typo in the comment describing it. - riscv64's AMode::offset was only used in one place and is clearer when inlined. * Review comments @bjorn3 correctly pointed out that I had changed the overflow behavior of this address computation. The existing code always added the result of `fp_to_arg_offset` using `i64` addition. It used Rust's default overflow behavior for addition, which panics in debug builds and wraps in release builds. In this commit I'm preserving that behavior: - s390x doesn't add anything, so can't overflow. - aarch64 and riscv64 use `i64` offsets in `FPOffset` address modes, so the addition is still using `i64` addition. - x64 does a checked narrowing to `i32`, so it's important to do the addition before that, on the wider `i64` offset.pull/8296/head
Jamey Sharp
7 months ago
committed by
GitHub
6 changed files with 27 additions and 63 deletions
Loading…
Reference in new issue