User Details
- User Since
- Apr 1 2014, 1:52 PM (425 w, 3 d)
Jun 30 2021
<format>
Second prototype. There is one subtle difference: the old ArithBuilder had only a reference to a builder, so if the original builder was changed, it would change the one used by the ArithBuilder too. In this new version, ArithBuilder is a builder specialized for arithmetic ops, and thus changes to an original builder will not impact it's version.
Nov 4 2020
renamed pattern rewriter function to match the StdExpandDivs theme.
Nov 3 2020
implemented the requested changes, including the pass name change from -std-to-std-lowering to -std-expand-divs.
Oct 29 2020
responded to comments, including the removal of the n*m>0 test that may overflow by a logical equivalent using n and m compares only.
Oct 28 2020
removed redundant includes and mlir:: qualifier, corrected the comments copied over (sorry)
@silvas Will push an update with fixes for your comment. One thing I do not know and input would be appreciated. Should this pass be added in the "mlir driver"? If so, can you recommend where the pass should be added. Thanks
Followed the suggestion to include the handling of ceil and floor (generic version supporting arbitrary pos/neg nominator/denominator) as a separate std to std pass. I also removed "auto" where easily substituted by the actual type, fixed the description of the ops as requested, and fixed a couple of other suggestions.
Oct 27 2020
Oct 19 2020
Oct 1 2020
Added suggestion, thanks for attempting to clarify the original text, much appreciated.
Sep 23 2020
Thanks, glad to see that the traits make such changes easy... Please correct Uday's nit, and its good to go.
Sep 18 2020
@imaihal Thanks for the upgrade. Minor nit still remains, please fix.
Sep 9 2020
Just my two cents; LE vs BE typically gives problem when a program read data with one data size, and write data with another size. So if the reader in the dense attributes respect the type size, namely read and write the data using the same format, and then generate the hex directly from the register content, then there are no issues with endianness.
Sep 1 2020
Rephrasing the question.
Aug 27 2020
yes please.
Aug 26 2020
@bondhugula I don't believe I have commit privilege yet. Please commit for me, if you don't mind.
Aug 25 2020
Completed all current requests for changes.
performed all requested changes but one. Left a clarification request for the suggestion that I am not sure to understand properly.
Update to reflect latest comments.
Aug 24 2020
Implemented all of the requested changes. Introduced at TODO for partially normalizable operations.
Aug 20 2020
added proper order for traits
Added revisions suggested for comments.
Added requested doc, edited the summary to be more specific with respect to the contribution of this patch, and removed a prior TODO with respect to recognizing operations that can be normalized by systematically using the new trait.
Aug 19 2020
remove spurious commented code
This functionality makes it very straightforward to develop SIMD code and replicate at a high level the ability to view memory as either scalar or SIMD code with very few restrictions.
Aug 18 2020
Once this patch is in, I have a follow on patch that introduces a new trait, MemRefNormalizable to be used by operations (such as DeallocOp, CallOp, ReturnOp) as well as any ops, for example, such as operations of an dialect that 1) will be expanded to external calls at some later time and 2) are ok with having their memrefs normalized to get rid of their maps.
LGTM
Aug 13 2020
Looking into extending this approach to handle dialect ops that will become calls to external functions. Specifically, I am looking for a way to express that an operation guarantees that (when it will be lowered to an external function call), the external function be aware of the data layout of the maps and thus it is safe to normalize the op memref parameters.
Aug 11 2020
@bondhugula Static is easy. We are working on making it work for the dynamic shapes, currently in our code base but we could migrate it to the MLIR as part of another patch. Basically, we go back to the alloc responsible for the array, and parse the memref to pick either a constant or the right alloc parameter corresponding to the n th '?' in the memref of the alloc.
I tried the patch and this simple code appears to disable memref normalization
Aug 9 2020
The code looks good, and I like the addition of skipping the analysis for "extern" functions. Because dialect ops can in some ways also represent "future" external functions, a natural way of handling "not yet expanded" external functions would to add an interface query that ask if a given op is "external" also. Default would be false, and dialects that needs dome/all of their ops to be external would be able to refine the interface to provide the necessary functionality.
Aug 4 2020
The bug was on my side, I made it more generic. All is good.
Jul 29 2020
Jul 28 2020
This patch does the advertised functionality well, as shown with the little example below:
sorry, requested a revision by mistake. Repost as a comment below
Jul 3 2020
Generalized the test, can be easily modified to test other dimensions as needed
Jul 2 2020
Jun 22 2020
code is ready to be dropped, since I don't have commit privilege, can you please assist, thanks.
Jun 19 2020
Addressed latest spelling requests. I do need help to commit changes, did a few sometimes ago, not sure how to do it now.
now all comments are done.
latest comments addressed
Added the requested lit tests
Jun 18 2020
I added the { and } around the if statement specifically to avoid name conflicts. I don't like assignment in if-conditional, but since it's both legal and machine generated code (not intended for human consumption), I think it's ok.
Feb 18 2020
What do you suggest I do? Would you like me to introduce the get and set, and leave the older methods for deprecation? Or only add the setter with "set" in the name?
Feb 14 2020
Feb 11 2020
Feb 10 2020
tx for the valuable input
added tests of setters, removed unneeded code, edited & migrated comments as requested
Feb 7 2020
updated style
Feb 6 2020
Dec 23 2019
Jul 31 2019
LGTM
Jul 29 2019
Jun 14 2019
Jun 12 2019
LGTM
Jun 11 2019
LGTM
Jun 10 2019
Apr 16 2019
fantastic
response to Alexey's comment
LGTM, just made one minor suggestion
Apr 12 2019
see note above; apologies if it is already done and hiding somewhere I did not see
Apr 8 2019
See suggested changes, should be pretty straightforward to do, let me know if you need help
Apr 3 2019
see comments
Sep 4 2018
make sense, thanks
Aug 27 2018
Yes, we should have done this right away. I did a rewrite of the functionality that uses header files already included; it was posted in D50522 and the changes were approved and pushed to svn.
- Merge branch 'unpatched-master' into unpatched-master-target-offload-envvar
- while (0) edit
Aug 26 2018
- added do while(1) for macros
Aug 24 2018
- put fatal message for default tgt test