This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Function specific optimizations call for discussion
On Thu, Nov 29, 2007 at 05:08:11PM +0530, Ramana Radhakrishnan wrote:
> Hi Karthik,
>
> Thanks for your email .
>
> > > Hi Michael,
> > >
> > > I had a comment / query regarding Stage 2 where you talk about
> > > Function cloning for different targets.
> > >
> > > I understand that the mechanism is to have a hidden function pointer
> > > that actually gets initialized based on the cpuid.
> > >
> > > I don't know if it is worth the effort to have debug info also
> > > enhanced to be such that a breakpoint put on the function my_min
> > > actually sets the breakpoint on any of the clones since the logic
> > > would be similar to the same. This sounds logically similar to the
> > > way that gdb currently handles breakpoints to multiple constructors.
> > >
> >
> > If the user has written the clone (for manual dispatch), then the
> > debug info would point to his code version. If it were generated
> > automatically (stage 2), the information would pertain to the function
> > cloned multiple times.The disassembly on those breakpoints might be
> > different, of course.
>
> All I am saying is that while doing the automatic dispatch try and
> have debug info in sync with the source written by the user. The
> disassembly is not what I am worrying about. Its only the ability to
> place breakpoints on all the clones.
>
> b do_min and voila gdb will automagically put breakpoints on all the clones.
Yes, that is the desired goal.
>
> >
> > > The other option ofcourse is to fake debug information for such to
> > > actually set a breakpoint on the value of the function pointer that
> > > you so set up. I am no DWARF expert but there might be other folks on
> > > the list who might have better ideas about how to implement this.
> > >
> >
> > There is an idea to modify the dynamic linker to take advantage of the
> > detection; If in such case, setting a breakpoint would be easier. Then
> > we wouldn't require indirect calls either. The breakpoints can be set
> > in each of the clones, and they will be processed only after setting
> > up the pointer and their subsequent execution.
>
> Hmmm some kind of dl symbol resolver work where you have a cloned
> attribute for the symbol in ELF and figure out the best clone based on
> a runnable hunk which detects the best function . Might increase a bit
> of overhead at run time but its a one time expense. If we did
> prelinking that could be removed too.
It would be nice if we could get something like this done. However, given that
it spans several different groups that don't always talk together (compiler,
glibc, binary utilities, dynamic linker, linux system vendors), it is a much
harder problem to solve. Also, doing it in the Linux space only, means it
isn't available to the non-Linux gcc users.
One approach is the fat binary approach, where you compile the program N times,
and at runtime the system maps in the correct code image depending on the
target bits. However, this is very space inefficient.
> This might preclude my earlier statement.
>
> >
> > The idea is to make use of the debugging information as provided by
> > the inline-cloner.
>
> All I wanted was the requirement of debug information consistency to
> be a part of the proposal for the inline cloner.
>
> cheers
> Ramana
> >
> > > cheers
> > > Ramana
> >
> > Karthik
> >
>
>
>
> --
> Ramana Radhakrishnan
> GNU Tools
> Celunite Inc.
>
>
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
michael.meissner@amd.com