Re: PATCH: __nodebug__ attribute for use on SSE intrinsic wrappers

[Daniel Berlin <dberlin at dberlin dot org>]

> 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...

If we followed every bad implementation idea choice someone else ever
made, we'd be in serious trouble.

> 
> >> 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.
> 
> Sigh.
> 
> I'll grant you the right to your opinions, but I find this argument  
> unpersuasive.  Would you please elaborate?

Sure.
These are function-like macros.
They can be implemented as either functions or macros.
Pretending they don't exist entirely in the debug info so that your
*profiling tools* look better is *wrong*.
They do exist.
If your profiling tools want to ignore them, ignore them.

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

It has the same amount of relevance as your complaint that we chose one
implementation method over another.

> 
> > 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.

Nobody has said otherwise.
The *only* problem people have had is that the fix is not "do not ever
output debug info for these functions".
I don't know how much clearer i can be that for things besides STABS,
that have a way of expressing that these are compiler generated
functions, this is the *WRONG ANSWER*.

vec_add is no different than *any other compiler generated function*,
like a generated C++ constructor.

If the debugger, profiler, or anything else wants to ignore them,
*fine*.

If your debug info format doesn't support such a way of saying they are
compiler generated functions, and you want to omit the info, I still
think it's a bad idea, but i'm more than willing to bend here and say
*fine*.

You can claim this information is never valuable to anyone till you are
blue in the face, and i will tell you there are users who care. Simply
because you do not see them or here from them right now, does not make
this true.

Also, on a general principle, having an attribute to not emit debug info
for certain functions is a bad idea, because users will expect it to
work in all weird cases that you aren't going to deal with right now, or
implement ever.
> O.K.
> 
> >> 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? 

The primary issue is that you want to not emit debug info for DWARF,
instead of marking it artificial and make a tool ignore it, which is the
correct thing to do for that format.

What you do for STABS, i don't care (someone else might, but it's not
me) 
:)

The secondary issue is that you really don't want to define a general
"don't emit debug info for this function" attribute, because it's going
to have all kinds of weird problems that you haven't documented the
semantics for (inlining vs not inlining vs versioning vs calling
functions they *do* want debug info for that get inlined two levels up,
blah blah blah).

So yes, calling it "nodebug" is an issue too, because users really
shouldn't know that it causes debug info to not be output for STABS, or
else they will abuse it.

Call it "artificial", make it drop debug info for STABS, and mark things
artificial for DWARF, document it as simply "Used to note that the
function is effectively a compiler generated function, not one created
by the user", and i have no objections.


>  Howabout  
> Fariborz re-submits his patch, with s/nodebug/bogus/ ?  You can pick  
> the new name.  (Imagine the possibilities:  "__attribute__  
> ((danberlin))"  :-):-):-)

Again, "Call it "artificial", make it drop debug info for STABS, and
mark things artificial for DWARF, document it as simply "Used to note
that the function is effectively a compiler generated function, not one
created by the user", and i have no objections.