Changes to TableGen in v4.0?

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

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:

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

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.