public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Cui, Lili" <lili.cui@intel.com>
To: "Beulich, Jan" <JBeulich@suse.com>
Cc: "hjl.tools@gmail.com" <hjl.tools@gmail.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>
Subject: RE: [PATCH 1/3] Support APX CCMP and CTEST
Date: Fri, 14 Jun 2024 03:29:45 +0000	[thread overview]
Message-ID: <SJ0PR11MB56002DCF8C62A63D96806B389EC22@SJ0PR11MB5600.namprd11.prod.outlook.com> (raw)
In-Reply-To: <b89f38f7-4007-4174-ab3d-1647c13e0eb3@suse.com>

> >>> @@ -1929,6 +1939,114 @@ static INLINE bool need_evex_encoding
> (const
> >>> insn_template *t)  #define CPU_FLAGS_PERFECT_MATCH \
> >>>    (CPU_FLAGS_ARCH_MATCH | CPU_FLAGS_64BIT_MATCH)
> >>>
> >>> +static INLINE bool set_oszc_flags (unsigned int oszc_shift) {
> >>> +  if (i.oszc_flags & oszc_shift)
> >>> +    {
> >>> +      as_bad (_("same oszc flag used twice"));
> >>> +      return false;
> >>> +    }
> >>> +  i.oszc_flags |= oszc_shift;
> >>> +  return true;
> >>> +}
> >>> +
> >>> +/* Handle SCC OSZC flags.  */
> >>> +
> >>> +static int
> >>> +check_Scc_OszcOperations (const char *l) {
> >>> +  const char *suffix_string = l;
> >>> +  bool has_dfv = false;
> >>> +
> >>> +  while (is_space_char (*suffix_string))
> >>> +    suffix_string++;
> >>> +
> >>> +  /* If {oszc flags} is absent, just return.  */  if
> >>> + (*suffix_string != '{')
> >>> +    return 0;
> >>> +  else
> >>> +    suffix_string++;
> >>
> >> Just to mention it: I'm pretty strongly against using "else" in cases
> >> like this
> >> one: It's more code, hence - even if just slightly - harder to read,
> >> for no gain at all. If you keep it like that, I may subsequently go
> >> through and purge all of those.
> >
> > Dropped 'else' here.
> 
> Thanks. You realize though that I used this as example; there were several
> more similar uses of "else" in the patch.
> 

I found a similar situation in this function and made changes, thanks for the reminder.

> >>> +  /* Parse 'dfv='.  */
> >>> +  while (*suffix_string)
> >>> +    {
> >>> +      if (is_space_char (*suffix_string))
> >>> +	suffix_string++;
> >>> +      else if (*suffix_string == '=')
> >>> +	{
> >>> +	  suffix_string++;
> >>> +	  break;
> >>> +	}
> >>> +      else if (startswith (suffix_string, "dfv") && !has_dfv)
> >>> +	{
> >>> +	  suffix_string += 3;
> >>> +	  has_dfv = true;
> >>> +	}
> >>> +      else
> >>> +	{
> >>> +	  as_bad (_("Unrecognized pseudo-suffix"));
> >>> +	  return -1;
> >>> +	}
> >>> +    }
> >>
> >> Hmm, a pretty firm expectation of mine was that this now wouldn't be
> >> done as a loop anymore. It's not strictly necessary to change, yet it
> >> looks as if this code structure wouldn't lend itself to there
> >> appearing another pseudo-suffix, which then also would want recognizing
> here.
> >>
> > My initial thought was that using a loop would make it easier to get rid of
> the extra spaces. If the loop is removed, the code becomes as follows, the
> space removal operation needs to be repeated.
> >
> >   while (is_space_char (*suffix_string))
> >     suffix_string++;
> >
> >   if (strcasecmp (suffix_string, "dfv") > 0)
> >     suffix_string += 3;
> >  else
> >   as_bad (_("Unrecognized pseudo-suffix"));
> >
> >   while (is_space_char (*suffix_string))
> >     suffix_string++;
> >
> >   if (*suffix_string == '=')
> >     suffix_string++;
> >  else
> >     as_bad (_("Unrecognized pseudo-suffix"));
> 
> First: Whitespace removal doesn't need loops, if other code is to be trusted.
> The scrubber collapses multiple of them into a single one anyway.
> Second: The as_bad() here want following by bailing from the function.
> Third: As indicated, I won't insist on you switching away from the loop you
> had. I merely think that the alternative is better both from a source clarity
> perspective and for resulting runtime behavior.
> 

I prefer the loop one.

> >>> +  /* Parse 'of , sf, zf, cf}'.  */
> >>> +  while (*suffix_string)
> >>> +    {
> >>> +      if (*suffix_string == ',' || is_space_char (*suffix_string))
> >>> +	suffix_string++;
> >>
> >> Like for the earlier loop in the earlier version: Is it really okay
> >> to have multiple successive commas (with or without whitespace in
> between)?
> >
> > Ok, I'll add a check for it.
> 
> It's not really another check that's needed. When put at the bottom of the
> loop body, your expectation simply is to find a brace or a comma. Anything
> else is an error. (That way "{dfv=,cf}" would then also be properly
> rejected.)
> 

I don't understand the logic of your approach, I think I missed some information. Currently I am using the following method to implement it.

bool check_comma = true;

  while (*suffix_string)
    {
      if (*suffix_string == ',')
        {
          /* Report an error for illegal commas.  */
          if (check_comma == true)
            {
              as_bad (_("Illegal comma found in pseudo-suffix"));
              return -1;
            }
          check_comma = true;
          suffix_string++;
        }
      else if (is_space_char (*suffix_string))
        suffix_string++;
      else if (*suffix_string == '}')
        {
          suffix_string++;
          return suffix_string - l;
        }
      else
        {
          check_comma = false;
          ...
          suffix_string += 2;
        }
    }

> >>> @@ -10637,6 +10692,19 @@ putop (instr_info *ins, const char
> >> *in_template, int sizeflag)
> >>>  		  evex_printed = true;
> >>>  		}
> >>>  	    }
> >>> +	  else if (l == 1 && last[0] == 'D')
> >>> +	    {
> >>> +	      /* Get oszc flags value from register_specifier.  */
> >>> +	      int oszc_value = ~ins->vex.register_specifier & 0xf;
> >>> +
> >>> +	      /* Add {dfv=of, sf, zf, cf} flags.  */
> >>> +	      oappend (ins, oszc_flags[oszc_value]);
> >>> +
> >>> +	      /* These bits have been consumed and should be cleared or
> >> restored
> >>> +		 to default values.  */
> >>> +	      ins->vex.v = 1;
> >>> +	      ins->vex.register_specifier = 0;
> >>
> >> vex.register_specifier was consumed here, yes, but vex.v belongs to
> >> SCC handling, doesn't it?
> >
> > Oh! yes, vex.v and vex.nf share the same bit.
> 
> They don't, do they? EVEX.NF aliases EVEX.SC2, while EVEX.V4 aliases
> EVEX.SC3 afaics. The two belong together, though (as said in the earlier reply).
> 
Yes, you are right.

Thanks,
Lili.

  reply	other threads:[~2024-06-14  3:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11  8:06 [PATCH 0/3] " Cui, Lili
2024-06-11  8:06 ` [PATCH 1/3] " Cui, Lili
2024-06-12 14:37   ` Jan Beulich
2024-06-13 10:30     ` Cui, Lili
2024-06-13 11:31       ` Jan Beulich
2024-06-14  3:29         ` Cui, Lili [this message]
2024-06-14  6:21           ` Jan Beulich
2024-06-14 10:29             ` Cui, Lili
2024-06-11  8:06 ` [PATCH 2/3] Remove %ME and used %NE for movbe Cui, Lili
2024-06-12 14:40   ` Jan Beulich
2024-06-11  8:06 ` [PATCH 3/3] Fix typo in i386-dis-evex-mod.h Cui, Lili
2024-06-12 14:39   ` Jan Beulich

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=SJ0PR11MB56002DCF8C62A63D96806B389EC22@SJ0PR11MB5600.namprd11.prod.outlook.com \
    --to=lili.cui@intel.com \
    --cc=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).