Re: [Xen-devel] [PATCH] x86/string: Use compiler builtins whenever possible

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/08/16 15:39, Jan Beulich wrote:
>>>> On 09.08.16 at 16:27, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 09/08/16 15:01, Jan Beulich wrote:
>>>>>> On 09.08.16 at 14:41, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> The use of -fno-builtin inhibits this automatic transformation.  Manually
>>>> tranform the callsites.  This causes constructs such as strlen("literal") 
>>>> to
>>>> be evaluated at compile time, and certain simple operations to be replaced
>>>> with repeated string operations.
>>> Iirc this was specifically avoided in at least older Linux because of
>>> compiler issues. Are you reasonably certain that those issues
>>> predate gcc 4.1.x (and don't exist at all in clang)? Other than that
>>> I'm of course fine with this patch.
>> Do you have any reference to these issues?  I cant find any reference.
> This was when I barley started working with Linux, i.e. in late 2.4.x
> or early 2.6.x times. Querying Google seems to indicate that
> someone reported successful use in 2.6.3.
>
>> I notice that Linux doesn't use these builtins, even today, but does
>> have arch specific implementations which are more efficient than our
>> common ones.  Still, it doesn't appear to be able to do any compile-time
>> evaluation.
> Isn't it surprising that no-one has submitted Linux patches to
> change that? Anyway, please consider the patch ack-ed. We
> can always revert it in case we run into problems (and once
> my hardware setup will be fully functional again, I will test with
> a reasonably old gcc anyway).

It turns out that in its current form, it breaks the clang build, citing

string.c:45:5: error: definition of builtin function '__builtin_strcasecmp'
int strcasecmp(const char *s1, const char *s2)
    ^
/local/xen.git/xen/include/asm/string.h:18:28: note: expanded from macro
'strcasecmp'
#define strcasecmp(s1, s2) __builtin_strcasecmp(s1, s2)
                           ^

which is something GCC clearly doesn't mind so much.

I will see about reworking it.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel