Hi Peter,
On Wed, Oct 31, 2018 at 9:58 PM Peter Zijlstra wrote:
>
> On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote:
> > Ok,
> >
> > with Segher's help I've been playing with his patch ontop of bleeding
> > edge gcc 9 and here are my observations. Please double-check me for
> > b
Hi Segher,
On Sun, Dec 2, 2018 at 3:48 PM Segher Boessenkool
wrote:
>
> On Fri, Nov 30, 2018 at 10:06:02AM +0100, Boris Petkov wrote:
> > On November 29, 2018 1:25:02 PM GMT+01:00, Segher Boessenkool
> > wrote:
> > >This will only be fixed from GCC 9 on, if the compiler adopts it. The
> > >ke
On November 29, 2018 1:25:02 PM GMT+01:00, Segher Boessenkool
wrote:
>This will only be fixed from GCC 9 on, if the compiler adopts it. The
>kernel wants to support ancient GCC, so it will need to have a
>workaround
>for older GCC versions anyway.
What about backporting it, like Richard says?
On Thu, Nov 29, 2018 at 02:09:25PM +0100, Richard Biener wrote:
> I'd be not opposed to backporting the asm inline support.
Even better! :-)
> Of course we still have to be happy with it and install the patch ;)
>
> Are you (kernel folks) happy with asm inline ()?
Yes, I think we are:
https://
On Thu, Nov 29, 2018 at 08:46:34PM +0900, Masahiro Yamada wrote:
> But, I'd like to ask if x86 people want to keep this macros.s approach.
> Revert 77b0bf55bc675 right now
> assuming the compiler will eventually solve the issue?
Yap, considering how elegant the compiler solution is and how much
pr
Hi.
On Wed, Oct 10, 2018 at 1:14 AM Segher Boessenkool
wrote:
>
> On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > On Sun, Oct 07, 2018 at 03:53:26PM +, Michael Matz wrote:
> > > > On Sun, 7 Oct 2018, Segher Boessenkool w
On Thu, Nov 01, 2018 at 02:20:40AM -0700, Joe Perches wrote:
> On Thu, 2018-11-01 at 10:01 +0100, Peter Zijlstra wrote:
> > On Wed, Oct 31, 2018 at 10:20:00PM -0700, Joe Perches wrote:
> > > On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote:
> > > > Anyway, with the below patch, I get:
> > >
On Thu, 2018-11-01 at 10:01 +0100, Peter Zijlstra wrote:
> On Wed, Oct 31, 2018 at 10:20:00PM -0700, Joe Perches wrote:
> > On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote:
> > > Anyway, with the below patch, I get:
> > >
> > >textdata bss dec hex filename
> > > 1738518
On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote:
>
> Anyway, with the below patch, I get:
>
>textdata bss dec hex filename
> 173851835064780 1953892 244038551745f8f
> defconfig-build/vmlinux
> 173856785064780 1953892 24404350174617e
>
On Wed, Oct 31, 2018 at 10:20:00PM -0700, Joe Perches wrote:
> On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote:
> >
> > Anyway, with the below patch, I get:
> >
> >textdata bss dec hex filename
> > 173851835064780 1953892 244038551745f8f
> > defconfig-
On Wed, Oct 31, 2018 at 01:55:26PM +0100, Peter Zijlstra wrote:
> On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote:
> > Ok,
> >
> > with Segher's help I've been playing with his patch ontop of bleeding
> > edge gcc 9 and here are my observations. Please double-check me for
> > boobo
Ping.
This is a good point in time, methinks, where kernel folk on CC here
should have a look at this and speak up whether it is useful for us in
this form.
Frankly, I'm a bit unsure on the aspect of us using this and supporting
old compilers which don't have it and new compilers which do. Becaus
On Sun, Oct 14, 2018 at 12:14:02AM +0300, Alexander Monakov wrote:
> I apologize for coming in late here with an alternative proposal, but would
> you be happy if GCC gave you a way to designate a portion of the asm template
> string that shouldn't be counted as its cost because it doesn't go into
Ok,
with Segher's help I've been playing with his patch ontop of bleeding
edge gcc 9 and here are my observations. Please double-check me for
booboos so that they can be addressed while there's time.
So here's what I see ontop of 4.19-rc7:
First marked the alternative asm() as inline and undeffe
On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote:
> It would be great to hear from kernel people if it works adequately for
> what you guys want it for :-)
Sure, ping me when you have the final version and I'll try to build gcc
with it and do some size comparisons.
Thx.
--
Reg
On Wed, Oct 10, 2018 at 03:03:25AM -0500, Segher Boessenkool wrote:
> The code immediately after this makes it size 1, even for things like
> asm(""), I suppose this works better for the inliner. But that's a detail
> (and it might change); the description says "consider this asm as minimum
> leng
* Richard Biener wrote:
> Can kernel folks give this a second and third thought please so we
> don't implement sth that in the end won't satisfy you guys?
So this basically passes '0 size' to the inliner, which should be better
than passing in the explicit size, as we'd inevitably get it wrong
* Segher Boessenkool wrote:
> On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > On Sun, Oct 07, 2018 at 03:53:26PM +, Michael Matz wrote:
> > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > > > > On Sun, Oct 07, 201
From: Michael Matz
> Sent: 07 October 2018 16:53
...
> I think the examples I saw from Boris were all indirect inlines:
>
> static inline void foo() { asm("large-looking-but-small-asm"); }
> static void bar1() { ... foo() ... }
> static void bar2() { ... foo() ... }
> void goo (void) { bar
* Michael Matz wrote:
> (without an built-in assembler which hopefully noone proposes).
There are disadvantages (the main one is having to implement it), but a
built-in assembler has
numerous advantages as well:
- Better optimizations: for example -Os could more accurately estimate true
i
* Segher Boessenkool wrote:
> > > More precise *size* estimates, yes. And if the user lies he should not
> > > be surprised to get assembler errors, etc.
> >
> > Yes.
> >
> > Another option would be if gcc parses the inline asm directly and
> > does a more precise size estimation. Which is a
On Sun, Oct 07, 2018 at 08:22:28AM -0500, Segher Boessenkool wrote:
> GCC already estimates the *size* of inline asm, and this is required
> *for correctness*.
I didn't say it didn't - but the heuristic could use improving.
> So I guess the real issue is that the inline asm size estimate for x86
Hi people,
this is an attempt to see whether gcc's inline asm heuristic when
estimating inline asm statements' cost for better inlining can be
improved.
AFAIU, the problematic arises when one ends up using a lot of inline
asm statements in the kernel but due to the inline asm cost estimation
heur
23 matches
Mail list logo
