Hello Richard,
Please see my response below:
>-----Original Message-----
>From: Richard Guenther [mailto:[email protected]]
>Sent: Friday, September 07, 2012 5:15 AM
>To: Richard Henderson
>Cc: [email protected]; Gabriel Dos Reis; Iyer, Balaji V; Aldy Hernandez
>([email protected]); Jeff Law
>Subject: Re: [PATCH] Merging Cilk Plus into Trunk (Patch 1 of approximately 22)
>
>On Thu, Sep 6, 2012 at 5:51 PM, Richard Henderson <[email protected]> wrote:
>> On 09/06/2012 02:37 AM, Richard Guenther wrote:
>>> In all this seems unrelated to CILK+ work (even if you make use of
>>> this from within CILK+).
>>
>> While true, we also asked him to split up the work. And this piece,
>> done correctly, seems useful even if the rest of cilk is ignored.
>
>Sure. When viewed independent of cilk then interpreting libm routines as
>elemental and appropriately matching that with the -mveclibabi support we have
>would be nice. -mveclibabi would specify how to mangle an assembler name to
>yield the vector elemental function (and thus be target dependent and
>eventually
>library ABI dependent) and the vectorizer would for each elemental function be
>able to get at a vectorized decl by means of the existing target hook (of which
>parts of it could then be lifted to generic code).
>
>Making GCC auto-generate vector variants should be done only when the
>definition is visible (for example through LTO). That would basically mean to
>implement inter-procedural vectorization support. That side-steps all ABI
>issues
>as the functions will be internal only. Not sure if that is enough for Cilk+
>requirements though.
I hope I have not mistaken your question, but to clarify the elemental
function's definition and body is visible to all passes after the invocation of
gimplify_function_tree (). It is also visible for the LTO optimization.
>
>Richard.
>
>>
>> r~
