================ @@ -0,0 +1,30 @@ +//===--- ArbitraryFPFormats.def - Arbitrary FP format database --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// +// Source encodings exposed by the __builtin_elementwise_convert_from_* family. +// Src is the source half of the builtin name suffix; LLVMName is the +// llvm.convert.from.arbitrary.fp interpretation string. +// +// Each entry needs a matching instantiation in Builtins.td: expansions name +// builtin IDs directly, so a stale entry fails to compile. An entry must also +// be accepted by APFloat::getArbitraryFPSemantics, or lowering fails. +// +// The sub-byte encodings (Float6E3M2FN, Float6E2M3FN, Float4E2M1FN) lower but +// are not exposed; Clang cannot spell their vector element types coherently. ---------------- chinmaydd wrote:
As I understand it, #140253 allows power-of-two `_BitInt` vector elements, so `_BitInt(6)` vectors are still rejected. FP4 vectors can be declared, but Clang and LLVM disagree on their sizes. ``` typedef unsigned _BitInt(4) v8u4 __attribute__((ext_vector_type(8))); sizeof(v8u4) // 8: Clang gives each element a byte load <8 x i4>, ... // LLVM packs elements: 32 bits = 4 bytes ``` Scalar `_BitInt(6)` and `_BitInt(4)` would work but I lean towards leaning them out for now such that every exposed format supports both scalars and vectors. I've cleaned up the comment to specify the underlying problem. --- Also, filed https://github.com/llvm/llvm-project/issues/230878 https://github.com/llvm/llvm-project/pull/212647 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
