On Thu, Jun 16, 2011 at 11:30 PM, Renato Golin <rengolin at systemcall.org>wrote:> On 16 June 2011 20:20, Kostya Serebryany <kcc at google.com> wrote: > > Not hard at all. > > At some point the file had no asm at all, but using the custom asm allows > to > > make the generated code more compact. > > That should also be simple for other platforms... >Sure.> > > > My first attempt that used no asm required ~15 bytes of code. > > Note, this code is executed only once, so it affects the performance very > > slightly (through icache size). > > I see, maybe you could leave your C implementation as a fall back. >Not easy, because it will require a fallback code in the run time library. But yes, possible.> > > > Alas. It will grow even more when we add MacOS support. > > (currently, only tiny tests work on Mac). > > I saw a few APPLE macros.Yea...> I think that's the part that needs most > care, since multi-platform (os/arch/etc) could bloat that > considerably. >Agree. We've been adding APPLE code just recently. Time to split. I afraid we'll have to keep a single .cc file and add .h files for os/arch specific code to keep inlining under manual control (I don't want to reply on the compiler doing cross-cc-file inlining for me). --kcc> > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110616/f9890ba1/attachment.html>
On 16 June 2011 20:57, Kostya Serebryany <kcc at google.com> wrote:>> I see, maybe you could leave your C implementation as a fall back. > > Not easy, because it will require a fallback code in the run time library. > But yes, possible.I was thinking more of a build-time fall back, when you're choosing the platform... #ifdef __x86_arch ... specific #else C-generic #endif> Agree. We've been adding APPLE code just recently. Time to split. > I afraid we'll have to keep a single .cc file and add .h files for os/arch > specific code to keep inlining under manual control (I don't want to reply > on the compiler doing cross-cc-file inlining for me).You might end up with a lot of redundancy. If inlining is not working as you'd expect, a compile-time static include (is ugly, but) would be better than to have the same code over and over. cheers, --renato
On Fri, Jun 17, 2011 at 11:48 AM, Renato Golin <rengolin at systemcall.org>wrote:> On 16 June 2011 20:57, Kostya Serebryany <kcc at google.com> wrote: > >> I see, maybe you could leave your C implementation as a fall back. > > > > Not easy, because it will require a fallback code in the run time > library. > > But yes, possible. > > I was thinking more of a build-time fall back, when you're choosing > the platform... > > #ifdef __x86_arch > ... specific > #else > C-generic > #endif >Sure, this is possible. But we'll need two such blocks: one in the LLVM instrumentation and one (matching) in the run-time. I am rather reluctant to add 'generic' code that handles unknown/untested platforms because the memory mapping is very platform specific anyway. For extreme performance ASAN uses the fixed memory-to-shadow mapping (addr>>3)+offset. I guess there are plenty of platforms where this mapping won't work or will require different offset. --kcc> > > > > Agree. We've been adding APPLE code just recently. Time to split. > > I afraid we'll have to keep a single .cc file and add .h files for > os/arch > > specific code to keep inlining under manual control (I don't want to > reply > > on the compiler doing cross-cc-file inlining for me). > > You might end up with a lot of redundancy. > > If inlining is not working as you'd expect, a compile-time static > include (is ugly, but) would be better than to have the same code over > and over. > > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110617/16667818/attachment.html>