[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7f06eb4a5b44ce29718341e28c823f8@AcuMS.aculab.com>
Date: Thu, 31 Aug 2023 08:37:11 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Zhangjin Wu' <falcon@...ylab.org>
CC: "ammarfaizi2@...weeb.org" <ammarfaizi2@...weeb.org>,
"arnd@...db.de" <arnd@...db.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"tanyuan@...ylab.org" <tanyuan@...ylab.org>,
"thomas@...ch.de" <thomas@...ch.de>, "w@....eu" <w@....eu>
Subject: RE: [RFC] tools/nolibc: replace duplicated -ENOSYS return with single
-ENOSYS return
...
> We also need this style of checking for the delta logic in __atoi_add(). have
> randomly tried different clang and gcc versions, seems all of them work
> correctly, but the compiling speed is not that good if we want to support the
> worst cases like "((0x900000 + 0x0f0000) + 5)", the shorter one
> "((0x900000+0x0f0000)+5)" is used by ARM+OABI (not supported by nolibc
> currently), therefore, we can strip some tailing branches but it is either not
> that fast, of course, the other architectures/variants can use faster
> __atoi_add() versions with less branches and without hex detection, comparison
> and calculating.
If there are only a few prefix offsets then the code can be optimised
to explicitly detect them - rather than decoding arbitrary hex values.
After all it only needs to decode the values that actually appear.
The code also needs a compile-time assert that the result
is constant (__buitin_constant_p() will do the check.
But you can't use _Static_assert() to report the error
because that requires an 'integer constant expression'.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists