On 03/08/16 12:52, Ramana Radhakrishnan wrote:
On Thu, Jul 28, 2016 at 12:37 PM, Ramana Radhakrishnan
<ramana....@googlemail.com> wrote:
On Mon, Jul 4, 2016 at 3:02 PM, Matthew Wahab
<matthew.wa...@foss.arm.com> wrote:
On 19/05/16 15:54, Matthew Wahab wrote:
On 18/05/16 16:20, Joseph Myers wrote:
On Wed, 18 May 2016, Matthew Wahab wrote:
In short: instructions for direct HFmode arithmetic should be described
with patterns with the standard names. It's the job of the
architecture-independent compiler to ensure that fp16 arithmetic in the
user's source code only generates direct fp16 arithmetic in GIMPLE (and
thus ends up using those patterns) if that is a correct representation of
the source code's semantics according to ACLE.
This patch changes the implementation to use the standard names for the
HFmode arithmetic. Later patches will also be updated to use the
arithmetic operators where appropriate.
All fine except -
Why can we not extend the <vrint_pattern> and the l<vrint_pattern> in
vfp.md for fp16 and avoid all the unspecs for vcvta and vrnd*
instructions ?
I now feel reasonably convinced that these can go away and be replaced
by extending the <vrint_pattern> and l<vrint_pattern> expanders to
consider FP16 as well. Given that we are still only in the middle of
stage1 - I'm ok for you to apply this as is and then follow-up with a
patch that gets rid of the UNSPECs . If this holds for add, sub and
other patterns I don't see why it wouldn't hold for all these patterns
as well.
Joseph, do you have any opinions on whether we should be extending the
standard pattern names or not for btrunc, ceil, round, floor,
nearbyint, rint, lround, lfloor and lceil optabs for the HFmode
quantities ?
Sorry for the delay replying.
I didn't extend the lvrint_pattern and vrint_pattern expanders to HF mode
because of the general intention to do fp16 operations through the NEON
intrinsics. If extending them to HF mode produces the expected behaviour for
the standard names that they implement then I agree that the change should be made.
I would prefer to do that as a separate patch though, to make sure that the new
operations are properly tested. Some of the existing tests (in gcc.target/arm)
use builtins that aren't available for HF mode so something else will be needed.
Matthew
