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