"Ronald S. Bultje" <[email protected]> writes: > Hi, > > On Mon, Mar 26, 2012 at 1:36 PM, Luca Barbato <[email protected]> wrote: >> On 26/03/12 11:54, Kostya Shishkov wrote: >>> On Sat, Mar 24, 2012 at 12:32:55PM -0700, Ronald S. Bultje wrote: >>>> Hi, >>>> >>>> On Thu, Mar 22, 2012 at 7:05 AM, Kostya Shishkov >>>> <[email protected]> wrote: >>>>> Can we get at least several compilers and compiler version output for the >>>>> functions that use it? It's inline assembly, so compiler output for these >>>>> may vary greatly and fail register allocation for some other GCC version, >>>>> for instance. When we have it, then we can discuss it further. >>>> >>>> gcc-4.2.1: better after patch (less and shorter instructions) >>>> gcc-4.2.1/llvm: same number of instructions before/after, but shorter >>>> instructions after patch >>>> gcc-4.5.3: same number of instructions before/after, but shorter >>>> instructions after patch >>>> gcc-4.6.3: same number of instructions before/after, but shorter >>>> instructions after patch >>>> gcc-4.7.0: better after patch (less and shorter instructions) >>>> clang-3.0: same number of instructions before/after, but shorter >>>> instructions after patch >>>> >>>> Complete disassembly attached in before.txt and after.txt with each of >>>> the above compilers. >>> >>> Looks legit, what do other people think? >> >> I tried to compare it and seems that the patch speeds up everything >> sensibly on linux/gcc-4.6.2. (ran 30 times for each interesting patch of >> the set, few times it got worse many times it got better I thrown away >> outliers and seems overall better) > > OK, so are there no more objections to the whole patchset then? I'd > like to push this.
You have not done anything to address the issue of why code that _should_ be worse is actually compiling better. Allowing such anomalies to go without investigation is irresponsible at best. I realise, however, that you don't give a fuck about this and that you are determined to push this hack of a patch no matter what. Enjoy your victory. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
