Martin Sebor <mse...@gmail.com> writes: > Can this option be used in attribute optimize? If yes, what's > the advantage of also providing an atttribute?
Compatibility with the clang attribute.
> It seems to me that as a matter of QOI, GCC should be able to
> disable the expansion of built-ins to calls to themselves in
> their bodies (I would view it as a bug if GCC expanded a byte
> copying loop into a call to __builtin_memcpy in the body of
> a function named memcpy, without issuing a warnings; but even
> with a warning I'd hope it to do the sensible thing and avoid
> introducing infinite recursion).
That's a pretty sensible plan and would resolve many of the issues
caused by these optimizations while implementing libc itself. Of course,
that wouldn't fix other places where the compiler is using knowledge of
builtin semantics to drive optimization (like the memset call before
free).
> A compiler may not be able
> to do that in calls made from those functions, and for that
> the built-in expansion needs to be disabled explicitly.
> -fno-builtin isn't good enough because it doesn't prevent GCC
> from introiducing calls to __builtin_ functions, and that's
> what this feature is for. Do I understand correctly?
-fno-builtin has two problems:
1. Cannot be used in source code, only on the command line.
2. Also disables explicit use of builtin functions.
> If we end up adding a new attribute (as opposed to relying
> on attribute optimize) and the attribute is expected to have
> an effect only on the definitions of functions and not also
> on their callers, I would suggest to consider having
> the handler check that it is, in fact, on a definiton and
> not a declaration and issuing a warning that it has no effect
> on a declaration, to avoid misunderstandings.
Hrm. I copied the code from the 'optimize' attribute to make this have
the same effect; as above, this new attribute offers clang compatibility
for something that can also be done with the existing optimize
attribute.
> If either a new attribute or a new option is introduced they
> need to be documented in the manual. From your description
> it's not clear to me if it's just about disabling the expansion
> of the built-ins or if it's meant to prevent GCC from making
> any assumptions about their semantics in calls to the annotated
> functions. That will likely be of interest to users and it
> matters for diagnostics.
Yes, I definitely need to add documentation. I'm actually using this
thread to help clarify precisely what those semantics should be; it's a
pretty subtle operation when compared with -fno-builtin.
> We will also need to add tests for the feature. There are many
> built-ins in GCC but the patch only affects a small subset of
> them (e.g., I see it affects a few stdio and string functions
> but I'm not sure the printf family are among them -- all those
> handled in gimple-ssa-sprintf.c).
Yeah, I can get started on tests.
Keeping this operation from affecting things that it shouldn't while
hitting everything it should is a bit more difficult than I had hoped; I
suspect we'll be finding cases for some time unless I can discover an
easier place to hook this into.
> Besides its effect on codegen, I would also hope for a few test
> cases for warnings, those issued by the strlen pass in particular,
> to make sure their effects either are preserved or are disabled
> (whichever is appropriate).
Because the goal is to have the optimizer "forget" about the semantics of
builtins, but let them still be used when explicitly named in the code,
these warnings would still need to be enabled, so I left them in.
I think we need to get a clear description of what this attribute should
do before making many more changes in the code. Here's a first stab:
no_builtin
This attribute directs GCC to not use knowledge of the semantics
of built-in functions to direct code optimization. GCC will not
add or remove usage of builtin functions, or restructure code in
ways that depend on built-in knowledge of their
operation. Explicit use of builtin functions will still use any
internal implementations.
In contrast to -fno-builtin, the no_builtin attribute does not
disable declaration of the built-in functions, so messages
related to use and definition will still be enabled, and they
can still be used when named explicitly. In addition, the
no_builtin attribute can be applied on a function-at-a-time
level, while -fno-builtin must be specified on the command line.
--
-keith
signature.asc
Description: PGP signature
