xiaoxiang781216 commented on code in PR #6132:
URL: https://github.com/apache/incubator-nuttx/pull/6132#discussion_r858573952
##########
include/nuttx/compiler.h:
##########
@@ -379,9 +379,11 @@
# if defined(__clang__)
# define no_builtin(n) __attribute__((no_builtin(n)))
-# else
+# elif (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) || (__GNUC__ > 4)
# define no_builtin(n)
__attribute__((__optimize__("-fno-tree-loop-distribute-patterns")))
Review Comment:
> Those are not an easy questions :)
>
> 1. I'm thinking that the more compiler specific can be moved to make
subsystem the better it is. But that is only my personal opinion.
> 2. Here it depends what should be the behaviour of the final system. I see
reasonable to apply it to all the files because it is not logical to me that
NuttX provides implementation for `memcpy`, but some parts of the system use it
while other use builtin version.
I think builtin here mean that compiler can assume these special functions
implement the behavior defined by standard, so the compiler can do more
optimization(e.g. replace memcpy with load/store instruction). but these
built-in functions can be implemented by anyone(e.g. glibc, musl, newlib, or
nuttx).
> I mean that we can have an option either to use NuttX `memcpy` or builtin
`memcpy` but not the mix. But again this is a point for discussion and maybe
I'm missing the bigger picture.
Even we provide some option to skip compile these builtin function, there is
still many other functions(e.g. open/close, malloc/free) duplicated in the
third party library(e.g. newlib) and nuttx. It's hard to tell the linker pull
memcpy... from 3rd party library and malloc/fopen... from nuttx.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
