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

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: > > > > >

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: > > > 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 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 >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? -- Sent from a small device: formatting sux and

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

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

* 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 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. --

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

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: >

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>>

Quoting Segher Boessenkool <segher@kernel.crashing.org>: > > I wonder if there's a way to "weak-link" against libraries on > > Linux/GNU-ld-so? The idea is that a symbol lookup/relocation isn't > > performed until the call is actually MADE, rather than merely > > referenced. > > That's the default behaviour. No it's not. The

Me again, this time not about patents but about wavelets. I've been doing some work on an image compression method which uses Haar wavelets plus VQ and entropy coding, and Segher Boessenkool told me in a private message that you are also doing a video codec. So I searched the archives and read a bunch of posts, but I never did find out any web address. And it's not on xiph.org either. So

I would like to see the following information added to the FAQ at vorbis.com, appended to the "Audio Quality" section. "Uiver," "boa," and "jonI" from OPN's #Vorbis channel contributed and reviewed it. "What does the 'quality' setting mean?" Beginning with vorbislib 1.0-rc3, audio quality is no longer measured in kilobits per

* 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

Segher Boessenkool wrote: >> I noticed that you changed all constant floating point numbers >> from double notation (e.g. 3.0) to float notation (3.0f) in the latest >> version >> of Speex (in subversion). >> Did that give any performance increase (because of elimination of the >> float to double and double to float conversions)? > > > It does, with

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") > > >