jeanPerier wrote:

> The other thing we need to consider, which I don't really know enough about 
> at the moment, is how this will interact with other dialects as we start 
> partial lowering. I think Flang has its own TBAA infrastructure, but I don't 
> know anything about it. It seems like there should be some 
> dialect-independent mechanism. Does such a thing exist, or do we need to 
> break that ground. Is Flang doing its own thing just because it was the first 
> language to get there?

@tblah who has been working a lot on Flang TBAA.

Flang only generates the TBAA info before generating LLVM IR dialect in its 
[AddAliasTags 
pass](https://github.com/llvm/llvm-project/blob/main/flang/lib/Optimizer/Transforms/AddAliasTags.cpp).
 FIR optimization passes do not rely on TBAA like metadata during the MLIR 
phase.

Note that the Fortran usage of TBAA is very different from C/C++, the types in 
the TBAA nodes are not related to the user types (integer, real,...) but to the 
variables categories that allows proving object do not alias in Fortran 
(Pointer, dummy arguments, ....).

At the MLIR level, flang implements and uses [mlir AliasAnalysis 
interface](https://github.com/llvm/llvm-project/blob/eb48a61cc17ef6e626a4c4e7c866738225d9870a/mlir/include/mlir/Analysis/AliasAnalysis.h#L232C7-L232C21)
  in [flang/Optimizer/Analysis)
/AliasAnalysis.h](https://github.com/llvm/llvm-project/tree/19c498fdef9d18ced713af4fe0bc4cf834b603b3/flang/include/flang/Optimizer/Analysis)
/AliasAnalysis.h

The AliasAnalysis interface works for generic passes that needs to reason about 
aliasing of two SSA addresses from a same dialect, but there is likely some 
work to get something more generic working when starting with a CIR and FIR 
addresses for instance, or a FIR and a memref address. Slava [made an 
attempt](https://github.com/llvm/llvm-project/pull/164020) to add a generic 
`ViewLikeOpInterface` that would allow the dialect specific alias analysis 
implementation to try to map back an input address that does not belong to the 
dialect to a cast/view from a value from the dialect (walking back the defining 
operations), but there are still some points to clarify.

Now, I also agree that there is likely a need for some metadata or operation to 
express aliasing in a dialect independent way so that partial lowering is 
easier. Currently, if you translate some part of FIR early to another dialect, 
say memref, you would not get (Fortran) TBAA generated for that part because 
the TBAA generation happens later (and the LLVM dialect TBAA attributes are 
only meaningful to add on LLVM IR and FIR dialect ops anyway).

As far as Fortran is concerned, I am not sure TBAA concept is the best fit, it 
is used because it is the most efficient way to get some of the Fortran 
aliasing into LLVM, but [the full restrict 
concept](https://groups.google.com/g/llvm-dev/c/2ZJiHKWuDJo/m/mPBCBZO0BQAJ) was 
probably a better fit. I am not sure if the effort is still ongoing in LLVM for 
this.
So I think that if some generic aliasing info is added to MLIR, it should be 
more generic than TBAA (but should still allow generating TBAA for LLVM IR).

https://github.com/llvm/llvm-project/pull/169226
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to