[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v9mioj5r.fsf@nanos.tec.linutronix.de>
Date: Thu, 02 Apr 2020 01:55:44 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Andy Lutomirski <luto@...capital.net>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86 cleanups for v5.7
Linus,
Linus Torvalds <torvalds@...ux-foundation.org> writes:
> On Tue, Mar 31, 2020 at 11:09 AM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> Lovely. This now makes my local boot-test tree be much closer to my
>> upstream tree, since I've had my clang asm-goto stuff in my boot tree
>> (and it had that series from Al).
>
> Side note: I've extended on the x86 uaccess cleanups a bit with a
> couple of commits:
>
> x86: start using named parameters for low-level uaccess asms
> x86: get rid of 'rtype' argument to __get_user_asm() macro
> x86: get rid of 'rtype' argument to __put_user_goto() macro
> x86: get rid of 'errret' argument to __get_user_xyz() macross
> x86: remove __put_user_asm() infrastructure
A few comments:
- x86 starts the short log after the colon with an uppercase
letter
- 'macross' is really gross :)
- All commits lack a Link:https//lore.kernel.org/r/$MSG-ID tag. That
might be an oversight or just reflecting the fact that these patches
have never seen a mailing list.
If my brain hasn't gone into complete wishful thinking mode there is
general consenus that we want to have visability and traceability of
changes including those which come from maintainers for various good
reasons (The obvious 'fix a typo breaking the build' exempted).
Of course that's at your discretion.
> which I _tried_ to make complete no-ops (comparing code generation
> before and after). Sadly, one of them (the "get rid of 'rtype'
> argument to __get_user_asm" one) causes gcc to pick different
> registers for me because now the temporary variables have different
> sizes.
>
> (The others cause line number data changes, of course, but I didn't
> see any _code_ changes).
>
> So that one commit results in a lot of small noise changes to the
> generated code for me, but the few I looked at closer all looked the
> same (mostly just different register, sometimes odd improvements where
> it avoided doing a stupid "andq $0xffffffff", and in one or two cases
> it seemed to randomly just change the stack frame size, sometimes to
> the better, sometimes to worse).
>From a quick check I can confirm that the resulting text changes are
just random noise and I did not notice anything horrible in the
generated code either.
> The others should be purely semantically identical.
>
> It was all just small prep to make the patch I have for "asm goto with
> outputs" have a smaller footprint - particularly when I try to then
> make it work with compilers that don't have the capability, and I need
> to have different output registers for that case.
>
> I'm not planning on actually doing that patch this merge window, it's
> just not ready enough. But just in case somebody (Al?) is still
> working on the uaccess.h file, letting you know about my preparatory
> cleanups.
See above.
Thanks,
tglx
Powered by blists - more mailing lists