search for: __x86_arch

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

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

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