Re: [PATCH 1/3]middle-end: Add the ability to let the target decide the method of argument promotions.

[Richard Sandiford via Gcc-patches]

Tamar Christina <tamar.christ...@arm.com> writes:
> Hi All,
>
> Some targets require function parameters to be promoted to a different
> type on expand time because the target may not have native instructions
> to work on such types.  As an example the AArch64 port does not have native
> instructions working on integer 8- or 16-bit values.  As such it promotes
> every parameter of these types to 32-bits.

This doesn't seem specific to parameters though.  It applies to any
8- or 16-bit variable.  E.g.:

#include <stdint.h>
uint8_t foo(uint32_t x, uint32_t y) {
    uint8_t z = x != 0 ? x : y;
    return z + 1;
}

generates:

foo:
        cmp     w0, 0
        and     w1, w1, 255
        and     w0, w0, 255
        csel    w0, w1, w0, eq
        add     w0, w0, 1
        ret

So I think the new behaviour is really a modification of the PROMOTE_MODE
behaviour rather than the PROMOTE_FUNCTION_MODE behaviour.

FWIW, I agree with Richard that it would be better not to add a new hook.
I think we're really making PROMOTE_MODE choose between SIGN_EXTEND,
ZERO_EXTEND or SUBREG (what LLVM would call “any extend”) rather
than the current SIGN_EXTEND vs. ZERO_EXTEND choice.

Thanks,
Richard