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

[Stuart Hastings <stuart at apple dot com>]

...
> > > The tool needs to know what functions to ignore.
> > >
> > > If you want that information to propogate from the source code, you
> > > should do it by adding some annotation to the debug info which says
> > > that the inline function is uninteresting, rather than removing  
> > > debug
> > > info.  This way, tools _can_ step into the function if they are  
> > > asked
> > > to by the user.
> >
> > And one way to annotate and propagate this info is to use special
> > attribute. Any other alternative ?
>
> Yes.  My point is that the attribute should ADD to the debug info, not
> SUBTRACT.

[snip]

> > In the same way as it will solve GDB's.  Once you have inlining data,
> > you can choose to ignore specific inline functions as not  
> > interesting -
> > the difference is that the consumer can now make this choice, instead
> > of the producer.  Then you credit the samples taken in those inline
> > functions to their call sites using DW_AT_call_line.
>
> - End user programmer did not write these inline functions. They  
> are supplied by GCC.
> - End user programmer does not see them as inline functions.
> - Consumer of this info, CHUD tools, does not know that this is  
> supplied by GCC and not by end user programmer.
>
> Since, GCC is supplying these intrinsics, it should supply them in  
> such a way that they are not represented as small functions. Note  
> that, these headers already uses inlining related attributes (and  
> not leave it on end user to set appropriate optimization flags) to  
> accomplish this in some sense.

I'd like to amplify what Devang wrote here.

If we step back to the Developer's perspective, s/he is trying to say  
"put a BLAH vector instruction here."  Intel and GCC have made this  
functionality available as "intrinsic functions," probably because it  
minimized the violence done to the language and the rest of the  
compiler.  The Developer doesn't know or care how it's done, s/he  
wants the instruction, nothing more or less.

If you examine the SSE intrinsics, it's clear they could all be  
implemented as C macros; I'd guess this was intentional.  GCC has  
chosen to implement SSE with a layer of functions wrapping a bunch of  
__builtins.  I suppose there are advantages to this scheme; it's  
possible to detect and flag some type errors that a macro  
implementation would miss.

Regardless, those wrapper functions are an implementation detail, and  
the current debugger behavior is apparently a serious handicap for  
our Developers.  Imagine debugging a loop with forty-odd vector  
instructions, and every (s)tep operation takes you to a meaningless  
header file somewhere in Siberia...

If GDB can learn to step over these wrapper functions, that would be  
fine.  But I see no point in preserving debug info for these  
functions; they're less interesting than the __lshri3 stuff in  
libgcc2.  The mere existence of this useless debug info is  
interfering with real developers that are writing real vector codes  
today.

If we defer the issue by redefining it as a debugger problem, we're  
just delaying the fix.  We might as well tell the Developer "avoid  
the SSE intrinsics and wait for the auto-vectorizer."  This is doubly  
infuriating for Developers, as they would be happy and productive  
today if GCC had implemented SSE with macros.

Would you consider rewriting the SSE intrinsics as macros?  This  
actually would resolve the issue.

stuart