This is an archive of the discontinued LLVM Phabricator instance.

[X86][NFC] Refactor X86InstrArithmetic.td by class
ClosedPublic

Authored by XinWang10 on Feb 15 2023, 5:51 PM.

Details

Summary
  1. Extract the common code of some instructions into a class to reduce duplication
  2. Refine some comments to the make the description of the class clearer

By this way, the records defined here will be consistent and easier to
maintain, I think.

Diff Detail

Event Timeline

XinWang10 created this revision.Feb 15 2023, 5:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 15 2023, 5:51 PM
XinWang10 requested review of this revision.Feb 15 2023, 5:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 15 2023, 5:51 PM
XinWang10 updated this revision to Diff 497858.Feb 15 2023, 6:03 PM
  • move add_flag_nocf
skan added inline comments.Feb 15 2023, 6:14 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
53–54

This class looks common, could we move it to X86InstrFormats..td?

skan added inline comments.Feb 15 2023, 6:31 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
408

It seems this class is never used?

689

Could we define MulOpR as a multiclass and use defm IMUL?

XinWang10 added inline comments.Feb 15 2023, 6:32 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
53–54

I find now this class is only used in X86InstrArithmetic.td

skan added inline comments.Feb 15 2023, 6:44 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
426

Please make sure that a class is not defined when it is only used at one place, otherwise it's too overdesign.

XinWang10 added inline comments.Feb 15 2023, 6:51 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
408

Actually, will remove.

689

I don't know if it is necessary? In my understanding, class and multiclass is designed for reuse, but if I rewrite a MulOpR as a multiclass here for IMUL, seems it has only one user here?

XinWang10 marked 2 inline comments as not done.Feb 15 2023, 6:55 PM
skan added inline comments.Feb 15 2023, 6:57 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
689

What's difference? You already define class MulOpR for MUL and IMUL, and if we change it to multiclass, couldn't we use it for MUL and IMUL as well? And the suffix "8r", "16r", "32r", "64r" can be written only once.

XinWang10 added inline comments.Feb 15 2023, 7:10 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
426

This is designed to be consistent with other class I wrote, it is unnecessary but make sense to me?

craig.topper added inline comments.Feb 15 2023, 7:20 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
415

Identation is off here

421

and here

434

and here

440

and here.

454

This Requires looks kind of funny. Might be better to switch to let Predicates = [Not64BitMode]

508

indentation is off

517

This is probably indented too far. It looks like its part of the [ expression

521

indentation

529

indentation

531

indentation

XinWang10 added inline comments.Feb 15 2023, 7:32 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
689

Because MUL8r and IMUL8r have different pattern.

skan added inline comments.Feb 15 2023, 7:34 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
426

It doesn't make sense to me. If nested inheritance, e.g. A->B->C, when I need to know what actually C is, I have to look at both B and A. This kind of mind burden should be avoid for maintainers and developers when B is used only once.

XinWang10 added inline comments.Feb 15 2023, 7:45 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
415

Hi, I'm not clear about the Identation rule here, could you please give me an example here?

454

will do

689

I get your point, will take a try.

XinWang10 added inline comments.Feb 15 2023, 10:27 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
689

@skan MUL can't share multiclass with IMUL, take a look at MUL8r/m and IMUL8r/m, MUL8r/m has a pattern inside without sideeffect=0, seems cannot easily make them together as ADD etc.

  • resolve some comments
  • adjust identation
XinWang10 updated this revision to Diff 498235.Feb 16 2023, 6:49 PM
  • fix build fail
XinWang10 updated this revision to Diff 498236.Feb 16 2023, 6:50 PM
  • adjust identation
skan added inline comments.Feb 16 2023, 7:18 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
53–54

X86TypeInfo and Xi* are common and might be used by at other instruction TDs. The fact is that we always use X86InstrArithmetic.td and X86InstrFormats..td together, and the former is bigger than the latter. Moving can make X86InstrArithmetic.td easier to read by reducing the size of a big file.

407

Could we change this comment? I never like this style of comment b/c it looks almost same as "INCDECM - Instructions like "inc [mem]". which is confusing.

We may change the comment to “Unary instructions with a memory operand”

Similarly for other classes in this file like BinOpMI8, etc.

XinWang10 marked 13 inline comments as done and an inline comment as not done.Feb 16 2023, 7:32 PM
XinWang10 added inline comments.
llvm/lib/Target/X86/X86InstrArithmetic.td
407

Yes, will do.

XinWang10 updated this revision to Diff 498250.Feb 16 2023, 9:52 PM
  • update comment for base unary and binary class
skan added inline comments.Feb 16 2023, 10:29 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
74

Binary already indicates two. I would suggest "Binary instructions with inputs "reg, reg"

204–205

Binary instructions with inputs "reg, imm", output "reg" and write EFLAGS

211–213

Binary instructions with inputs "reg, imm", output "reg" and read/write EFLAGS

skan added inline comments.Feb 16 2023, 10:31 PM
llvm/lib/Target/X86/X86InstrArithmetic.td
470

Misplaced comment

476

Misplaced comment

  • fix comment further
skan added inline comments.Feb 17 2023, 1:25 AM
llvm/lib/Target/X86/X86InstrArithmetic.td
498

This class is misleading. From the comment "BinOpRRxMI - Binary instructions with inputs "reg/[mem], imm". I would understand the input is reg, imm or  mem imm. In fact, all the thing it says is that "I have a output register and I have two input"

I suggest to remove this class and use ITy instead.

XinWang10 added inline comments.Feb 17 2023, 1:39 AM
llvm/lib/Target/X86/X86InstrArithmetic.td
498

Agree.

XinWang10 edited the summary of this revision. (Show Details)Feb 17 2023, 2:22 AM
XinWang10 updated this revision to Diff 498296.Feb 17 2023, 2:23 AM
  • remove misleading class
skan added inline comments.Feb 17 2023, 2:59 AM
llvm/lib/Target/X86/X86InstrArithmetic.td
422

Drop the _C suffix, this class does not have the constraint in the definition. And update the comments

XinWang10 updated this revision to Diff 498306.Feb 17 2023, 3:10 AM
  • resolve comments
skan added inline comments.Feb 17 2023, 3:53 AM
llvm/lib/Target/X86/X86InstrArithmetic.td
720–728

The only difference between Xi64x and Xi64 is the "small use of immediate", which is defined in X86InstrInfo.td. e,g imm_su <-> imm

imm_su is not used here b/c IMUL are not binary operations.

so the suffix x here is not appropriate.

I would suggest you add one field SDPatternOperator ImmNoSuOperator in X86TypeInfo and use Xi16, Xi32, Xi64 for IMUL too.

XinWang10 edited the summary of this revision. (Show Details)Feb 17 2023, 3:54 AM
XinWang10 updated this revision to Diff 498706.Feb 19 2023, 6:10 PM
  • remove Xinnx
  • add missing comment
skan accepted this revision.Feb 21 2023, 1:47 AM

LGTM

This revision is now accepted and ready to land.Feb 21 2023, 1:47 AM
skan retitled this revision from [X86]Use Class to refactor ArithMetic td file in X86 to [X86][NFC] Refactor X86InstrArithmetic.td by class.Feb 21 2023, 1:52 AM
skan edited the summary of this revision. (Show Details)Feb 21 2023, 1:57 AM
This revision was landed with ongoing or failed builds.Feb 21 2023, 5:20 PM
This revision was automatically updated to reflect the committed changes.