Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1193549 > unrolled thread

Re: ASM flags in general

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: ASM flags in general Andy Lutomirski <luto@amacapital.net> - 2015-07-28 00:50 +0200
    Re: ASM flags in general Andy Lutomirski <luto@amacapital.net> - 2015-07-28 01:40 +0200
      Re: ASM flags in general "H. Peter Anvin" <hpa@zytor.com> - 2015-07-28 02:00 +0200
        Re: ASM flags in general Andy Lutomirski <luto@amacapital.net> - 2015-07-28 02:00 +0200
          Re: ASM flags in general "H. Peter Anvin" <hpa@zytor.com> - 2015-07-28 02:10 +0200
          Re: ASM flags in general "H. Peter Anvin" <hpa@zytor.com> - 2015-07-28 02:40 +0200
            Re: ASM flags in general Andy Lutomirski <luto@amacapital.net> - 2015-07-28 02:50 +0200
      Re: ASM flags in general Andy Lutomirski <luto@amacapital.net> - 2015-07-28 02:00 +0200

#1193549 — Re: ASM flags in general

On Mon, Jul 27, 2015 at 2:04 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 07/27/2015 01:38 PM, Andy Lutomirski wrote:
>>
>> As long as we're thinking about this stuff, there are bunch of places
>> where we use exception fixups and do awful things involving translating
>> them to error codes.  Ideally they'd use as goto instead, but last time
>> I checked, GCC was quite picky and didn't like output constraints and
>> asm goto at the same time.  Maybe GCC could fix this at some point, but
>> using condition code outputs might be reasonable, too.
>>
>> Doing this would make put_user_ex and similar completely unnecessary, I
>> think.
>>
>
> No, I think this is wrong.  Exceptions and flags are almost each others
> opposites.  Since C doesn't have native exception handling (except
> setjmp/longjmp) we pretty much hack it.
>
> asm goto() would indeed be the better way to do this, but again, would
> in most cases require asm goto to support outputs.
>
> However, get_user_ex and put_user_ex we really don't want to go away.
> They produce extremely efficient code -- just a bunch of mov operations
> -- for the common path, and that's the way we like it.

Wouldn't asm goto be just as good (assuming it supported the right
constraints)?  In principle, this:

if (put_user(...))
  goto error;
if (put_user(...))
  goto error;

should optimize to:

mov [...]
_ASM_EXTABLE(...)
mov [...]
_ASM_EXTABLE(...)

...

extable_landing_pad:
   jmp error

IOW, I think that GCC's optimizer should be good enough to keep the
error paths out of line and maybe even to coalesce them,

>
> That being said, there probably are a couple of patterns where we could
> do, say "stc" in the exception path, and emit CF as an output:
>
> bool err;
> int errno;
>
> asm volatile("xor %1,%1\n"      /* Clears CF */
>              "1: something %3,%0\n"/* Leaves CF unchanged, or clears */
>              "2:\n"
>              ".section .fixup.\"ax\"\n"
>              "3: mov %4,%1\n"
>              "   stc\n"
>              "   jmp 2b"
>              _ASM_EXTABLE(1b,3b)
>             : "=X" (output), "=r" (errno), "=@ccc" (err)
>             : "Y" (input), "i" (-EIO));
>
> This would make "err" immediately testable.  However, it also might make
> gcc generate extra code to save and restore err, since it wouldn't
> understand the invariant that err = !!errno.

Yeah, this wouldn't be as good as asm goto.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1193590

On Mon, Jul 27, 2015 at 4:22 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> For that to work, gcc would have to know about the extable.

It could, I think:

asm goto (
    "1: mov ...\n\t"
    _ASM_EXTABLE(1b, %l2)  /* or whatever index it is */
    : ... : ... : ... : efault);

return 0;

efault:
     return -EFAULT;

I think that wrmsr_safe could get this treatment with current GCC.
put_user plausibly could, too, if we were willing to mark it volatile
and accept that we're lying a little bit about the lack of an output
constraint.  get_user would need GCC to understand output constraints
for real.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1193643

Sure... but now you have to wrap things in stac/clac.  I'm not sure I see the point since the code is already pretty much optimal.

On July 27, 2015 4:49:46 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Mon, Jul 27, 2015 at 4:46 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> Sure, but that is different than getting rid of the _ex forms.
>>
>
>If we did that and got rid of the _ex forms, though, then the code
>that matters (the no-fault case) would just be a bunch of movs, right?
> That's basically the same as the current _ex code.
>
>--Andy
>
>> On July 27, 2015 4:36:26 PM PDT, Andy Lutomirski
><luto@amacapital.net>
>> wrote:
>>>
>>> On Mon, Jul 27, 2015 at 4:22 PM, H. Peter Anvin <hpa@zytor.com>
>wrote:
>>>>
>>>>  For that to work, gcc would have to know about the extable.
>>>
>>>
>>> It could, I think:
>>>
>>> asm goto (
>>>     "1: mov ...\n\t"
>>>     _ASM_EXTABLE(1b, %l2)  /* or whatever index it is */
>>>     : ... : ... : ... : efault);
>>>
>>> return 0;
>>>
>>> efault:
>>>      return -EFAULT;
>>>
>>> I think that wrmsr_safe could get this treatment with current GCC.
>>> put_user plausibly could, too, if we were willing to mark it
>volatile
>>> and accept that we're lying a little bit about the lack of an output
>>> constraint.  get_user would need GCC to understand output
>constraints
>>> for real.
>>>
>>> --Andy
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1193647

On Mon, Jul 27, 2015 at 4:56 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Sure... but now you have to wrap things in stac/clac.  I'm not sure I see the point since the code is already pretty much optimal.

Ick.  I forgot about that.

It would benefit all the users who aren't using the _ex functions,
though.  And, if there are enough of those, it just might be worth
trying to postprocess object files to collapse adjacent stac and clac
instances, or just to teach the alternatives code to nop them out if
they're redundant.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1193654

There are certainly applications.  That just isn't one of them.

On July 27, 2015 4:58:29 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Mon, Jul 27, 2015 at 4:56 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> Sure... but now you have to wrap things in stac/clac.  I'm not sure I
>see the point since the code is already pretty much optimal.
>
>Ick.  I forgot about that.
>
>It would benefit all the users who aren't using the _ex functions,
>though.  And, if there are enough of those, it just might be worth
>trying to postprocess object files to collapse adjacent stac and clac
>instances, or just to teach the alternatives code to nop them out if
>they're redundant.
>
>--Andy

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1193662

However... perhaps we can do the flags stuff first?  There are certainly a ton of changes we ought to do.

On July 27, 2015 4:58:29 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Mon, Jul 27, 2015 at 4:56 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> Sure... but now you have to wrap things in stac/clac.  I'm not sure I
>see the point since the code is already pretty much optimal.
>
>Ick.  I forgot about that.
>
>It would benefit all the users who aren't using the _ex functions,
>though.  And, if there are enough of those, it just might be worth
>trying to postprocess object files to collapse adjacent stac and clac
>instances, or just to teach the alternatives code to nop them out if
>they're redundant.
>
>--Andy

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1193672

On Mon, Jul 27, 2015 at 5:35 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> However... perhaps we can do the flags stuff first?  There are certainly a ton of changes we ought to do.
>

Fine with me.  Flags are probably more generally useful, especially
because of the silly lack of output constraints on asm goto.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1193648

On Mon, Jul 27, 2015 at 4:46 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Sure, but that is different than getting rid of the _ex forms.
>

If we did that and got rid of the _ex forms, though, then the code
that matters (the no-fault case) would just be a bunch of movs, right?
 That's basically the same as the current _ex code.

--Andy

> On July 27, 2015 4:36:26 PM PDT, Andy Lutomirski <luto@amacapital.net>
> wrote:
>>
>> On Mon, Jul 27, 2015 at 4:22 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>
>>>  For that to work, gcc would have to know about the extable.
>>
>>
>> It could, I think:
>>
>> asm goto (
>>     "1: mov ...\n\t"
>>     _ASM_EXTABLE(1b, %l2)  /* or whatever index it is */
>>     : ... : ... : ... : efault);
>>
>> return 0;
>>
>> efault:
>>      return -EFAULT;
>>
>> I think that wrmsr_safe could get this treatment with current GCC.
>> put_user plausibly could, too, if we were willing to mark it volatile
>> and accept that we're lying a little bit about the lack of an output
>> constraint.  get_user would need GCC to understand output constraints
>> for real.
>>
>> --Andy
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web