[flang] add tbaa tags to global and direct values

[tblah]

The commit to be reviewed here is ba1bbbe (and any fixups). The others are from previous "stacked PRs", the previous one is #68595

These turn out to be useful for spec2017/fotonik3d and are safe so long as
they are not used along side TBAA tags for local allocations. LLVM may
be able to figure out local allocations by itself anyway.

[Renaud-K]

We also wanted to use SourceKind::Direct with Allocmem and Alloca in which case global would be undefined.
Maybe we can define the union instead in the TypeSwitch and get rid of this condition.

I am assuming that in tbaa gen, we will be distinguishing based on the SourceKind.
A global SymbolRefAttr with a SourceKind::Global means that we are directly accessing global memory and we know this cannot physically alias with heap and stack.
But a global SymbolRefAttr with a SourceKind::Direct means we do not know much other than the target and pointer attributes.

[tblah]

So SourceKind::Direct isn't necessarily a global?

The use case for the tbaa alias analysis is we want to be able to add tags to global arrays. These can be boxed. The specific case I care about is

module mod
real, dimension(:), allocatable :: glbl

subroutine func(arg)
  real, intent(in), dimension(:) :: arg
  ! glbl can't alias with arg
end subroutine
end module

The generated code looks something like

fir.global @_QMmodEglbl : !fir.box<!fir.heap<!fir.array<?xf32>>> { [...]}

func.func @_QMmodPfunc([...]) {
  [...]
  %glbl_addr = fir.address_of(@_QmodEa) : !fir.ref<!fir.box<!fir.heap<!fir.array<?xf32>>>>
  %decl = fir.declare %glbl_addr [...]
  [...]
  %box = fir.load %decl
  %addr = fir.box_addr %box : (!fir.box<!fir.heap<!fir.array<?xf32>>>) -> !fir.heap<!fir.array<?xf32>>
  [...]
  %element = fir.array_coor %addr(%shape) %index
  %val = fir.array_coor %element

What I want to happen here is to notice that %val comes from a global variable and to tag that load as such. This is a lot clearer from the fortran source than the FIR so maybe we need to store more information somewhere.

As I understand it, you're saying that we can't know much about this variable because the global variable is boxed. Why is the box special?

[kiranchandramohan]

That could be because glbl can be passed as one of the arguments to the subroutine func and hence alias.

[kiranchandramohan]

I am possibly wrong here. Settings of other compilers seem to suggest that globals and dummies do not alias.

from the oracle docs:
-xalias=no%dummy: The Fortran standard is followed and dummy arguments do not alias each other or global variables in the actual call. (This is the default.)

-fargument-noalias-global is the default for gfortran.
https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Aliasing-Assumed-To-Work.html (old page)

[Renaud-K]

No, they would not alias unless they have target/pointer attributes. I will be looking into the example and spend more time on this today.

[tblah]

Thank you for your help!

[Renaud-K]

Would it help, if I just said that %val does not come from a global variable. It comes from the heap because glbl is an allocatable. The box is global, but the data it wraps is not.

In the example below glbl is a global

real, dimension(1000) :: glbl
contains
subroutine func(arg)
  real, intent(in), dimension(:) :: arg
  call escape(glbl)
end subroutine
end module

In this case the SourceKind is global and we can infer that it cannot alias with anything else because of where it is physically located. But if you prefer to stick to Fortran rules, you can say that it is an F77 construct (since it does not have any target attribute) and therefore does not alias with anything. It would be non-conformant to pass it as an argument.

fir.global @_QMmodEglbl : !fir.array<1000xf32> {
  %0 = fir.zero_bits !fir.array<1000xf32>
  fir.has_value %0 : !fir.array<1000xf32>
}
func.func @_QMmodPfunc(%arg0: !fir.box<!fir.array<?xf32>> {fir.bindc_name = "arg"}) {
  %c1000 = arith.constant 1000 : index
  %0 = fir.address_of(@_QMmodEglbl) : !fir.ref<!fir.array<1000xf32>>
  %1 = fir.shape %c1000 : (index) -> !fir.shape<1>
  %2 = fir.declare %0(%1) {uniq_name = "_QMmodEglbl"} : (!fir.ref<!fir.array<1000xf32>>, !fir.shape<1>) -> !fir.ref<!fir.array<1000xf32>>
  %3 = fir.declare %arg0 {fortran_attrs = #fir.var_attrs<intent_in>, uniq_name = "_QMmodFfuncEarg"} : (!fir.box<!fir.array<?xf32>>) -> !fir.box<!fir.array<?xf32>>
  fir.call @_QPescape(%2) fastmath<contract> : (!fir.ref<!fir.array<1000xf32>>) -> ()
  return
}

In the case of the Direct SourceKind, the outcome w.r.t. arg is the same but the rule is different. We have a direct memory access because, despite the box load and indirect fir.box_addr operations, we could establish that %val is indexing into glbl. There is no target or pointer attribute on arg so we say that it cannot alias with it.

A couple of observations here is:

1. Direct SourceKind by itself is not sufficient to determine aliasing, the attributes need to be looked at as well.
2. Unlike the global case, the rule for direct is not reflective. Aliasing is established w.r.t. another value.

Hopefully, this clarifies things. But if none of that helps I am now wondering if we cannot alter the rule to make it reflective. Instead of

lhsSrc.kind == SourceKind::Direct && !rhsSrc.isTargetOrPointer()

could we have

lhsSrc.kind == SourceKind::Direct && !lhsSrc.isTargetOrPointer()

I will play with it today.

[tblah]

So, if I understand correctly, it is safe for me to proceed treating these Direct source kinds as globals (I already handle pointer/target elsewhere)?

The information I am encoding in TBAA is roughly "if it is a pointer, target, or if I don't know what it is then assume it could alias with any other data access". I think this covers both the reflective and non-reflective cases:

1. rhsSrc.isTargetOrPointer() -> rhs may alias with any data access and so it would alias with lhsSrc no matter what lhsSrc is
2. lhsSrc.isTargetOrPointer() -> lhs will alias with rhs, no matter what rhs is.

This is less precise than fir::AliasAnalysis::alias but it shouldn't produce incorrect results.

Thanks again for your help on this

[Renaud-K]

I am still struggling a bit with heap data being marked global.

What would make sense for me is:

A direct with no pointer/target would have its own TBAA node.
A global with no target would have its own TBBA node.
Anything else would point to the "Any Data Access" node?

[tblah]

Yeah that sounds good to me. I will update this patch to do that tomorrow. I only added it to the global tree because currently it only seemed to be used to represent global variables and I didn't think much about the heap data.

[tblah]

@Renaud-K ping

[tblah]

Merged manually in 6242c8c