On 14 March 2014 16:34, JF Bastien <jfb at google.com> wrote:> How does this overlap with: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140310/thread.html#208333The builtin was created to call __clear_cache() on platforms that need it (like ARM and MIPS), but to be ignored on others (like x86_64). This builtin should call __clear_cache() from whatever library is available at the moment, so there is no overlap, just supporting the GCC builtin to avoid calling a noop function when not needed.> The bug mentions doing the mov r7 and svc, when the above code already does > it, I'm somewhat confused.That's an idea that might not be a good one. I was thinking if, in some occasions, we could emit directly the instructions, but that will have to deal with lower level stuff that we don't want on the intrinsic level. GCC just emits a call to __clear_cache() and, at the very least, we should do the same for now. That optimisation might come later, at a much lower level, but I have my doubts if that's relevant. We shouldn't be clearing the cache on a hot loop anyway. ;) cheers, --renato
> > The builtin was created to call __clear_cache() on platforms that need > it (like ARM and MIPS), but to be ignored on others (like x86_64). > > This builtin should call __clear_cache() from whatever library is > available at the moment, so there is no overlap, just supporting the > GCC builtin to avoid calling a noop function when not needed. >I see, this makes sense. Agreed it's useful, thanks for explaining.> That's an idea that might not be a good one. I was thinking if, in > some occasions, we could emit directly the instructions, but that will > have to deal with lower level stuff that we don't want on the > intrinsic level. GCC just emits a call to __clear_cache() and, at the > very least, we should do the same for now. > > That optimisation might come later, at a much lower level, but I have > my doubts if that's relevant. We shouldn't be clearing the cache on a > hot loop anyway. ;)Maybe a naive question, but it seems better to just use inlining instead of reimplementing the same logic within LLVM. That requires static linking/LTO, so it's not that workable. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140314/d5b27d8d/attachment.html>
On 14 March 2014 17:06, JF Bastien <jfb at google.com> wrote:> Maybe a naive question, but it seems better to just use inlining instead of > reimplementing the same logic within LLVM. That requires static linking/LTO, > so it's not that workable.You're absolutely right... Premature optimization is the root of all evil... ;) --renato