On 3/1/19 9:36 AM, Jakub Jelinek wrote:
On Fri, Mar 01, 2019 at 09:21:16AM +0000, Kyrill Tkachov wrote:
Ok for trunk?
Ok.
Thanks. I'll wait for my regtest, previously I've regtested it only with
an older version of this patch.
Or is there an easy way to estimate if a constant satisfies both "I" and "L"
constraints at the same time and is not one of 0 and INT_MIN, which
of the two (positive or negated) would have smaller encoding and decide
based on that?
Don't think there's a cleaner way of doing that. There are some helper
functions in arm.c that can estimate the number instructions neeedd to
synthesise a constant, but nothing that takes size into account. The
encoding size can only change for TARGET_THUMB2 (not TARGET_ARM) but it's
not worth gating that decision on TARGET_THUMB2 as well IMO.
Well, with the patch the decision which insn is chosen is done in C code.
So it could look like:
if (operands[2] == const0_rtx
|| INTVAL (operands[2]) == -HOST_WIDE_INT_C (0x80000000)
subs; // mandatory
else if (TARGET_THUMB2
&& arm_immediate_operand (operands[2], SImode)
&& arm_neg_immediate_operand (operands[2], SImode))
{
// Both adds and subs can do the job here, and unlike
// non-thumb mode, the instructions can have different
// sizes. Pick the shorter one.
}
else if (which_alternative == 1)
subs;
else
adds;
This can be done incrementally, I just have no idea what the rules
for thumb2 constant encoding are.
Yeah, I had considered this. But I don't think it's worth the extra
code. I'm not aware of any implementation where adds and subs differ in
performance and I'd be surprised so when there's no size advantage I
wouldn't be picky.
Thanks,
Kyrill
Jakub
