This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.



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.

O.K., "min()" exists, but we don't /force/ developers to step through it.


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.

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,
*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,

(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
this true.

I presume these users are also intrigued by the implementation of min () ?


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.

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

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

This sounds good to me. Fariborz, can you implement this?


stuart

(exhale! :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]