<feed xmlns='http://www.w3.org/2005/Atom'>
<title>bcm5719-llvm/mlir/test/Transforms/Vectorize, branch meklort-10.0.1</title>
<subtitle>Project Ortega BCM5719 LLVM</subtitle>
<id>https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/'/>
<updated>2020-01-13T21:24:39+00:00</updated>
<entry>
<title>[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types.</title>
<updated>2020-01-13T21:24:39+00:00</updated>
<author>
<name>River Riddle</name>
<email>riverriddle@google.com</email>
</author>
<published>2020-01-13T21:12:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=4268e4f4b84b85266426e99050d31ec63f3ce8aa'/>
<id>urn:sha1:4268e4f4b84b85266426e99050d31ec63f3ce8aa</id>
<content type='text'>
Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map&lt;&gt;` and IntegerSetAttr is wrapped with `affine_set&lt;&gt;`.

Reviewed By: nicolasvasilache, ftynse

Differential Revision: https://reviews.llvm.org/D72429
</content>
</entry>
<entry>
<title>More affine expr simplifications for floordiv and mod</title>
<updated>2019-12-11T00:00:53+00:00</updated>
<author>
<name>Uday Bondhugula</name>
<email>uday@polymagelabs.com</email>
</author>
<published>2019-12-10T23:49:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=36a415bcc543553891af6809c5256e6e2469357d'/>
<id>urn:sha1:36a415bcc543553891af6809c5256e6e2469357d</id>
<content type='text'>
Add one more simplification for floordiv and mod affine expressions.
Examples:
 (2*d0 + 1) floordiv 2 is simplified to d0
 (8*d0 + 4*d1 + d2) floordiv 4 simplified to 4*d0 + d1 + d2 floordiv 4.
 etc.

 Similarly, (4*d1 + 1) mod 2 is simplified to 1,
            (2*d0 + 8*d1) mod 8 simplified to 2*d0 mod 8.

Change getLargestKnownDivisor to return int64_t to be consistent and
to avoid casting at call sites (since the return value is used in expressions
of int64_t/index type).

Signed-off-by: Uday Bondhugula &lt;uday@polymagelabs.com&gt;

Closes tensorflow/mlir#202

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/202 from bondhugula:affine b13fcb2f1c00a39ca5434613a02408e085a80e77
PiperOrigin-RevId: 284866710
</content>
</entry>
<entry>
<title>Drop MaterializeVectorTransfers in favor of simpler declarative unrolling</title>
<updated>2019-12-04T20:11:42+00:00</updated>
<author>
<name>Nicolas Vasilache</name>
<email>ntv@google.com</email>
</author>
<published>2019-12-04T20:11:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=edfaf925cfab38e02b281136a0d72a51d0e153a1'/>
<id>urn:sha1:edfaf925cfab38e02b281136a0d72a51d0e153a1</id>
<content type='text'>
Now that we have unrolling as a declarative pattern, we can drop a full pass that has gone stale. In the future we may want to add specific unrolling patterns for VectorTransferReadOp.

PiperOrigin-RevId: 283806880
</content>
</entry>
<entry>
<title>Refactor the LowerVectorTransfers pass to use the RewritePattern infra - NFC</title>
<updated>2019-11-14T23:40:07+00:00</updated>
<author>
<name>Nicolas Vasilache</name>
<email>ntv@google.com</email>
</author>
<published>2019-11-14T23:39:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=0b271b7dfe285064b8b237d18bfc923212e7a77b'/>
<id>urn:sha1:0b271b7dfe285064b8b237d18bfc923212e7a77b</id>
<content type='text'>
This is step 1/n in refactoring infrastructure along the Vector dialect to make it ready for retargetability and composable progressive lowering.

PiperOrigin-RevId: 280529784
</content>
</entry>
<entry>
<title>Move VectorOps to Tablegen - (almost) NFC</title>
<updated>2019-11-14T16:15:23+00:00</updated>
<author>
<name>Nicolas Vasilache</name>
<email>ntv@google.com</email>
</author>
<published>2019-11-14T16:10:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=f2b6ae99913d0049c7929160aed5f213b1081abb'/>
<id>urn:sha1:f2b6ae99913d0049c7929160aed5f213b1081abb</id>
<content type='text'>
This CL moves VectorOps to Tablegen and cleans up the implementation.

This is almost NFC but 2 changes occur:
  1. an interface change occurs in the padding value specification in vector_transfer_read:
     the value becomes non-optional. As a shortcut we currently use %f0 for all paddings.
     This should become an OpInterface for vectorization in the future.
  2. the return type of vector.type_cast is trivial and simplified to `memref&lt;vector&lt;...&gt;&gt;`

Relevant roundtrip and invalid tests that used to sit in core are moved to the vector dialect.

The op documentation is moved to the .td file.

PiperOrigin-RevId: 280430869
</content>
</entry>
<entry>
<title>Lower vector transfer ops to loop.for operations.</title>
<updated>2019-10-18T21:10:10+00:00</updated>
<author>
<name>Nicolas Vasilache</name>
<email>ntv@google.com</email>
</author>
<published>2019-10-18T21:09:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=9e7e297da33be70ec41335800c05b554f5de065b'/>
<id>urn:sha1:9e7e297da33be70ec41335800c05b554f5de065b</id>
<content type='text'>
This allows mixing linalg operations with vector transfer operations (with additional modifications to affine ops) and is a step towards solving tensorflow/mlir#189.

PiperOrigin-RevId: 275543361
</content>
</entry>
<entry>
<title>Use "standard" load and stores in LowerVectorTransfers</title>
<updated>2019-07-26T09:34:24+00:00</updated>
<author>
<name>Nicolas Vasilache</name>
<email>ntv@google.com</email>
</author>
<published>2019-07-26T09:33:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=fae4d94990fb0e9b79059bd8d93f84ff5ee996fc'/>
<id>urn:sha1:fae4d94990fb0e9b79059bd8d93f84ff5ee996fc</id>
<content type='text'>
Clipping creates non-affine memory accesses, use std_load and std_store instead of affine_load and affine_store.
In the future we may also want a fill with the neutral element rather than clip, this would make the accesses affine if we wanted more analyses and transformations to happen post lowering to pointwise copies.

PiperOrigin-RevId: 260110503
</content>
</entry>
<entry>
<title>EDSC: use affine.load/store instead of std.load/store</title>
<updated>2019-07-12T15:42:28+00:00</updated>
<author>
<name>Alex Zinenko</name>
<email>zinenko@google.com</email>
</author>
<published>2019-07-10T18:16:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=054e25c079279ba2ae564e4260a21a49eaed7797'/>
<id>urn:sha1:054e25c079279ba2ae564e4260a21a49eaed7797</id>
<content type='text'>
Standard load and store operations are evolving to be separated from the Affine
constructs.  Special affine.load/store have been introduced to uphold the
restrictions of the Affine control flow constructs on their operands.
EDSC-produced loads and stores were originally intended to uphold those
restrictions as well so they should use affine.load/store instead of
std.load/store.

PiperOrigin-RevId: 257443307
</content>
</entry>
<entry>
<title>Standardize the value numbering in the AsmPrinter.</title>
<updated>2019-07-09T17:41:00+00:00</updated>
<author>
<name>River Riddle</name>
<email>riverriddle@google.com</email>
</author>
<published>2019-07-09T17:40:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=89bc449cee6ca6b9d4c220a8782ee324fab565e0'/>
<id>urn:sha1:89bc449cee6ca6b9d4c220a8782ee324fab565e0</id>
<content type='text'>
Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations.

PiperOrigin-RevId: 257225069
</content>
</entry>
<entry>
<title>Globally change load/store/dma_start/dma_wait operations over to affine.load/store/dma_start/dma_wait.</title>
<updated>2019-07-03T21:37:06+00:00</updated>
<author>
<name>Andy Davis</name>
<email>andydavis@google.com</email>
</author>
<published>2019-07-03T17:35:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=2e1187dd25aee1c364e5273108c14e591656f19a'/>
<id>urn:sha1:2e1187dd25aee1c364e5273108c14e591656f19a</id>
<content type='text'>
In most places, this is just a name change (with the exception of affine.dma_start swapping the operand positions of its tag memref and num_elements operands).
Significant code changes occur here:
*) Vectorization: LoopAnalysis.cpp, Vectorize.cpp
*) Affine Transforms: Transforms/Utils/Utils.cpp

PiperOrigin-RevId: 256395088
</content>
</entry>
</feed>
