https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106912
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
static tree
handle_pure_attribute (tree *node, tree name, tree ARG_UNUSED (args),
int ARG_UNUSED (flags), bool *no_add_attrs)
{
if (TREE_CODE (*node) == FUNCTION_DECL)
{
tree type = TREE_TYPE (*node);
if (VOID_TYPE_P (TREE_TYPE (type)))
warning (OPT_Wattributes, "%qE attribute on function "
"returning %<void%>", name);
DECL_PURE_P (*node) = 1;
/* ??? TODO: Support types. */
}
else
{
warning (OPT_Wattributes, "%qE attribute ignored", name);
*no_add_attrs = true;
}
meh.
I also question that we clear const/pure after instrumenting. We don't
do that for other instrumenting and it's only done for functions with
definitions but not functions in other (profile instrumented) TUs.
Edge counters do not alias anyway so that leaves for example
__gcov_time_profiler_counter which is updated like
# VUSE <.MEM_14>
PROF_time_profile_8 = __gcov_time_profiler_counterD.2013;
PROF_time_profile_9 = PROF_time_profile_8 + 1;
# .MEM_15 = VDEF <.MEM_14>
__gcov7.fooD.2016[0] = PROF_time_profile_9;
# .MEM_16 = VDEF <.MEM_15>
__gcov_time_profiler_counterD.2013 = PROF_time_profile_9;
the counter is public, external and static (eh?). We do eventually IPA
inline profile instrumented functions, but at least the above seems to be
at function end only.
That said, the const clearing doesn't have any effect, only the pure one
has.
It's possible to "fixup" in the vectorizer here but that's a hack for the
general inconsistency. The vectorizer can also build a const qualified
function type variant for the call fntype which might be a better fit but
then the simd clones use the exact same counters as the original function
which might or might not be intended ...
Honza - any comments on the pure/const difference for profile instrumented
code here? Do we need to "fix" the const case or can we drop the
pure/const state changes? It depends on that what the correct fix in
the vectorizer is.
