[llvm-dev] Changes to TableGen in v4.0?

Nemanja Ivanovic via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 23 06:59:33 PST 2017


I believe fpround is a node that takes a larger FP representation and
rounds it to a smaller FP representation (i.e. f64 -> f32) and may or may
not be known to preserve the exact value.

The fround node on the other had is used to actually round an FP value to
the nearest whole number (note. not integer in a sense that it goes from
f64 -> i64). It just rounds a floating point value to the nearest floating
point whole number (i.e. f64 -> f64). I believe that for this one, the
rounding mode is "Nearest away" or round to nearest whole number, ties away
from zero.

On Mon, Jan 23, 2017 at 3:09 PM, Martin J. O'Riordan <
martin.oriordan at movidius.com> wrote:

> Thanks, I have replaced these with ‘fpround’ and it does indeed work as
> you suggest.
>
>
>
> I still see use of ‘fpround’ in the TDs for other targets AArch64, ARM,
> NVPTX, PowerPC and SystemZ.  Is there still a use for the old named ‘
> fpround’ and does it still exist with a new or refined semantic meaning,
> or is it just that these targets have not yet tracked the change?
>
>
>
> Certainly I am all in favour of regularising the names.
>
>
>
> All the best,
>
>
>
>             MartinO
>
>
>
> *From:* Nemanja Ivanovic [mailto:nemanja.i.ibm at gmail.com]
> *Sent:* 23 January 2017 12:42
> *To:* Martin J. O'Riordan <Martin.ORiordan at movidius.com>
> *Cc:* LLVM Developers <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Changes to TableGen in v4.0?
>
>
>
> I believe the node you're looking for is fpround.
>
> That one has a type profile with the source larger than the target. The
> fround does not - they have to be the same.
>
> I imagine this is a result of:
> ------------------------------------------------------------------------
> r279129 | mkuper | 2016-08-18 15:08:15 -0500 (Thu, 18 Aug 2016) | 8 lines
>
> [SelectionDAG] Rename fextend -> fpextend, fround -> fpround, frnd ->
> fround
>
> The names of the tablegen defs now match the names of the ISD nodes.
> This makes the world a slightly saner place, as previously "fround" matched
> ISD::FP_ROUND and not ISD::FROUND.
>
> Differential Revision: https://reviews.llvm.org/D23597
>
> ------------------------------------------------------------------------
>
>
>
> On Mon, Jan 23, 2017 at 12:41 PM, Martin J. O'Riordan via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I am trying to upgrade to the LLVM v4.0 branch, but I am seeing failures
> in my TableGen descriptions for conversion from FP32 to FP16 (scalar and
> vector).
>
>
>
> The patterns I have are along the lines of:
>
>
>
> [(set (f16 RF16:$dst), (fround (f32 RF32:$src)))]
>
> or:
>
> [(set (v2f16 VF16:$dst), (fround (v2f32 VF32:$src)))]
>
>
>
> and these now produce the errors:
>
>
>
> error: In CONV_f32_f16: Type inference contradiction found, merging 'f32'
> into 'f16'
>
> or:
>
> error: In CONV_v2f32_v2f16: Type inference contradiction found, merging
> 'v2f32' into 'v2f16'
>
>
>
> For the scalar version, the conflict is between two rules that have
> different mutually exclusive predicates (for alternative chip versions).
> But in the case of the vector, the conflict is for a vector of a different
> size, in the case:
>
>
>
> [(set (v4f16 VF16:$dst), (fround (v4f32 VF32:$src)))]
>
>
>
> and ‘CONV_v4f32_v4f16’.  What adjustments do I need to make to the TD
> descriptions to make these work again?  I know that FP16 is not hugely
> common on the mainstream platforms, but it is vital to ours.
>
>
>
> I did notice that ‘fextend’ was replaced by ‘fpextend’, is there some new
> ISD node type I should use for ‘fround’?
>
>
>
> Thanks,
>
>
>
>             MartinO
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170123/a54412cb/attachment.html>


More information about the llvm-dev mailing list