changing parameters in build
Hi, I am having exploring how much work it would be to do whole kernel optimization using clang on the current kernel. My understanding is the kernel uses a recursive make file system. I am curious if there are any easy ways to get the kernel to build llvm bit code for all files without going through and hand editing hundreds of makefiles. Thanks in advance, Carter.
On Wed, Oct 17, 2018 at 04:24:13PM +0800, Carter Cheng wrote:
Hi,
I am having exploring how much work it would be to do whole kernel optimization using clang on the current kernel. My understanding is the kernel uses a recursive make file system. I am curious if there are any easy ways to get the kernel to build llvm bit code for all files without going through and hand editing hundreds of makefiles.
There is no need to modify more than one makefile. Look at how the kernel is built, you should be just fine as-is because people use clang just fine today. good luck! greg k-h
The problem is I have to do something special with the clang options. I have to add an interprocedural link time optimization pass spitting out bitcode files and tying them together using llvm-link. On Wed, Oct 17, 2018 at 7:55 PM Greg KH <greg@kroah.com> wrote:
On Wed, Oct 17, 2018 at 04:24:13PM +0800, Carter Cheng wrote:
Hi,
I am having exploring how much work it would be to do whole kernel optimization using clang on the current kernel. My understanding is the kernel uses a recursive make file system. I am curious if there are any easy ways to get the kernel to build llvm bit code for all files without going through and hand editing hundreds of makefiles.
There is no need to modify more than one makefile. Look at how the kernel is built, you should be just fine as-is because people use clang just fine today.
good luck!
greg k-h
On Wed, Oct 17, 2018 at 08:02:46PM +0800, Carter Cheng wrote:
The problem is I have to do something special with the clang options. I have to add an interprocedural link time optimization pass spitting out bitcode files and tying them together using llvm-link.
Then add those options to the proper place in the main Makefile. There really is only "one" kernel makefile, look at the code, it's not that tricky to follow if you understand make. good luck! greg k-h
Thanks! On Wed, Oct 17, 2018 at 8:12 PM Greg KH <greg@kroah.com> wrote:
On Wed, Oct 17, 2018 at 08:02:46PM +0800, Carter Cheng wrote:
The problem is I have to do something special with the clang options. I have to add an interprocedural link time optimization pass spitting out bitcode files and tying them together using llvm-link.
Then add those options to the proper place in the main Makefile. There really is only "one" kernel makefile, look at the code, it's not that tricky to follow if you understand make.
good luck!
greg k-h
On Wed, 17 Oct 2018 20:02:46 +0800, Carter Cheng said:
The problem is I have to do something special with the clang options. I have to add an interprocedural link time optimization pass spitting out bitcode files and tying them together using llvm-link.
As I said back on Friday, this is work that's already been done:
There's no LTO support in the stock 4.19 tree, but Andi Kleen did a patchset for 4.15, and there's another patchset to enable LTO when using Clang rather than gcc. (I haven't tried either one, don't use on a production machine, as the resulting kernel may crash, eat filesystems, and/or turn your dog green...)
http://lmgtfy.com/?q=andi+kleen+linux+4.15+lto What you're probably going to run into is that adding the options isn't the hard part of the project. The hard part will be fixing all the places where LTO exposes issues in the code, such as this (already-fixed) problem: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1620485.html
Well I found and old post by John Criswell describing how he did his dissertation project SVA. He didn't use LTO but llvm-link. So I figure I would try to do it that way and see if this works since I am not sure how good the current support for LTO is. Will clang generally work if an external assembler is used? On Wed, Oct 17, 2018 at 9:05 PM <valdis.kletnieks@vt.edu> wrote:
On Wed, 17 Oct 2018 20:02:46 +0800, Carter Cheng said:
The problem is I have to do something special with the clang options. I have to add an interprocedural link time optimization pass spitting out bitcode files and tying them together using llvm-link.
As I said back on Friday, this is work that's already been done:
There's no LTO support in the stock 4.19 tree, but Andi Kleen did a patchset for 4.15, and there's another patchset to enable LTO when using Clang rather than gcc. (I haven't tried either one, don't use on a production machine, as the resulting kernel may crash, eat filesystems, and/or turn your dog green...)
http://lmgtfy.com/?q=andi+kleen+linux+4.15+lto
What you're probably going to run into is that adding the options isn't the hard part of the project. The hard part will be fixing all the places where LTO exposes issues in the code, such as this (already-fixed) problem:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1620485.html
What I mean is will it nowadays compile the kernel with 4.19 or do you need to manually hack the inline asm? On Wed, Oct 17, 2018 at 9:11 PM Carter Cheng <cartercheng@gmail.com> wrote:
Well I found and old post by John Criswell describing how he did his dissertation project SVA. He didn't use LTO but llvm-link. So I figure I would try to do it that way and see if this works since I am not sure how good the current support for LTO is. Will clang generally work if an external assembler is used?
On Wed, Oct 17, 2018 at 9:05 PM <valdis.kletnieks@vt.edu> wrote:
On Wed, 17 Oct 2018 20:02:46 +0800, Carter Cheng said:
The problem is I have to do something special with the clang options. I have to add an interprocedural link time optimization pass spitting out bitcode files and tying them together using llvm-link.
As I said back on Friday, this is work that's already been done:
There's no LTO support in the stock 4.19 tree, but Andi Kleen did a patchset for 4.15, and there's another patchset to enable LTO when using Clang rather than gcc. (I haven't tried either one, don't use on a production machine, as the resulting kernel may crash, eat filesystems, and/or turn your dog green...)
http://lmgtfy.com/?q=andi+kleen+linux+4.15+lto
What you're probably going to run into is that adding the options isn't the hard part of the project. The hard part will be fixing all the places where LTO exposes issues in the code, such as this (already-fixed) problem:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1620485.html
participants (3)
-
Carter Cheng -
Greg KH -
valdis.kletnieks＠vt.edu