public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: <binutils@sourceware.org>
Subject: Re: [PATCH, v2] gas/x86: don't allow invalid operand combinations for VGATHER
Date: Tue, 07 Aug 2012 13:44:00 -0000	[thread overview]
Message-ID: <502135850200007800093425@nat28.tlf.novell.com> (raw)
In-Reply-To: <CAMe9rOo7s8t7+ZWThN2tk6PuQy8BBQtp0oJFYZGAwhXD6hgeYw@mail.gmail.com>

>>> On 07.08.12 at 15:21, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 3:28 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 31.07.12 at 17:43, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>> On Tue, Jul 31, 2012 at 12:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 30.07.12 at 18:10, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>> The assembler should only check the operands which can't be
>>>>> encoded.  It should shouldn't check if operands are functional
>>>>> correct.  However, I don't mind to issue an error which is controlled
>>>>> by a command line option.
>>>>
>>>> Hmm, not sure. Is there any precedent to such behavior? I as a
>>>> programmer would appreciate if the assembler rejected anything
>>>> that's invalid.
>>>>
>>>> In the case you stay on that position, would making the new
>>>> diagnostic an unconditional warning be acceptable instead?
>>>>
>>>
>>> Can you also add a command line option to turn it off and
>>> turn warning into error?
>>
>> How about this then?
>>
>> Jan
>>
>> The VGATHER group of instructions requires that all three involved
>> xmm/ymm registers are distinct. This patch adds code to check for this,
>> and at once eliminates a superfluous check for not using PC-relative
>> addressing for these instructions (the fact that an index register is
>> required here already excludes valid PC-relative addresses). The
>> severity of the resulting diagnostics can be controlled via command
>> line option or directive.
> 
> Why
> 
> vgatherdps %xmm2,(%rax,%xmm1,2),%xmm2
> 
> can't be used?  XMM2 can be used for both mask and
> destination.

Not that I'm aware of (quoting the documentation):

"If any pair of the index, mask, or destination registers are the
 same, this instruction results a #UD fault."

It's my understanding that this is because of the restartability of
the instruction (i.e. if the same register served as mask and
destination, the instruction might never complete if the loaded
vector element had its high bit set).

Jan

  reply	other threads:[~2012-08-07 13:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-24 14:19 [PATCH] x86: " Jan Beulich
2012-07-30 16:10 ` H.J. Lu
2012-07-31  7:49   ` Jan Beulich
2012-07-31 15:44     ` H.J. Lu
2012-07-31 16:24       ` Jan Beulich
2012-08-07 10:32       ` [PATCH, v2] gas/x86: " Jan Beulich
2012-08-07 13:25         ` H.J. Lu
2012-08-07 13:44           ` Jan Beulich [this message]
2012-08-07 14:07             ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=502135850200007800093425@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).