maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
2,027 Commits 23 Branches 0 Tags 2.2 GiB
Commit Graph

5 Commits

Author SHA1 Message Date
River Riddle 679a3b4191 Change the attribute dictionary syntax to separate name and value with '='. 
The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations:

Old:
  "foo: 10 : i32"

New:
  "foo = 10 : i32"
PiperOrigin-RevId: 255097928
 2019-06-25 19:06:34 -07:00
Nicolas Vasilache dac75ae5ff Split test-specific passes out of mlir-opt 
Instead put their impl in test/lib and link them into mlir-test-opt

PiperOrigin-RevId: 254837439
 2019-06-24 17:47:12 -07:00
River Riddle 704a7fb13e Add support for 1->N type mappings in the dialect conversion infrastructure. To support these mappings a hook must be overridden on the type converter: 'materializeConversion' :to generate a cast operation from the new types to the old type. This operation is automatically erased if all uses are removed, otherwise it remains in the IR for the user to handle. 
PiperOrigin-RevId: 254411383
 2019-06-22 09:16:06 -07:00
River Riddle 9764ae3f24 Refactor the TypeConverter to support more robust type conversions: 
* Support for 1->0 type mappings, i.e. when the argument is being removed.
* Reordering types when converting a type signature.
* Adding new inputs when converting a type signature.

This cl also lays down the initial foundation for supporting 1->N type mappings, but full support will come in a followup.

Moving forward, function signature changes will be driven by populating a SignatureConversion instance. This class contains all of the necessary information for adding/removing/remapping function signatures; e.g. addInputs, addResults, remapInputs, etc.

PiperOrigin-RevId: 254064665
 2019-06-19 23:08:33 -07:00
River Riddle 5da741f671 Add basic cost modeling to the dialect conversion infrastructure. This initial cost model favors specific patterns based upon two criteria: 
1) Lowest minimum pattern stack depth when legalizing.
  - This leads the system to favor patterns that have lower legalization stacks, i.e. represent a more direct mapping to the target.

2)  Pattern benefit.
  - When considering multiple patterns with the same legalization depth, this favors patterns with a larger specified benefit.

PiperOrigin-RevId: 252713470
 2019-06-19 22:59:06 -07:00