Re: Cilk Library
On 10/02/13 13:40, Iyer, Balaji V wrote: Dear steering committee, To support the _Cilk_spawn, and _Cilk_sync implementation in GCC (patch submitted link: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we need to add a foreign library (Cilk Runtime Library) into the gcc repository. With this email, I am attaching the README file that will accompany Cilk Runtime Library (libcilkrts). I am also copy-pasting the header comment from one of the libcilkrts files. The header shown below will be in all the source files in libcilkrts. Does this look OK? I'm pleased to announce the steering committee approves the license terms for the Cilk+ runtime system as well as the plan to have the Cilk+ runtime maintained upstream by Intel and copied into the GCC repository. Given the runtime system will be maintained upstream by Intel, only a cursory review of the runtime system should be necessary -- basically stuff like ensuring it integrates into our build system, copyrights are in place and the like. Jeff
libgcc/sync.c vs. cgraph alias tracking
MIPS16 code can't do atomic operations directly, so it calls into out-of-line
versions that are compiled as -mno-mips16. These out-of-line versions use
the same open-coded implementation as you'd get in normal -mno-mips16 code.
This is done by libgcc/sync.c, which contains code like like:
static void
sync_synchronize (void)
{
__sync_synchronize ();
}
typeof (sync_synchronize) __sync_synchronize
__attribute__((alias ("sync_synchronize")));
With the recent cgraph changes, we follow the alias and the function becomes
an infinite loop.
The code above was always a bit of a hack, so it's not surprising it broke.
Is this a valid use of aliases? If not, can anyone think of a better
way of doing it? If so, any suggestions on how to fix it? I made a
couple of flailing attempts but they both caused other problems...
Sorry if this has already been reported btw.
Thanks,
Richard
Re: libgcc/sync.c vs. cgraph alias tracking
> MIPS16 code can't do atomic operations directly, so it calls into out-of-line
> versions that are compiled as -mno-mips16. These out-of-line versions use
> the same open-coded implementation as you'd get in normal -mno-mips16 code.
Hmm, and I assume you don't want to use target attribute for this...
>
> This is done by libgcc/sync.c, which contains code like like:
>
> static void
> sync_synchronize (void)
> {
> __sync_synchronize ();
> }
> typeof (sync_synchronize) __sync_synchronize
> __attribute__((alias ("sync_synchronize")));
>
> With the recent cgraph changes, we follow the alias and the function becomes
> an infinite loop.
Yep, here you define two symbols of same assembler name, so they will be
identified.
How exactly the code worked before?
Honza
>
> The code above was always a bit of a hack, so it's not surprising it broke.
> Is this a valid use of aliases? If not, can anyone think of a better
> way of doing it? If so, any suggestions on how to fix it? I made a
> couple of flailing attempts but they both caused other problems...
>
> Sorry if this has already been reported btw.
>
> Thanks,
> Richard
Re: libgcc/sync.c vs. cgraph alias tracking
Jan Hubicka writes:
>> MIPS16 code can't do atomic operations directly, so it calls into out-of-line
>> versions that are compiled as -mno-mips16. These out-of-line versions use
>> the same open-coded implementation as you'd get in normal -mno-mips16 code.
>
> Hmm, and I assume you don't want to use target attribute for this...
You mean so that any code that calls a __sync function would become
-mno-mips16? Yeah, we want to avoid that. There are specific mips16
and nomips16 attributes for setting the ISA mode, but the idea is to
allow functions to be compiled as -mips16 wherever possible.
>> This is done by libgcc/sync.c, which contains code like like:
>>
>> static void
>> sync_synchronize (void)
>> {
>> __sync_synchronize ();
>> }
>> typeof (sync_synchronize) __sync_synchronize
>> __attribute__((alias ("sync_synchronize")));
>>
>> With the recent cgraph changes, we follow the alias and the function becomes
>> an infinite loop.
>
> Yep, here you define two symbols of same assembler name, so they will be
> identified.
> How exactly the code worked before?
You'd know better than me how it worked before. :-) All I know is
that until the recent changes, the gimple optimisers didn't redirect
__sync_synchronize() to sync_synchronize(), so the original call
survived until expand and so got replaced with a sync instruction.
This is in contrast to:
void
__sync_synchronize (void)
{
__sync_synchronize ();
}
which the compiler always treated as an infinite loop. That's why
the alias indirect was used.
Thanks,
Richard
