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