public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Indu Bhagat <indu.bhagat@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH,V2] gas: x86: ginsn: adjust ginsns for certain lea ops
Date: Thu, 25 Jan 2024 00:46:46 -0800	[thread overview]
Message-ID: <aa3fd55f-0962-4006-8480-2a38b5992aa3@oracle.com> (raw)
In-Reply-To: <c3f859f5-34e6-484e-b1af-326c728c19d3@suse.com>

On 1/24/24 23:33, Jan Beulich wrote:
>>>>          dst_reg = ginsn_dw2_regnum (i.op[1].regs);
>>>> -      ginsn = ginsn_new_other (insn_end_sym, true,
>>>> -			       GINSN_SRC_REG, index_reg,
>>>> -			       GINSN_SRC_IMM, index_scale,
>>>> -			       GINSN_DST_REG, dst_reg);
>>>> -      /* FIXME - It seems to make sense to represent a scale factor of 1
>>>> -	 correctly here (i.e. not as "other", but rather similar to the
>>>> -	 base-without- index case above)?  */
>>>> -    }
>>>> -  else
>>>> -    {
>>>> -      /* lea disp(%base,%index,imm) %dst.  */
>>>> -      /* TBD_GINSN_INFO_LOSS - Skip adding information about the disp and imm
>>>> -	 for index reg.  */
>>>> -      base_reg = ginsn_dw2_regnum (i.base_reg);
>>>> -      index_reg = ginsn_dw2_regnum (i.index_reg);
>>>> -      dst_reg = ginsn_dw2_regnum (i.op[1].regs);
>>>> -      /* Generate an GINSN_TYPE_OTHER ginsn.  */
>>>> -      ginsn = ginsn_new_other (insn_end_sym, true,
>>>> -			       GINSN_SRC_REG, base_reg,
>>>> -			       GINSN_SRC_REG, index_reg,
>>>> -			       GINSN_DST_REG, dst_reg);
>>>> -    }
>>>> +      /* It makes sense to represent a scale factor of 1 precisely here
>>>> +	 (i.e., not using GINSN_TYPE_OTHER, but rather similar to the
>>>> +	 base-without-index case).  Ignore the case when disp has a symbol
>>>> +	 instead.  */
>>>> +      if (!index_scale
>>>> +	  && (!i.disp_operands
>>>> +	      || (i.disp_operands && i.op[0].disps->X_op == O_constant)))
>>> This is functionally identical to the shorter
>>>
>>>         if (!index_scale
>>> 	  && (!i.disp_operands || i.op[0].disps->X_op == O_constant))
>>>
>>> But: What about any of
>>>
>>> 	lea	(%rax,%riz),%rbp
>>> 	lea	(%rax,4),%rbp
>>> 	lea	(%rax,%riz,4),%rbp
>>>
>>> ?
>> Current behaviour is:
>>
>> lea  (%rax,%riz),%rbp
>> ginsn: OTH 0, 0, %r6
> Ought to be MOV?
> 

MOV is more precise, thats true here...

>> lea  (%rax,4),%rbp
>> ****  Warning: scale factor of 4 without an index register
>> ginsn: MOV %r0, %r6
> Oh, right - the scale factor is zapped in that case along with issuing
> the warning. That's not quite right though, I suppose.
> 
>> lea  (%rax,%riz,4),%rbp
>> ginsn: OTH 0, 0, %r6
> Ought to be MOV again?
> 

..and here again. But I am inclined to just leave them as OTH for the 
same reason, we left the sub-case handling of lea symbol, %dst : this is 
better expressed as a MOV itself.

>> lea  sym(,%riz), %rbp
>> ginsn: OTH 0, 0, %r6
>>
>> lea  (,%riz), %rbp
>> ginsn: MOV %r4, %r6
>> (We use DWARF register number 4 {%rsi} in lieu of %riz).
> Where's the 4 coming from? That doesn't look right. Imo when you
> create insns other than OTHER, they should be correct. Irrespective
> of SCFI's needs. (The case here is no different from "lea const, ..."
> so ought to be handled like that.)

Since %riz is a pseudo register, and we need a DWARF register number in 
the ginsn representation, I designated %rsi to be used instead when %riz 
or %rip appears. This adds a inexistent data flow dependence, but I 
judged that this _should_ be ok (as not callee-saved register).

That said, for this specific case of 'lea (,%riz), %rbp', generating 
ginsn GINSN_TYPE_OTHER does seem better. I agree that when we create 
ginsn other than GINSN_TYPE_OTHER, they should be as precise as possible.

I can add a check of (!i.index_reg || i.index_reg->reg_num != RegIZ) and 
  handle lea (,%riz), %rbp as GINSN_TYPE_OTHER.



      reply	other threads:[~2024-01-25  8:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24  6:40 Indu Bhagat
2024-01-24  7:51 ` Jan Beulich
2024-01-24 23:56   ` Indu Bhagat
2024-01-25  7:33     ` Jan Beulich
2024-01-25  8:46       ` Indu Bhagat [this message]

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=aa3fd55f-0962-4006-8480-2a38b5992aa3@oracle.com \
    --to=indu.bhagat@oracle.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.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).