On 3/1/19 9:42 AM, Kyrill Tkachov wrote:
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.
Two thoughts collided in my head on the last sentence. I meant to say:
"I'm not aware of any implementation where adds and subs differ in
performance so when there's no size advantage I wouldn't be picky."
Thanks,
Kyrill
Thanks,
Kyrill
>
> Jakub
