arch-specific template code
Paolo Carlini
paolo.carlini@oracle.com
Sat Sep 8 10:25:00 GMT 2012
Hi,
On 09/08/2012 12:12 PM, Marc Glisse wrote:
> On Sat, 8 Sep 2012, Paolo Carlini wrote:
>
>> On 08/28/2012 06:02 PM, Marc Glisse wrote:
>>> I can understand that, but it is nice to know exactly what is
>>> missing so we have a chance to get there eventually. __builtin_sqrt
>>> is a good example indeed. I thought masking was supposed to work
>>> (depending on what that means), although possibly only in C.
>> Marc, I think it would be very nice to have a record of these missing
>> features / weaknesses of the vector extensions. Since you know the
>> extensions pretty well by now, could you please double check whether
>> something is missing from Bugzilla,
>
> I think most of the features mentioned in this thread have a bugzilla
> entry.
>
> PR 54400: horizontal add
> PR 54408: sqrt
> PR 54422: unaligned load/store
> PR 54427: operator< and others in C++
>
> I posted a patch for 54427 and a RFC/patch for 54400 on x86 about a
> week ago (no answer yet).
Good, good. Remember to ping and always add in CC the right persons in
the first place.
>
>> possibly open a metabug, something like that?
>
> Hmm, it isn't obvious what the topic of the meta-bug would be. There
> are front-end parts (like 54427, I also think some way to generate
> VEC_COND_EXPR (i.e. ?: for vectors) would be nice), middle-end and
> back-end parts (optimize those vector operations). I don't think "all
> vector-related PRs" would do. Maybe "vector extension enhancements for
> libstdc++"?
I see. No, I don't think we want a metabug for the library-related work.
I was more thinking about generic limitations which every C/C++
programmer can experience. Well, we could have 3 metabugs, for
front-end, middle-end and back-end, referring each other, I would not
see anything wrong with that, but only if you think they would be useful
to clarify the current status.
Paolo.
More information about the Libstdc++
mailing list