-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[clang] "modular_format" attribute for functions using format strings #147431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: users/mysterymath/modular-printf/ir
Are you sure you want to change the base?
Changes from all commits
3ac7481
009666f
15c4fc0
e2af60f
4083c98
a0bf190
51b2ad3
1b9cdfd
cfe7065
cfa9c2b
b148035
ef62829
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2557,6 +2557,20 @@ void CodeGenModule::ConstructAttributeList(StringRef Name, | |
|
|
||
| if (TargetDecl->hasAttr<ArmLocallyStreamingAttr>()) | ||
| FuncAttrs.addAttribute("aarch64_pstate_sm_body"); | ||
|
|
||
| if (auto *ModularFormat = TargetDecl->getAttr<ModularFormatAttr>()) { | ||
| // TODO: Error checking | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a heck of a TODO :) Though, I'd expect us to do diagnostics during our normal checking of the format string, so we shouldn't really require anything here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hah, fair; this is very much a Draft PR. My intent was to get this in front of a bunch of eyes sooner rather than later, as this PR set touches everything every layer from the compiler through to libc (skipping the linker). |
||
| FormatAttr *Format = TargetDecl->getAttr<FormatAttr>(); | ||
| StringRef Type = Format->getType()->getName(); | ||
| std::string FormatIdx = std::to_string(Format->getFormatIdx()); | ||
| std::string FirstArg = std::to_string(Format->getFirstArg()); | ||
| SmallVector<StringRef> Args = { | ||
| Type, FormatIdx, FirstArg, | ||
| ModularFormat->getModularImplFn()->getName(), | ||
| ModularFormat->getImplName()}; | ||
| llvm::append_range(Args, ModularFormat->aspects()); | ||
| FuncAttrs.addAttribute("modular-format", llvm::join(Args, ",")); | ||
| } | ||
| } | ||
|
|
||
| // Attach "no-builtins" attributes to: | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| // RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s | ||
|
|
||
| int printf(const char *fmt, ...) __attribute__((modular_format(__modular_printf, "__printf", "float"))); | ||
| int myprintf(const char *fmt, ...) __attribute__((modular_format(__modular_printf, "__printf", "float"), format(printf, 1, 2))); | ||
|
|
||
| // CHECK-LABEL: define dso_local void @test_inferred_format( | ||
| // CHECK: {{.*}} = call i32 (ptr, ...) @printf(ptr noundef @.str) #[[ATTR:[0-9]+]] | ||
| void test_inferred_format(void) { | ||
| printf("hello"); | ||
| } | ||
|
|
||
| // CHECK-LABEL: define dso_local void @test_explicit_format( | ||
| // CHECK: {{.*}} = call i32 (ptr, ...) @myprintf(ptr noundef @.str) #[[ATTR:[0-9]+]] | ||
| void test_explicit_format(void) { | ||
| myprintf("hello"); | ||
| } | ||
|
|
||
| int redecl(const char *fmt, ...) __attribute__((modular_format(__first_impl, "__first", "one"), format(printf, 1, 2))); | ||
| int redecl(const char *fmt, ...) __attribute__((modular_format(__second_impl, "__second", "two", "three"))); | ||
|
|
||
| // CHECK-LABEL: define dso_local void @test_redecl( | ||
| // CHECK: {{.*}} = call i32 (ptr, ...) @redecl(ptr noundef @.str) #[[ATTR_REDECL:[0-9]+]] | ||
| void test_redecl(void) { | ||
| redecl("hello"); | ||
| } | ||
|
|
||
| // CHECK: attributes #[[ATTR]] = { "modular-format"="printf,1,2,__modular_printf,__printf,float" } | ||
| // CHECK: attributes #[[ATTR_REDECL]] = { "modular-format"="printf,1,2,__second_impl,__second,three,two" } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| //RUN: %clang_cc1 -fsyntax-only -verify %s | ||
|
|
||
| #include <stdarg.h> | ||
|
|
||
| int printf(const char *fmt, ...) __attribute__((modular_format(__modular_printf, "__printf", "float"))); // no-error | ||
| int myprintf(const char *fmt, ...) __attribute__((modular_format(__modular_printf, "__printf", "float"))); // expected-error {{'modular_format' attribute requires 'format' attribute}} | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So will any call to
printfwith a constant format specifier string be rewritten to call__modular_printf?Also, who is responsible for writing these attributes? Are they only in the libc implementation, or can a user write one of these themselves on their own declarations? I'm asking because I wonder about compatibility; e.g., the call dispatches to
__modular_printfbut that doesn't know about some particular extension being used in the format specifier and so the code appears to misbehave.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct.
Users could use these for their own implementations, in particular to allow functions that e.g. wrap
vsnprintfto do logging etc. As for compatibility, if the compiler understands aspect names that the implementation doesn't, there's no issue, as the compiler will not spontaneously emit them if not requested. If an implementation requests a verdict on an implementation aspect unknown to the compiler, the compiler will conservatively report that the aspect is required. Themodular_formatattribute provided by the code and the aspect references emitted by the compiler thus form a sort of two-phase handshake between the code and compiler.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to know, thanks!
My concern is more about dispatching in ways the user may not anticipate and getting observably different behavior. e.g., the user calls
printf("%I64d", 0LL)and they were getting the MSVC CRTprintfcall which supported that modifier but now calls__modular_printfwhich doesn't know about the modifier. What happens in that kind of situation?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, if I understand what you're getting at, that can't happen: it's explicitly out of scope for the feature.
The
modular_formatattribute exists to advertise to compiler that is compiling calls to a function that the implementation can be split by redirecting calls and emitting relocs to various symbols. A header file is the only plausible mechanism to tell the compiler this, and that means that the header would need to be provided by and intrinsically tied to a specific version of the implementation. Otherwise, it would be impossible to determine what aspects the implementation requires to be emitted to function correctly.Accordingly, this feature would primarily be useful for cases where libc is statically linked in and paired with its own headers. (llvm-libc, various embedded libcs, etc.) I suppose it's technically possible to break out printf implementation parts into a family of individual dynamic libraries, but even then, any libc header set that required that the libc implementation be dynamically replaceable would not be able to include
modular_format.So, for implementations that use this feature,
printfand__modular_printfwould always be designed together. To avoid ever introducing two fullprintfimplementations into the link,printfwould be a thin wrapper around__modular_printfthat also requests every possible aspect of the implementation. This would mean that the two could never diverge.As an aside, this is my first time landing a RFC across so many components of LLVM. I wasn't sure how much detail to include in each change; my intuition was to try to provide links to the RFC instead. I don't want the above reasoning to get buried, and it gives me pause that it wasn't readily accessible. But I'm also not entirely sure where it should live going forward. Advice would be appreciated.