public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: "H.J. Lu" <hjl.tools@gmail.com>,
	Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] elf: Remove -fno-tree-loop-distribute-patterns usage on dl-support
Date: Wed, 10 Aug 2022 10:12:59 -0300	[thread overview]
Message-ID: <86e720fc-2586-22c3-5e1d-e29a48dce46d@linaro.org> (raw)
In-Reply-To: <CAMe9rOp=8g8r-vUGRvWk7pri1EohsWeNniN89ive594Rb2RqkA@mail.gmail.com>



On 09/08/22 18:51, H.J. Lu wrote:
> On Tue, Aug 9, 2022 at 12:40 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 09/08/22 16:34, H.J. Lu wrote:
>>> On Tue, Aug 9, 2022 at 12:32 PM Adhemerval Zanella Netto
>>> <adhemerval.zanella@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 09/08/22 16:06, H.J. Lu wrote:
>>>>> On Tue, Aug 9, 2022 at 11:48 AM Adhemerval Zanella Netto
>>>>> <adhemerval.zanella@linaro.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/08/22 15:31, H.J. Lu wrote:
>>>>>>> On Tue, Aug 9, 2022 at 5:11 AM Adhemerval Zanella Netto
>>>>>>> <adhemerval.zanella@linaro.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/08/22 19:16, H.J. Lu wrote:
>>>>>>>>
>>>>>>>>>> --- a/sysdeps/x86_64/multiarch/memset-evex-unaligned-erms.S
>>>>>>>>>> +++ b/sysdeps/x86_64/multiarch/memset-evex-unaligned-erms.S
>>>>>>>>>> @@ -44,4 +44,7 @@
>>>>>>>>>>
>>>>>>>>>>  # define USE_LESS_VEC_MASK_STORE       1
>>>>>>>>>>  # include "memset-vec-unaligned-erms.S"
>>>>>>>>>> +# if !defined NO_MULTIARCH && MINIMUM_X86_ISA_LEVEL >= 4
>>>>>>>>>> +strong_alias (__memset_evex_unaligned, __memset_generic)
>>>>>>>>>> +# endif
>>>>>>>>>>  #endif
>>>>>>>>>
>>>>>>>>> This will define 2 __memset_generic for -march=x86-64-v4.
>>>>>>>>
>>>>>>>> Are you sure? Check with a x86_64 build with -march=x86-64-v4 I am seeing:
>>>>>>>>
>>>>>>>> $ readelf -Ws string/memset*.os | grep -w __memset_generic | wc -l
>>>>>>>> 1
>>>>>>>>
>>>>>>>> And it is indeed provided only by string/memset-evex-unaligned-erms.os.
>>>>>>>
>>>>>>> You are right.  Since dl-symbol-hacks.h defines memset to an alias,
>>>>>>> should it be moved to sysdes/generic and each arch can provide a
>>>>>>> suitable alias?
>>>>>>
>>>>>> The dl-symbol-hacks.h is meant to be used solely by loader code (that's
>>>>>> why I have added to elf/), but I don't have a strong preference.
>>>>>
>>>>> The default should be no alias.  Only IFUNC targets need to define a
>>>>> proper alias.
>>>>
>>>> Alright, although I added the alias on all targets to avoid adding another
>>>> hook to specify whether memset is implemented by IFUNC (to enable the
>>>> symbol redirection instead of use the default symbol name).  I am not sure
>>>> if making arch-specific will simplify the required code here.
>>>
>>> But your patch adds alias to all targets.
>>
>> Yes, because otherwise we will need something like HAVE_MEMSET_IFUNC to add:
>>
>> #if defined SHARED && HAVE_MEMSET_IFUNC
>> asm ("memset = __memset_generic");
>> #endif
>>
>> I don't have a strong preference, although it is another this will require
>> to have kernel-features.h (which we usually add the HAVE_*) on elf objects.
> 
> There are
> 
> elf/Makefile:CFLAGS-dl-tunables.c += -fno-tree-loop-distribute-patterns
> elf/Makefile:CFLAGS-rtld.c += -fno-tree-loop-distribute-patterns

Unfortunately we can't really remove these two without refactoring the code to
avoid the memset constructions because functions call are not really allowed.

For dl-tunables.c I am not sure if we actually need to filter out the invalid
options to create a new tunable, since we already do not set them for glibc
itself.  The program will see the original value, but it show not matter since
glibc would already have handle it anyway and it might avoid the need to strdup 
the GLIBC_TUNABLES.

> elf/Makefile:CFLAGS-dl-support.c = -fno-tree-loop-distribute-patterns
> include/libc-symbols.h:    __attribute__ ((__optimize__
> ("-fno-tree-loop-distribute-patterns")))

We need this to void the memset recursion when gcc see the memset implementation
as memset itself.

> string/test-string.h:    __attribute__ ((__optimize__
> ("-fno-tree-loop-distribute-patterns")))
> 
> There should be no check on SHARED.   It can be something like
> 
> #define SYMBOL_STR1(s) #s
> #define SYMBOL_STR(s) SYMBOL_STR1(s)
> 
> #ifdef DEFAULT_MEMSET
> asm ("memset = " _SYMBOL_STR (DEFAULT_MEMSET));
> #endif

Yeah, it could work.  I will redo based on this, it should simplify the changes
for other ports.


  reply	other threads:[~2022-08-10 13:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08 20:00 Adhemerval Zanella
2022-08-08 22:16 ` H.J. Lu
2022-08-09 12:11   ` Adhemerval Zanella Netto
2022-08-09 18:31     ` H.J. Lu
2022-08-09 18:48       ` Adhemerval Zanella Netto
2022-08-09 19:06         ` H.J. Lu
2022-08-09 19:32           ` Adhemerval Zanella Netto
2022-08-09 19:34             ` H.J. Lu
2022-08-09 19:40               ` Adhemerval Zanella Netto
2022-08-09 21:51                 ` H.J. Lu
2022-08-10 13:12                   ` Adhemerval Zanella Netto [this message]
2022-08-10  3:37 ` Noah Goldstein
2022-08-10 13:04   ` Adhemerval Zanella Netto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86e720fc-2586-22c3-5e1d-e29a48dce46d@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@gotplt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).