This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: __nodebug__ attribute for use on SSE intrinsic wrappers
On Jul 29, 2005, at 2:21 PM, Daniel Berlin wrote:
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.
We're already in trouble, due to our /own/ implementation choice.
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?
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.
O.K., "min()" exists, but we don't /force/ developers to step through
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
implementation method over another.
I'm sorry, this doesn't make sense to me.
Yes, I'm complaining that GCC's implementation made our users
miserable. I suppose Motorola has done worse, but the AltiVec
standard is a "done deal," and can't reasonably be fixed today.
GCC made an implementation choice that made our Developers miserable,
and /can/ be fixed easily.
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*.
O.K., rename it as "__attribute__ ((voodoo))". For DWARF it has /no
effect/, and for STABS it omits the debug info.
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,
If your debug info format doesn't support such a way of saying they
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
You can claim this information is never valuable to anyone till you
blue in the face,
(inhaling deeply and holding breath... :-)
I'm not claiming this information is "never valuable," I'm claiming
it has "negative value." Right now, with our current debug stack
(STABS + GDB), this information is /interfering/ with Developers
debugging their SSE codes.
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
I presume these users are also intrigued by the implementation of min
Also, on a general principle, having an attribute to not emit debug
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
Personally, I think that inline vector intrinsics are ... "a bad
idea," but they're here and GCC supports them. And GCC could easily
do better than it's doing today.
Howabout we pick the name of this functionality ("artificial",
"intrinsic", "voodoo", "bogus", whatever :-) and apply it to the
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
DWARF, where your tool should be smart enough to know what was
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
correct thing to do for that format.
What you do for STABS, i don't care (someone else might, but it's not
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
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
blah blah blah).
Ditto my comments above concerning bad ideas.
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
else they will abuse it.
Call it "artificial", make it drop debug info for STABS, and mark
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.
Fariborz re-submits his patch, with s/nodebug/bogus/ ? You can pick
the new name. (Imagine the possibilities: "__attribute__
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
created by the user", and i have no objections.
This sounds good to me. Fariborz, can you implement this?