PATCH: __nodebug__ attribute for use on SSE intrinsic wrappers

Stuart Hastings
Fri Jul 29 20:20:00 GMT 2005

On Jul 29, 2005, at 12:52 PM, Daniel Berlin wrote:

>> But it's not a function!
> It's vec_add. It can be implemented as a function or a macro, just  
> like
> "max", "min", or a billion other things.
>> It's a /vector instruction/.  The function-call-esque syntax we've
>> saddled them with is just a distraction.  No vector coder I know
>> asked for this syntax.  I suppose a more natural syntax for SSE would
>> be "vector operators": imagine something like "v+", "v*", etc
> None of this is relevant.

If you think that "vec_add()" is the issue, you're right.  However,  
the folks that use these intrinsics don't think that way, and it's a  
bit arrogant for GCC to force the issue as it does.  Our users  
opinions should count for something...

>> Simply saying this
>>> is not the right way to go about this in a world where your debug
>>> info can easily
>>> tell you whether the called function is compiler made or not.
>> is /ducking the issue/.
> Not it's not.


I'll grant you the right to your opinions, but I find this argument  
unpersuasive.  Would you please elaborate?

>> GCC inflicted these wrapper functions on our
>> Developers, and GCC can be part of the solution.
> and Motorola inflicted the idea of overloading the hell out of the
> operators without bothering to go the extra 3 inches and just make  
> real
> C operators for vector types.

I'm sorry, I don't understand what Motorola has to do with this.

> What's your point?

A GCC implementation choice ("wrapper functions") has made it very  
difficult for vector coders to debug their software, and GCC should  
help fix the problem it has caused.

If GCC chose the equally valid (and intuitive) implementation of SSE  
via macros, this would not be an issue.  I have been asked do this  
(I'm still resisting).

> Omitting debug info for them is not the right solution for a format  
> like


>> Howabout we pick the name of this functionality ("artificial",
>> "intrinsic", "voodoo", "bogus", whatever :-) and apply it to the SSE
>> headers today; the initial STABS implementation can turn off debug
>> info, and DWARF can "Do The Right Thing," eventually.
> Who said you can't do this?
> Certainly not me.
> I said simply that "nodebug" is the wrong thing to do for a format  
> like
> DWARF, where your tool should be smart enough to know what was made up
> by the compiler, and what wasn't.

So it's the spelling of "nodebug" that's the issue?  Howabout  
Fariborz re-submits his patch, with s/nodebug/bogus/ ?  You can pick  
the new name.  (Imagine the possibilities:  "__attribute__  
((danberlin))"  :-):-):-)

>> Would you prefer rewriting the SSE intrinsics as macros?
> How would this help?

GDB/STABS is currently blind to C macros, so a Developer that says (n) 
ext inside GDB isn't sent to some random line in xmmintrin.h every time.

One of our vector coders has already rewritten a portion of  
*mmintrin.h as macros for exactly this reason.  His stuff will break  
when GCC alters some random __builtin_voodoo intrinsic someday.

> Sane formats have macro debugging info too.
> You currently can't step into a macro in GDB, but that's just an
> implementation issue.
> Someone could make it possible to display the macro you were  
> executing.

I've longed for this when trudging through GCC itself...  But today,  
we can, um, "leverage" this "feature" to help some SSE developers.  :-)


More information about the Gcc-patches mailing list