This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH][ARM][GAS] Allow integer immediate for VFP vmov instructions.
- From: Nick Clifton <nickc at redhat dot com>
- To: Tamar Christina <Tamar dot Christina at arm dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>, nd <nd at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Thu, 10 May 2018 15:55:36 +0100
- Subject: Re: [PATCH][ARM][GAS] Allow integer immediate for VFP vmov instructions.
- References: <20180510110633.GA5507@arm.com> <5da27a76-8822-ea4e-71a4-a11778758cbf@redhat.com> <20180510144640.GA11488@arm.com>
Hi Tamar,
>> I think that you ought to verify that the conversion to floating point
>> representation has not lost any accuracy, and issue a warning/error if
>> the floating point and immediate values are not the same.
>
> If there's a significant loss of precision you're going to get an error already due to
> is_quarter_float rejecting the float then as it wouldn't be representable.
>
> You also can't have a loss due to a large value, as if the value is large enough not to fit
> inside a float it will also not fit in the imm encoding for the instruction, so you'll get
> an error saying "garbage after ...".
>
> I have a patch locally that adds a warning using truncf (imm) != imm but have so far been
> unable to trigger any failing case. I can submit it if you'd like to have a warning here
> but it also adds a dependency to libm. I assume that's not a problem?
That's not a problem, although I was assuming that you would just cast the float
result back to an int and then compare that with the original integer value.
But, if as you say, it is not possible to get to this point with an invalid integer
constant, then please disregard my comment.
So - patch approved - please apply.
> I assume the AArch64 variant of this patch (submitted at the same time) wouldn't need this
> as that just has a more liberal parsing and I don't know whether it was an integer at all.
Correct - that patch is OK too.
Cheers
Nick