On Thu, Nov 09, 2017 at 07:48:06AM +0300, Maxim Kuvyrkov wrote:
> Regarding CONFIG_* options, I would expect most of the configuration
> changes to be equally valid for both GCC's and Clang's LTO support.
> Sami, I don't think it's fair to ask you to support both Clang and GCC in
> your patchset,
On Thu, Nov 09, 2017 at 07:48:06AM +0300, Maxim Kuvyrkov wrote:
> Regarding CONFIG_* options, I would expect most of the configuration
> changes to be equally valid for both GCC's and Clang's LTO support.
> Sami, I don't think it's fair to ask you to support both Clang and GCC in
> your patchset,
On Wed, Nov 08, 2017 at 04:02:22PM -0800, Andi Kleen wrote:
> There's also older patches to enable single-pass-linking for kallsyms,
> which is extremly useful for LTO build performance.
Excellent, can you point me to the patch in question?
I worked around the build performance problem by
On Wed, Nov 08, 2017 at 04:02:22PM -0800, Andi Kleen wrote:
> There's also older patches to enable single-pass-linking for kallsyms,
> which is extremly useful for LTO build performance.
Excellent, can you point me to the patch in question?
I worked around the build performance problem by
On Wed, Nov 08, 2017 at 12:25:55PM +0300, Yury Norov wrote:
> The patch below uses trick with undefining mrs_s/msr_s immediately
> after use to solve the problem. It works for both gcc and clang.
Great, looks good to me! I tested the patch with LTO and clang's integrated
assembler seems to be
On Wed, Nov 08, 2017 at 12:25:55PM +0300, Yury Norov wrote:
> The patch below uses trick with undefining mrs_s/msr_s immediately
> after use to solve the problem. It works for both gcc and clang.
Great, looks good to me! I tested the patch with LTO and clang's integrated
assembler seems to be
> On Nov 9, 2017, at 3:02 AM, Andi Kleen wrote:
>
>> There's the series from Andi Kleen that enables LTO for Linux on x86:
>> https://lwn.net/Articles/512548/
>> https://github.com/andikleen/linux-misc/tree/lto-411-1
>>
>> It has solved many problems you also try to solve,
> On Nov 9, 2017, at 3:02 AM, Andi Kleen wrote:
>
>> There's the series from Andi Kleen that enables LTO for Linux on x86:
>> https://lwn.net/Articles/512548/
>> https://github.com/andikleen/linux-misc/tree/lto-411-1
>>
>> It has solved many problems you also try to solve, and some patches
>>
> There's the series from Andi Kleen that enables LTO for Linux on x86:
> https://lwn.net/Articles/512548/
> https://github.com/andikleen/linux-misc/tree/lto-411-1
>
> It has solved many problems you also try to solve, and some patches
> are looking very similar.
>
> At now we have different
> There's the series from Andi Kleen that enables LTO for Linux on x86:
> https://lwn.net/Articles/512548/
> https://github.com/andikleen/linux-misc/tree/lto-411-1
>
> It has solved many problems you also try to solve, and some patches
> are looking very similar.
>
> At now we have different
Hi Sami,
(CC Andi Kleen, Alex Matveev, Maxim Kuvyrkov)
On Fri, Nov 03, 2017 at 10:12:01AM -0700, Sami Tolvanen wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM
Hi Sami,
(CC Andi Kleen, Alex Matveev, Maxim Kuvyrkov)
On Fri, Nov 03, 2017 at 10:12:01AM -0700, Sami Tolvanen wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM
On Fri, Nov 03, 2017 at 10:12:01AM -0700, Sami Tolvanen wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending
On Fri, Nov 03, 2017 at 10:12:01AM -0700, Sami Tolvanen wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending
On Fri, Nov 3, 2017 at 11:06 AM, Mark Rutland wrote:
> On Fri, Nov 03, 2017 at 10:53:08AM -0700, Nick Desaulniers wrote:
>> These mrs_s and msr_s macros in particular were preventing us from
>> linking arm64 with Clang's integrated assembler, regardless of LTO.
>> Those
On Fri, Nov 3, 2017 at 11:06 AM, Mark Rutland wrote:
> On Fri, Nov 03, 2017 at 10:53:08AM -0700, Nick Desaulniers wrote:
>> These mrs_s and msr_s macros in particular were preventing us from
>> linking arm64 with Clang's integrated assembler, regardless of LTO.
>> Those macros ran into:
On Fri, Nov 03, 2017 at 10:53:08AM -0700, Nick Desaulniers wrote:
> These mrs_s and msr_s macros in particular were preventing us from
> linking arm64 with Clang's integrated assembler, regardless of LTO.
> Those macros ran into: https://bugs.llvm.org/show_bug.cgi?id=19749.
> So while I appreciate
On Fri, Nov 03, 2017 at 10:53:08AM -0700, Nick Desaulniers wrote:
> These mrs_s and msr_s macros in particular were preventing us from
> linking arm64 with Clang's integrated assembler, regardless of LTO.
> Those macros ran into: https://bugs.llvm.org/show_bug.cgi?id=19749.
> So while I appreciate
These mrs_s and msr_s macros in particular were preventing us from
linking arm64 with Clang's integrated assembler, regardless of LTO.
Those macros ran into: https://bugs.llvm.org/show_bug.cgi?id=19749.
So while I appreciate how clever they are, they prevent us from
assembling with Clang so I
These mrs_s and msr_s macros in particular were preventing us from
linking arm64 with Clang's integrated assembler, regardless of LTO.
Those macros ran into: https://bugs.llvm.org/show_bug.cgi?id=19749.
So while I appreciate how clever they are, they prevent us from
assembling with Clang so I
Clang's integrated assembler does not allow assembly macros defined
in one inline asm block using the .macro directive to be used across
separate asm blocks. LLVM developers consider this a feature and not a
bug, recommending code refactoring:
https://bugs.llvm.org/show_bug.cgi?id=19749
As
Clang's integrated assembler does not allow assembly macros defined
in one inline asm block using the .macro directive to be used across
separate asm blocks. LLVM developers consider this a feature and not a
bug, recommending code refactoring:
https://bugs.llvm.org/show_bug.cgi?id=19749
As
22 matches
Mail list logo