This is an archive of the discontinued LLVM Phabricator instance.

Change order of tablegen generated fastisel instruction code to be based on instruction complexity
ClosedPublic

Authored by seurer on Nov 11 2014, 1:06 PM.

Details

Summary

The order that tablegen fastisel instruction code is generated is currently based on the text of the predicate (using string lessthan). This patch changes this to instead use the instruction complexity. Because the complexities are not unique a C++ multimap is used instead of a map.

This fixes the problem where code with no predicate always comes out first (the empty string always compares as less than all other strings) thus making the code with predicates dead code. See the FMUL code in PPCFastISel.cpp for an example. It also more closely matches the normal codegen ordering. Some error checking in the tablegen fastisel code is fixed as well.

Diff Detail

Event Timeline

seurer updated this revision to Diff 16057.Nov 11 2014, 1:06 PM
seurer retitled this revision from to Change order of tablegen generated fastisel instruction code to be based on instruction complexity.
seurer updated this object.
seurer edited the test plan for this revision. (Show Details)
seurer added reviewers: echristo, hfinkel, wschmidt.
seurer added a subscriber: Unknown Object (MLST).
wschmidt edited edge metadata.Nov 11 2014, 1:34 PM

I like this approach. What did you do to verify the code that's produced for various targets? (You probably told me this but I've forgotten.)

/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
767–768

You didn't introduce the problem, but there's a pretty large factoring opportunity between the code below and the sequence starting at 651. It would be nice to clean that up as long as you're in here.

In D6220#4, @wschmidt wrote:

I like this approach. What did you do to verify the code that's produced for various targets? (You probably told me this but I've forgotten.)

I went through some of the generated fastisel .inc files comparing them to a version generated without this change to see if anything stood out as broken. The ordering is different of course but I am not familiar with the other targets and so I don't know if they are OK or not. For Power it was all OK.

I tried to build the X86 target on my laptop to run tests there but I never got it to work.

/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
767–768

Yeah, I noticed that those two sections of code were the same.

seurer added inline comments.Nov 11 2014, 1:46 PM
/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
730

Should this PrintWarning be an PrintError or an assert? The X86 target actually hits this at least once so perhaps there is some problem there.

hfinkel added inline comments.Nov 11 2014, 4:04 PM
/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
600

Make sure you're not adding lines > 80 cols.

echristo edited edge metadata.Nov 11 2014, 4:35 PM
In D6220#5, @seurer wrote:
In D6220#4, @wschmidt wrote:

I like this approach. What did you do to verify the code that's produced for various targets? (You probably told me this but I've forgotten.)

I went through some of the generated fastisel .inc files comparing them to a version generated without this change to see if anything stood out as broken. The ordering is different of course but I am not familiar with the other targets and so I don't know if they are OK or not. For Power it was all OK.

I tried to build the X86 target on my laptop to run tests there but I never got it to work.

What problems did you have here? (Though the tests in test/CodeGen/X86 should pass either way)

In D6220#8, @echristo wrote:
In D6220#5, @seurer wrote:
In D6220#4, @wschmidt wrote:

I like this approach. What did you do to verify the code that's produced for various targets? (You probably told me this but I've forgotten.)

I went through some of the generated fastisel .inc files comparing them to a version generated without this change to see if anything stood out as broken. The ordering is different of course but I am not familiar with the other targets and so I don't know if they are OK or not. For Power it was all OK.

I tried to build the X86 target on my laptop to run tests there but I never got it to work.

What problems did you have here? (Though the tests in test/CodeGen/X86 should pass either way)

The configure script complained about Python and I can't get it (Python) to build for some reason. I still plan on trying to get it to work.

Weird, what platform are you on? Anyhow, we can take that out of the code review. make check did pass on your ppc machine I gather?

In D6220#10, @echristo wrote:

Weird, what platform are you on? Anyhow, we can take that out of the code review. make check did pass on your ppc machine I gather?

make check works just fine.

In general looks good. Couple of inline comments and fixing the bit that Bill pointed out would be nice.

/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
726

Too many negatives in this comment, could you reword please?

730

This would be nice to track down. What's running into it?

seurer added inline comments.Nov 13 2014, 7:44 AM
/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
730

llvm[3]: Building X86.td "fast" instruction selector implementation with tblgen
warning:Multiple instructions match and one with no predicate came before one with a predicate! name:VBROADCASTSSZr predicate: (Subtarget->hasAVX512())

.. unsigned fastEmit_X86ISD_VBROADCAST_MVT_v4f32_MVT_v16f32_r(unsigned Op0, bool Op0IsKill) {
.. return fastEmitInst_r(X86::VBROADCASTSSZr, &X86::VR512RegClass, Op0, Op0IsKill);
.. if ((Subtarget->hasAVX512())) {
.. return fastEmitInst_r(X86::VBROADCASTSSZr, &X86::VR512RegClass, Op0, Op0IsKill);
.. }
.. }

That function comes out the same way either or without these changes.

echristo added inline comments.Nov 13 2014, 12:30 PM
/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
730

That's... lovely.

Don't worry about it. I've looked at the .td files and it would need some work to fix it. It is a problem in the X86 backend, but until we can fix it we can't do anything about it.

Perhaps file a bug and leave a comment that this should be an error?

seurer updated this revision to Diff 16180.Nov 13 2014, 2:23 PM
seurer edited edge metadata.

I updated the code with changes to address all the comments so far.

Couple of inline comments.

/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
596–599

Is there a reason we either a) don't want this on by default, or b) would never want this on?

646

Can you file a bug for this and then link the PR?

seurer added inline comments.Nov 13 2014, 2:47 PM
/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
596–599

When I tried it generated over 150 warnings so it's probably just too noisy. I wasn't sure if multiple patterns having the same complexity could be a potential issue, though.

echristo added inline comments.Nov 13 2014, 2:50 PM
/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
596–599

Yeah, I don't think so. Go ahead and just delete the commented out code with a "Two patterns could have the same complexity and we just end up picking the first one" or something like that. (I think it's the first one at this point?)

seurer added inline comments.Nov 13 2014, 2:57 PM
/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
596–599

They all will still be generated because the predicates are different. I believe the order will be the order in which they are encountered.

"When iterating over a std::multimap the elements are ordered by key, but the order of elements having the same key is not specified."

Hmmm, maybe not.

hfinkel edited edge metadata.Nov 13 2014, 3:10 PM
  • Original Message -----

From: "Bill Seurer" <seurer@linux.vnet.ibm.com>
To: seurer@linux.vnet.ibm.com, hfinkel@anl.gov, echristo@gmail.com, wschmidt@linux.vnet.ibm.com
Cc: llvm-commits@cs.uiuc.edu
Sent: Thursday, November 13, 2014 4:57:55 PM
Subject: Re: [PATCH] Change order of tablegen generated fastisel instruction code to be based on instruction
complexity

Comment at:
/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp:595
@@ -570,2 +594,3 @@

  • SimplePatterns[Operands][OpcodeName][VT][RetVT][PredicateCheck]

Memo;

+ This was used when testing
+
if
(SimplePatterns[Operands][OpcodeName][VT][RetVT].count(complexity))

{

echristo wrote:

seurer wrote:

echristo wrote:

Is there a reason we either a) don't want this on by default,
or b) would never want this on?

When I tried it generated over 150 warnings so it's probably just
too noisy. I wasn't sure if multiple patterns having the same
complexity could be a potential issue, though.

Yeah, I don't think so. Go ahead and just delete the commented out
code with a "Two patterns could have the same complexity and we
just end up picking the first one" or something like that. (I
think it's the first one at this point?)

They all will still be generated because the predicates are
different. I believe the order will be the order in which they are
encountered.

"When iterating over a std::multimap the elements are ordered by key,
but the order of elements having the same key is not specified."

Hmmm, maybe not.

It was unspecified in C++ before C++11, but since C++11, the order is specified to be stable. LLVM has other dependencies on this, IIRC.

http://stackoverflow.com/questions/2643473/does-stdmultiset-guarantee-insertion-order?rq=1

-Hal

http://reviews.llvm.org/D6220

Ah, thanks Hal.

LGTM then with the comment change.

-eric

seurer updated this revision to Diff 16218.Nov 14 2014, 9:18 AM
seurer edited edge metadata.

Final (I hope) source updates with all comments taken into account.

echristo accepted this revision.Nov 14 2014, 9:54 AM
echristo edited edge metadata.

One nit and LGTM.

Thanks for all the work here!

-eric

/home/seurer/llvm/llvm-oneoff/utils/TableGen/FastISelEmitter.cpp
647

Canonical naming is "PR21575".

This revision is now accepted and ready to land.Nov 14 2014, 9:54 AM
seurer updated this revision to Diff 16230.Nov 14 2014, 10:45 AM
seurer edited edge metadata.

Corrected reference to PR21575

wschmidt closed this revision.Nov 14 2014, 1:06 PM

I added the missing period! ;) Also, I committed the patch on Bill's behalf. r222038. Thanks for the work, Bill!