Re: Function specific optimizations call for discussion

["Ramana Radhakrishnan" <ramana dot r at gmail dot com>]

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.


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

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.