This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Merging Cilk Plus into Trunk (Patch 1 of approximately 22)


On Tue, Sep 11, 2012 at 4:06 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Sep 11, 2012 at 03:57:44AM -0500, Gabriel Dos Reis wrote:
>> On Tue, Sep 11, 2012 at 3:42 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>
>> > Btw, this then happily fits into my suggestion that the "elementalness"
>> > can be autodetected by the compiler simply by means of a proper IPA
>> > pass and thus be fully LTO / whole-program aware.  No need for an
>> > attribute (where you'd need to handle the case that the attribute was placed
>> > there by error).
>>
>> We are in violent agreement.
>
> For locally defined functions sure, the question is if we want the attribute
> to be something for external functions.  Something that would have ABI
> implications (the external symbol would need to be provided in two forms (or
> more?), one scalar with normal mangling, one vector with some other kind
> of mangling/suffix/whatever), when compiling the definition of function with
> such an attribute the compiler could verify its properties (i.e. autodetect
> and if it is not autodetected elemental, complain?), and when using extern
> function just rely on it being provided twice.  Even with LTO, the function
> can be defined in some other shared library etc.
>
> Nothing says the implementation of the vector version of the elemental
> function necessary has to be vectorized, just that the arguments would need
> to be passed in the expected vector registers, similarly for return value.
> Say if the elemental function is compiled with -O0, then there could just be
> a loop executing the scalar body several times and creating vectors.
>

As it was pointed out earlier (by Marc?), there is also an issue of overload
resolution if these automatically synthetized functions have to be something
visible, which of course entails the whole ABI issues.  This is really
a language
design issue, not just compiler implementation.   If the synthetized functions
do not need to have the same status as real functions (hence no need for
attributes), then these issues evaporate.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]