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

[Richard Guenther]

On Thu, Sep 6, 2012 at 5:51 PM, Richard Henderson <rth@redhat.com> 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.

Richard.

>
> r~