changing parameters in build

changing parameters in build

[Carter Cheng]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181017/6d4ef3c5/attachment.html>

changing parameters in build

[Greg KH]

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

changing parameters in build

[Carter Cheng]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181017/24feb974/attachment.html>

changing parameters in build

[Greg KH]

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

changing parameters in build

[Carter Cheng]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181017/60722a8d/attachment.html>

changing parameters in build

[valdis.kletnieks at vt.edu]

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 at vger.kernel.org/msg1620485.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181017/1bc89d0e/attachment.sig>

changing parameters in build

[Carter Cheng]

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 at vger.kernel.org/msg1620485.html
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181017/f0296150/attachment-0001.html>

changing parameters in build

[Carter Cheng]

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 at vger.kernel.org/msg1620485.html
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181017/d389076d/attachment.html>