Re: Backtrace library [1/3]
On Sep 11, 2012, at 4:24 PM, Ian Lance Taylor wrote: > On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner wrote: >> >> FYI, "backtrace" is a well-known function provide by glibc (and other >> libc's). It might be best to pick another name. > > Good point. Thanks. I renamed it to backtrace_full. I've included > the updated backtrace.h here. The other changes are mechanical. What do you think of (poor man's) namespacification? You could prefix symbols with "libbacktrace_", which I think is much less likely to conflict, and be much more clear to clients. -Chris
Re: Backtrace library [1/3]
On Sep 11, 2012, at 3:53 PM, Ian Lance Taylor wrote: > I have finished the initial implementation of the backtrace library I > proposed at http://gcc.gnu.org/ml/gcc/2012-08/msg00317.html . I've > separated the work into three patches. These patches only implement the > backtrace library itself; actual use of the library will follow in > separate patches. Hi Ian, I have no specific comment on the implementation of this library, but: > > +/* Get a full stack backtrace. SKIP is the number of frames to skip; > + passing 0 will start the trace with the function calling backtrace. > + DATA is passed to the callback routine. If any call to CALLBACK > + returns a non-zero value, the stack backtrace stops, and backtrace > + returns that value; this may be used to limit the number of stack > + frames desired. If all calls to CALLBACK return 0, backtrace > + returns 0. The backtrace function will make at least one call to > + either CALLBACK or ERROR_CALLBACK. This function requires debug > + info for the executable. */ > + > +extern int backtrace (int skip, backtrace_callback callback, > + backtrace_error_callback error_callback, void *data); FYI, "backtrace" is a well-known function provide by glibc (and other libc's). It might be best to pick another name. -Chris
Re: Vector shuffling
On Aug 31, 2011, at 1:27 AM, Artem Shinkarov wrote: >> If you're going to add vector shuffling builtins, you might consider adding >> the same builtin that clang has for compatibility: >> http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector >> >> It should be straight-forward to map it into the same IR. >> >> -Chris >> > > Chris > > I am trying to use OpenCL syntax here which says that the mask for > shuffling is a vector. Also I didn't really get from the clang > description if the indexes could be non-constnants? If not, then I > have a problem here, because I want to support this. Yes, constant elements are required for this builtin. It is an implementation detail, but Clang doesn't implement the OpenCL shuffle operations with builtins. -Chris
Re: Vector shuffling
On Aug 30, 2011, at 10:01 AM, Artem Shinkarov wrote:
>>> The patch at the moment lacks of some examples, but mainly it works
>>> fine for me. It would be nice if i386 gurus could look into the way I
>>> am doing the expansion.
>>>
>>> Middle-end parts seems to be more or less fine, they have not changed
>>> much from the previous time.
>>
>> +@code{__builtin_shuffle (vec, mask)} and
>> +@code{__builtin_shuffle (vec0, vec1, mask)}. Both functions construct
>>
>> the latter would be __builtin_shuffle2.
>
> Why??
> That was the syntax we agreed on that elegantly handles both cases in one
> place.
If you're going to add vector shuffling builtins, you might consider adding the
same builtin that clang has for compatibility:
http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector
It should be straight-forward to map it into the same IR.
-Chris
