- User Since
- Jul 27 2020, 8:22 AM (18 w, 4 d)
I will break out the instruction namespace change, submit a second Phabricator revision, and remove it from this revision. Probably not until Sunday, so let's carry on with this discussion.
@dblaikie will attest to the fact that I still don't understand the C++ baroque memory management model. It took me awhile to figure out how to use the std::unordered_map.
I'm about to push this revision. I will be surprised if it does not break the build.
Cool! It had seen the TODO and planned to do something about it, but didn't realize the class wasn't used at all.
Tue, Dec 1
Does it make sense to define a const for the value (uint64_t)-1?
Fixed some of the lint issues.
Sat, Nov 28
The TypeOf_xxx field is only used by the searchable tables backend. My trek through all the backends revealed it as the only one that needs to distinguish string and code, because it can emit the C++ initializer for any type of field. All the other backends know what is in each field they process. You can see from the various patches that there is nothing special about code fields in the other backends.
Yes, we could create !codeconcat instead, along with !codeinterleave, !codeeq, etc. We could also just extend the existing bang operators to work on the code type. I thought it was cleaner just to get rid of the distinction.
The TypeOf_xxx feature of searchable tables already exists. I just co-opted it as the way to tell the searchable table backend to emit the code without quotes. If we go with this revision, we will always need it in certain cases, when the code is constructed as a string and the backend cannot tell that it is a string.
I will auto-LGTM this on Monday.
Fri, Nov 27
I eliminated the new function and replaced it with the new option -sort-timers. Nice!
Thu, Nov 26
I still haven't gotten used to the fact that any old compilation unit can define command line options. Great idea!
Wed, Nov 25
Mon, Nov 23
I'm no expert on GlobalISelEmiitter, but it doesn't appear to perform this check now. Your new code looks good to my untrained eye.
Sun, Nov 22
I deleted some obsolete lines of code in Record.h.
Sat, Nov 21
Thu, Nov 19
Wed, Nov 18
I will auto-LGTM this revision on Friday.
Tue, Nov 17
Changed the child size to a size_t. And changed the VBR size to match.
I'll get this in as soon as there is some more review *and* I manage to reinstate my building ability. I just updated Visual Studio and can't build anything. Sigh.
Remove //// markers and make one final check.
Mon, Nov 16
I will auto-LGTM this on Tuesday.
Sun, Nov 15
Sat, Nov 14
Fri, Nov 13
I forgot to add the new -time-phases option to the xxx-tblgen documentation.
Thu, Nov 12
I'm not yet familiar enough with instruction selection, so I'll leave the decision to others.
Wed, Nov 11
I see no problem with this.
Tue, Nov 10
Mon, Nov 9
I will auto-LGTM this revision in 36 hours.
Restored the two !foldl operators discussed above.
Sun, Nov 8
Auto-LGTM. I will move on to cleaning up more IR files.
Sat, Nov 7
I will auto-LGTM this revision in 24 hours.
Fri, Nov 6
DA is an instruction field, not a boolean.
Duly added to my initialism list.
But what is "NFC"?
Thu, Nov 5
I will push this now.
Yes, I think it would be quite disruptive. But a strong stylistic suggestion in the documentation is in order.
I would have to invent a boolean type to prevent that assignment. That would be such a box of frogs that I quickly gave up on the idea. I'm not even sure we could do it compatibly. What would !eq(x, y) produce? And I don't think people would want !if(pred, ...) to require a boolean, since it doesn't in C++. [Much to my chagrin, and perhaps yours.]
Sorry, I'm not sure what you mean by "these." If you mean 'true' and 'false', they are simply named literals for 1 and 0. So they can be used in any context where an integer is allowed.
A minor suggestion: Use the new true/false literals in the TableGen files. I believe it makes the code easier to read.
Cleaned up the other TableGen files.
I see you accepted this revision. Shall I clean up the other .td files as part of this revision, or do them separately?
Cleaned out the spurious lines with ////.