[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Nov 4, 2021)
Hi all, There is an agenda for tomorrow's meeting. If you have topics to discuss or share, please let me know and I can add them to the agenda. Agenda: 1. Progress of RISC-V sub-extension supports 2. Open Discussion Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. Topic: RISC-V GNU Toolchain Biweekly Sync-up Join Zoom Meeting https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 Meeting ID: 893 9360 0951 Passcode: 899662 BEIJING, China 11:00pThu, Nov 4 2021 12:00aFri, Nov 5 2021 PDT/PST, Pacific Daylight Time (US) 8:00aThu, Nov 4 2021 9:00aThu, Nov 4 2021 PHILADELPHIA, United States, Pennsylvania 11:00aThu, Nov 4 2021 12:00pThu, Nov 4 2021 PARIS, France 4:00pThu, Nov 4 2021 5:00pThu, Nov 4 2021 Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://zoom.us/meeting/tZ0ufuqurjsjH9XTthkNg3MffX-QsRBuVBET/ics?icsToken=98tyKuGhrTIpHNSVuRyGRpx5A4r4b-7ziGJEgvplqAvtCA5UMS7wMNoPA6FNMs3m -- Best wishes, Wei Wu (吴伟)
Re: [PATCH] Add 'no_builtin' function attribute
On 11/2/21 3:14 PM, Keith Packard via Gcc-patches wrote:
This attribute controls optimizations which make assumptions about the
semantics of builtin functions. Typical cases here are code which
match memcpy, calloc, sincos, or which call builtins like free.
This extends on things like the -ftree-loop-distribute-patterns
flag. That flag only covers converting loops into builtin calls, not
numerous other places where knowledge of builtin function semantics
changes the generated code.
The goal is to allow built-in functions to be declared by the compiler
and used directly by the application, but to disable optimizations
which take advantage of compiler knowledge about their semantics, and
to allow this optimization behavior to be changed for individual
functions.
One place where this behavior is especially useful is when compiling
the builtin functions that gcc knows about, as in the C
library. Currently, C library source code and build systems have
various kludges to work around the compilers operations in these
areas, using a combination of -fno-tree-loop-distribute-patterns,
-fno-builtins and even symbol aliases to keep GCC from generating
infinite recursions.
This can be applied globally to a file using the -fno-optimize-builtin
flag.
Can this option be used in attribute optimize? If yes, what's
the advantage of also providing an atttribute?
A few more comments below.
This disables optimizations which translate a sequence of builtin calls
into an equivalent sequence:
void
attribute((no_builtin))
sincos(double x, double *s, double *c)
{
*s = sin(x);
*c = cos(x);
}
This also avoids converting loops into builtin calls like this:
void *
attribute((no_builtin))
memcpy(void *__restrict__ dst, const void *__restrict__ src, size_t n)
{
char *d = dst;
const char *s = src;
while (n--)
*d++ = *s++;
return dst;
}
As well as disabling analysis of memory lifetimes around free as in
this example:
void *
attribute((no_builtin))
erase_and_free(void *ptr)
{
memset(ptr, '\0', malloc_usable_size(ptr));
free(ptr);
}
It also prevents converting builtin calls into inline code:
void
attribute((no_builtin))
copy_fixed(char *dest)
{
strcpy(dest, "hello world");
}
Clang has a more sophisticated version of this mechanism which
can disable specific builtins:
double
attribute((no_builtin("exp2")))
exp2(double x)
{
return pow (2.0, x);
}
The general approach in this change is to introduce checks in some
places where builtin functions are used to see if the specific
function is 'allowed' to be used for optimization, skipping the
optimization when the desired function has been disabled.
Three new functions, builtin_decl_implicit_opt_p,
builtin_decl_explicit_opt and builtin_decl_implicit_opt are introduced
which add checks for whether the compiler can assume standard
semantics for the specified function for purposes of
optimization. These are used throughout the compiler wherever
appropriate. Code which must use builtins for correct operation
(e.g. struct assignment) are not affected.
The machinery proposed here could be extended to support the
additional clang feature by extending the attribute parsing function
and creating a list of disabled builtins checked by the builtin_decl
functions described above.
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). 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?
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.
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 G
Re: [PATCH] Add 'no_builtin' function attribute
Martin Sebor 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
does TARGET_MEM_REF documentation need updating?
The manual says that the first argument of a TARGET_MEM_REF
"is @code{TMR_SYMBOL} and must be a @code{VAR_DECL} of an object
with a fixed address."
The TARGET_MEM_REF below has as its first argument an ADDR_EXPR
and not a VAR_DECL as the manual claims. The code I looked at
seems to be prepared for the first argument to be pretty much
any address, including an SSA_NAME. What should the manual be
updated to, to make it accurate?
The description also says:
The second argument is @code{TMR_BASE} and the third one is
@code{TMR_INDEX}.
and gives the formula below to compute its address:
&TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
The second argument of my TARGET_MEM_REF is a pointer and not
something I'd expect to see added to the address of something.
Is the second argument meant to have a dual purpose like in
a MEM_REF?
Thanks
Martin
type 0x7fffe7c0fd20 tree_node>
sizes-gimplified public unsigned type_6 DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7fffe7c0fdc8
pointer_to_this
reference_to_this >
readonly sizes-gimplified unsigned DI size 0x7fffea7f5f48 64> unit-size
user align:128 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7fffe6836dc8>
readonly
arg:0
public unsigned DI size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7fffe4b2d540>
readonly constant
arg:0 0x7fffe6836348>
readonly used static tree_1 tree_2 tree_6 read decl_5
decl_6 BLK /src/gcc/trunk/gcc/c-family/c-common.c:301:26
size
unit-size
align:256 warn_if_not_align:0 context
initial
chain >>
arg:1 0x7fffe666a3f0> constant 0>
arg:2 type type_6 DI size unit-size 0x7fffea7f5f60 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7fffea815000 precision:64 min 0x7fffea7f5f78 0> max >
visited
def_stmt _6 = ivtmp.4177_35 * 16;
version:6
ptr-info 0x7fffe63de020>>
