similar to: PROPOSAL: Extend inline asm syntax with size spec

Hi Segher, On Sun, Dec 2, 2018 at 3:48 PM Segher Boessenkool <segher at kernel.crashing.org> 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 <segher at kernel.crashing.org> wrote: > > >This will only be fixed from GCC 9 on, if the compiler adopts it. The > >

* Segher Boessenkool <segher at kernel.crashing.org> 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 +0000, Michael Matz wrote: > > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote: > > > > > On Sun, Oct 07, 2018 at 11:18:06AM

Hi. On Wed, Oct 10, 2018 at 1:14 AM Segher Boessenkool <segher at kernel.crashing.org> 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 +0000, Michael Matz wrote: > > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote: > > > > >

Hi. On Wed, Oct 10, 2018 at 1:14 AM Segher Boessenkool <segher at kernel.crashing.org> 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 +0000, Michael Matz wrote: > > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote: > > > > >

* Segher Boessenkool <segher at kernel.crashing.org> 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 lot more involved

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 > isn't very good (since it has to be pessimistic, and x86 insns can be >

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 > length and cost for inlining decisions", which works for either 0 or

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. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

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. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

Hi Peter, On Wed, Oct 31, 2018 at 9:58 PM Peter Zijlstra <peterz at infradead.org> 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 > > booboos so that they can be

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://lkml.kernel.org/r/20181031125526.GA13219 at hirez.programming.kicks-ass.net Thx. --

I couldn't resist: izeof(synth_buffs) = sizeof(float)*2*2*0x120 = 4 * 4 * 0x120 = 0x1200 = 4608 -Anish > -----Original Message----- > From: Segher Boessenkool [mailto:segher@chello.nl] > Sent: Monday, July 02, 2001 6:34 PM > To: vorbis-dev@xiph.org > Subject: Re: [vorbis-dev] ogg vorbis dynamic memory allocation. > > > > > Firelight Multimedia wrote: >

On Sun, Dec 16, 2018 at 12:29 PM Nadav Amit <namit at vmware.com> wrote: > > > On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > > > > Revert the following 9 commits: > > > > [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to > > work around GCC inlining bugs") > > >

Thread-split from the vorbis-mailing list ("Vorbis determined to be as good as MPC at 128 kbps!") <p>On Sun, 30 May 2004, Segher Boessenkool wrote: [Steven So] SS>> If iTunes AAC can encode castanets with much less pre-echo at SS>> ABR 128 kbps, then hopefully there will be an imaginative SS>> (and non-patented) way of doing this in Vorbis without the SS>>

* Michael Matz <matz at suse.de> 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 instruction size. - Better inlining: as the examples in this thread are

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) { bar1(); } // bar1 should have been inlined > > So, while the

* Richard Biener <rguenther at suse.de> 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 in cases. I also like 'size 0' for the

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 the > .text section? This wouldn't interact with your redefinitions of the

On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote: > > Anyway, with the below patch, I get: > > text data bss dec hex filename > 17385183 5064780 1953892 24403855 1745f8f defconfig-build/vmlinux > 17385678 5064780 1953892 24404350 174617e defconfig-build/vmlinux > > Which shows we inline more (look for asm_volatile for

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: > > > > > > text data bss dec hex filename > > > 17385183 5064780 1953892 24403855 1745f8f