Re: RFA: Remove alias usage from libgcc/sync.c

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
>> On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
>>> asm(".alias __sync_synchronize sync_synchronize");
>>
>> It is .set, but not everywhere.
>> /* The MIPS assembler has different syntax for .set. We set it to
>>    .dummy to trap any errors.  */
>> #undef SET_ASM_OP
>> #define SET_ASM_OP "\t.dummy\t"
>> But perhaps it would require fewer variants than providing inline asm
>> of the __sync_* builtin by hand for all the targets that need it.
>
> Yeah, that's why I prefer the sed approach.  GCC knows how to do exactly
> what we want, and what syntax to use.  We just need to take its output and
> change the function name.
>
> And like Richard says, parsing top-level asms would be fair game,
> especially if GCC and binutils ever were integrated (for libgccjit.so).
> So using top-level asms seems like putting off the inevitable
> (albeit putting it off further than __asm renaming).
>
> Do either of you object to the sed thing?

Well, ideally there would be a way to not lie about symbol names to GCC.
That is, have a "native" way of telling GCC what to do here (which is
as far as I understand to emit the code for the builtin-handled $SYM
in a function with $SYM - provide the out-of-line copy for a builtin).

For the __sync functions it's unfortunate that the library function has
the same 'name' as the builtin and the builtin doesn't have an alternate
spelling.  So - can't we just add __builtin__sync_... spellings and use

__sync_synchronize ()
{
  __builtin_sync_syncronize ();
}

?  (what if __builtin_sync_syncronize expands to a libcall?  if it can't,
what's the point of the library function?)

Why does a simple

__sync_synchronize ()
{
  __sync_synchronize ();
}

not work?  On x86_64 I get from that:

__sync_synchronize:
.LFB0:
        .cfi_startproc
        mfence
        ret
        .cfi_endproc

(similar to how you can have a definition of memcpy () and have
another memcpy inside it inline-expanded)

Richard.

> Thanks,
> Richard