This is the mail archive of the
mailing list for the GCC project.
Re: RFA: Remove alias usage from libgcc/sync.c
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Fri, 11 Oct 2013 12:16:03 +0200
- Subject: Re: RFA: Remove alias usage from libgcc/sync.c
- Authentication-results: sourceware.org; auth=none
- References: <87ob6wp8oh dot fsf at talisman dot default> <CAFiYyc1cNcSgwXP4=OySk8d_3Wwx5uF4x=c3QEfjS_t3zsUZwg at mail dot gmail dot com> <20131011082136 dot GO30970 at tucnak dot zalov dot cz> <87bo2wta5l dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
> Jakub Jelinek <firstname.lastname@example.org> 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
? (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
not work? On x86_64 I get from that:
(similar to how you can have a definition of memcpy () and have
another memcpy inside it inline-expanded)