================
@@ -704,6 +725,25 @@ template <typename ArgProvider> class Parser {
 #endif // LIBC_COPT_PRINTF_DISABLE_INDEX_MODE
 };
 
+#ifdef LIBC_PRINTF_DEFINE_MODULES
+#define HANDLE_ARG_LIST_TYPE(TYPE)                                             
\
+  template void Parser<internal::TYPE>::write_float_arg_val(                   
\
+      FormatSection &section, LengthModifier lm, size_t conv_index);
+#include "src/__support/arg_list_types.def"
+#undef HANDLE_ARG_LIST_TYPE
+
+#define HANDLE_ARG_LIST_TYPE(TYPE)                                             
\
+  template TypeDesc Parser<internal::TYPE>::float_type_desc(LengthModifier lm);
+#include "src/__support/arg_list_types.def"
+#undef HANDLE_ARG_LIST_TYPE
+
+#define HANDLE_ARG_LIST_TYPE(TYPE)                                             
\
+  template bool Parser<internal::TYPE>::advance_arg_if_float(                  
\
+      TypeDesc cur_type_desc);
+#include "src/__support/arg_list_types.def"
+#undef HANDLE_ARG_LIST_TYPE
+#endif
----------------
michaelrj-google wrote:

could you expand a bit more on why this is necessary? It seems like this 
mechanism exists to allow the parser, when in modular mode, to completely 
remove any reference to floating point numbers. That does seem like it'll save 
a bit of code size but at the cost of significant complexity (as seen here). 
Would it be okay for the parser handling of floats to be included 
unconditionally? No mathematical operations are performed so there shouldn't be 
any libcalls generated even for soft float systems. Additionally, the float 
`TypeDesc` doesn't actually involve any floats, it's just a helper struct with 
basic type information.

https://github.com/llvm/llvm-project/pull/147426
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to