Addressing CR and adding documentation

CR fix

Fix bug

rebase

rebase

edit commit message

Update:
I pushed the fix and thanked you :)

commit message

Update commit message

There was a bug in a test in flang but it was fixed so you can push/rebase

it's my fault.. https://reviews.llvm.org/D145952
I just uploaded a fix because I didn't see yours:
https://reviews.llvm.org/D146213

Rebase after the bug in flang fixed

clang format

ping @dfki-jugr @pifon2a @herhut @nicolasvasilache

Add custom attribute to the lit test

Your example will work for me, I'll just have to add a pass where I insert this alloc_tensor.
Actually I expected this to happen naturally in insertTensorCopies stage.

Then you can bufferize with One-Shot Bufferize first, excluding all FuncOps of which you know that they cannot be bufferized. Then run the bufferization with copyBeforeWrite = true on all excluded FuncOps.

Addressing code review

Thanks @springerm
I tried it, added this patch: https://reviews.llvm.org/D142631

edit title

In D142195#4073141, @springerm wrote:

Is it possible to give them a tensor signature? Then you could bufferize the entire thing with One-Shot Bufferize.

@springerm - my case is a bit different/special. I have an IR with functions that have memref based signature.
Some of them have implementation - and it is a tensor based implementation, meaning I have to_tensor/to_memrefs on args/results.
I had to inline some of them to one function that will be pure tensor based function. On this function I run OneShotBufferize.
After inlining I had the intermediate to_tensor(to_memref), and I expected them to fold.
That's how I got to all the wondering about the folding.
I understand now that the general case is much more complicated than my case.
So I decided to manually move the to_tensor right after their to_memref - because in my case I know it is not changing the meaning of the IR.

lit test change

Change operation in lit test.

Do you suggest adding this attribute to the func dialect? Or do you suggest discussing the whole idea of not always returning true?

I had a scenario where I wanted the callOp not to be inlined.
This is how I solved it, based on your change in Test dialect: https://reviews.llvm.org/D90359
Do you think I should implement it differently?

Since this is my first commit, I can't commit it by myself.
Can you please commit it for me? (https://llvm.org/docs/Phabricator.html#committing-someone-s-change-from-phabricator)
Thanks!

The input in your test case has mixed tensor/memref ops. How did you get to that state? Can you use -one-shot-bufferize="bufferize-function-boundaries" on the initial IR when everything is tensors?

Hi!
I suspect this assertion is too strict.
I have here a piece of code that works without the assertion but fails when the assertion is there: