[flang][RFC] Do not rely on attributes to tag HLFIR variable uses

[jeanPerier]

Summary

After more considerations and experience, switch to one of the
alternative plan for HLFIR variable that will avoid requiring naming
designators and having to maintain and update names in attributes after
inlining of code duplication.

The cost is the increase of fir.box usage, which in most cases should
be removed when lowering from HLFIR to FIR.

[PeteSteinfeld]

flang/docs/HighLevelFIR.md

91

Should read "are retrievable".

92

Should read "are not".

97

Shoud read "This will give".

108–113

This all sounds complicated. Having two kinds of variable, sometimes including attributes and sometimes not. I'm not sure what the advantage of this is or if there's a simpler way to accomplish what you're trying to do.

124

Should read "is generated".

294

Should read "would become"

1346–1348

I couldn't quite parse this sentence. Did you mean to say Instead of introducing an hlfir.declare operation, which would restrict the memory types for an HLFIR variable, it was considered to force ...?

1349–1350

Reword to Using such an attribute would prevent MLIR from merging to operations using a different variable in a new block...?

1352

I would say The advantage of forcing the defining operation to be retrievable is that ...

1354

Should read "avoids requiring the introduction of fir.box ..."

1355–1356

Do you mean that there will be many more HLFIR variables than Fortran variables? If so, perhaps reword as The big drawback is that this implies naming all HLFIR variables, and there are many more of them than there are Fortran named variables.

1360

Should read "operations"

1361

Should read "operations".

1373

Should read "annoying since fir.designator also produces"

1379

Should read "dominate their uses, it seems better to use ..."

1380

Should read "and mixture with"

[jeanPerier]

Fix typos caught by Pete and remove paragaph about the "split"
of variables into two categories, that is more an implementation
detail about how one can view things and it's too much detail for
this document.

[jeanPerier]

Thanks @PeteSteinfeld for the detailed review !

flang/docs/HighLevelFIR.md

108–113

Yes, I removed this paragraph. It is too much details not really needed here. What I was saying is that when you look at an HLFIR variables, you will either be able to know about its Fortran attributes, or you will not. In lowering (when first generating the HLFIR from the parse tree) we will always be able to know about attributes, because no optimization passes may have "hidden" the source yet, so it is OK to rely on having access to it at that stage. Then, in HLFIR to HLFIR passes, we may no longer have access to it and we should not rely on having access to it for correctness purposes.

1346–1348

Changed to Instead of restricting .... the hlfir.declare op is not very important here.

[peixin]

One thing I am not clear is that when do you plan to use fir.declare given hlfir.declare is used. Why is the debug info not added to hlfir.declare directly?

flang/docs/HighLevelFIR.md

97

297

[jeanPerier]

One thing I am not clear is that when do you plan to use fir.declare given hlfir.declare is used. Why is the debug info not added to hlfir.declare directly?

Lowering from the parse tree will only generate hlfir.declare, then in the HLFIR to FIR conversion pass that gets rid of HLFIR operations, hlfir.declare will be translated to fir.declare that is slightly simpler.

hlfir.declare conveys the information that will allow generate variable debug info, and this role is then transmitted to fir.declare until LLVM IR dialect is generated and DIE debug info is actually generated (as I envision it, there is no detailed plan for debug info yet).

[jeanPerier]

Fix more typos.

[clementval]

LGTM

[kiranchandramohan]

While for the near term, hlfir.declare will simplify the OpenMP privatisation clause handling but when we bring in the privatisation clauses to the OpenMP dialect, the dialect will have to live with multiple variable types (hlfir.declare, fir.declare, fir.alloca, llvm.alloca etc).

flang/docs/HighLevelFIR.md

96

Nit: passe -> passes/pass.

123

Will these two co-exist? Or will fir.declare be generated from hlfir.declare ?

134

fir.declare or hlfir.declare?

1346

Something is missing in this sentence.

[kiranchandramohan]

Thanks for describing the changes in detail and for putting them up for review before the code changes. I have a few questions. None of them are blocking, so feel free to push forward if necessary.

It will be good if you can mention in the summary that this patch introduces hlfir.declare operation. It will be great if we can have a table/summary describing what information is present in hlfir.declare vs fir.declare.

flang/docs/HighLevelFIR.md

76

Is this not allowed for an hlfir variable or for fir variables too?

95

Would this information be available in fir.declare as well? Or should any pass requiring such information operate at the hlfir level?

292–298

Is it not possible to create %var#1 from %var#0?

[peixin]

In D137634#3918852, @jeanPerier wrote:

One thing I am not clear is that when do you plan to use fir.declare given hlfir.declare is used. Why is the debug info not added to hlfir.declare directly?

Lowering from the parse tree will only generate hlfir.declare, then in the HLFIR to FIR conversion pass that gets rid of HLFIR operations, hlfir.declare will be translated to fir.declare that is slightly simpler.

hlfir.declare conveys the information that will allow generate variable debug info, and this role is then transmitted to fir.declare until LLVM IR dialect is generated and DIE debug info is actually generated (as I envision it, there is no detailed plan for debug info yet).

Got it. Thanks a lot.

[jeanPerier]

Thanks for the rewiew

In D137634#3918988, @kiranchandramohan wrote:

While for the near term, hlfir.declare will simplify the OpenMP privatisation clause handling but when we bring in the privatisation clauses to the OpenMP dialect, the dialect will have to live with multiple variable types (hlfir.declare, fir.declare, fir.alloca, llvm.alloca etc).

They are three things that could maybe help here:

1. hlfir.declare and fir.declare share a common FortranVariableOpInterface that could be relied on
2. hlfir.declare and fir.declare will probably not co-exists (so depending on when privatization occur, only one or the other would matter)
3. the declare ops are not really doing anything with memory, they are just tagging it, and binding info to it, so maybe it is OK to only care about the alloc ops as far as privatization is concerned.

flang/docs/HighLevelFIR.md

123

It is possible for the two to coexist, but the plan is for fir.declare to be generated from hlfir.declare while converting HLFIR to FIR.

134

hlfir.declare, thanks

1346

Repharsed to "Instead of restricting the memory types an HLFIR variable can have, it was"

[jeanPerier]

Fix two typos and add missing word.

flang/docs/HighLevelFIR.md

 memory reference).
 
 This makes reasoning about Fortran variables in FIR harder, and in general
 forces lowering to apply all decisions related to the information that is lost
 in FIR. A more problematic point is that it does not allow generating debug
 information for the variables from FIR, since the bounds and type parameters
 information is not tightly linked to the base mlir::Value.
 
-The proposal is to add a fir.declare operation that would anchor the
-fir::ExtendedValue information in the IR regardless of the mlir::Value used for
-the variable (bare memory reference, or fir.box). This operation will have a
-"fir.def = uniq_mangled_variable_name" that will allow linking it to the Fortran
-source variable, and will take all the bounds and type parameters as operands.
-All the high-level operations referring to variables will have a "fir.ref =
-uniq_mangled_variable_name" that will allow retrieving back the related
-dominating fir.declare and all the variable information. In most of the cases,
-the fir.declare should simply be the defining operation of the operand mlir
-value.
+The proposal is to add a hlfir.declare operation that would anchor the
+fir::ExtendedValue information in the IR. A variable will be represented by a
+single SSA value with a memory type (fir.ref<T>, fir.ptr<T>, fir.heap<T>,
+fir.box<T>, fir.boxchar or fir.ref<fir.box<T>>). Not all memory types will be
+allowed for a variable: it should allow retrieving all the shape, type
+parameters, and dynamic type information without requiring to look-up for any
+defining operations. For instance, `fir.ref<fir.array<?xf32>>` will not be
+allowed as an HLFIR variable, and fir.box<fir.array<?xf32>> will be used
+instead. However, `fir.ref<fir.array<100xf32>>` will be allowed to represent an
+array whose lower bounds are all ones (if the lower bounds are different than
+one, a fir.box will still be needed).  The hlfir.declare operation will be
+responsible for producing the SSA value with the right memory type given the
+variable specifications. One notable point is that, except for the POINTER and
+ALLOCATABLE attributes that are retrievable from the SSA value type, other
+Fortran attributes (OPTIONAL, TARGET, VOLATILE...) will not be retrievable from
+the SSA value alone, and it will be required to access the defining
+hlfir.declare to get the full picture.
+
+This creates a split of the HFLIR variables in two categories: the ones for
+which the defining operation is retrievable, that will be called
+`FortranVariable`, and the ones for which the defining operation is not
+retrievable, that will be called `FortranLikeVariable`. Lowering to HLFIR,
+because it is producing the IR, will propagate and operate on
+`FortranVariable`, which will give it the full picture. The following
+transformation passes will be required to be able to operate on
+`FortranLikeVariable`. This will gives more freedom for optimizations to clone,
+move and merge the code without creating situations where HLFIR code generation
+to FIR could not be performed. This means that semantically relevant attributes
+will need to be set by lowering on operation using variables when that is
+relevant (for instance when using an OPTIONAL variable in an intrinsic where it
+is allowed to be absent). Then, the optimizations passes will be allowed to
+look for the defining hlfir.declare, but not to assume that it must be visible.
+For instance, simple contiguity of fir.box can be deduced in certain case from
+the hlfir.declare, and if the hlfir.declare cannot be found, the transformation
+passe will have to assume that the variable may be non contiguous.
+
+In practice, it is expected that the passes will be able to leverage
+hlfir.declare in most cases, but that guaranteeing that it will always be the
+case would constraint the IR and optimizations too much.  The goal is also to
+remove the fir.box usages when possible while lowering to FIR, to avoid
+needlessly creating runtime descriptors for variables that do not really
+require it.
 
-The fir.declare operation will allow:
+The hlfir.declare operation and restrained memory types will allow:
 - Pushing higher-level Fortran concepts into FIR operations (like array
   assignments or transformational intrinsics).
-- Generating debug information for the variables based on the fir.declare
+- Generating debug information for the variables based on the hlfir.declare
   operation.
 - Generic Fortran aliasing analysis (currently implemented only around array
   assignments with the fir.array_load concept).
 
+The hlfir.declare will have a sibling fir.declare operation in FIR that will
+allow keeping variable information until debug info are generated. The main
+difference is that the fir.declare will simply return its first operand,
+making its codegen a no-op, while hlfir.declare might change the type of
+its first operand to return an HLFIR variable compatible type.
 The fir.declare op is the only operation described by this change that will be
-added to FIR and not HLFIR. The rational for this is that it is intended to
-survive until LLVM dialect codegeneration so that debug info generation can use
-them and alias information can take advantage of them even on FIR. 
+added to FIR. The rational for this is that it is intended to survive until
+LLVM dialect codegeneration so that debug info generation can use them and
+alias information can take advantage of them even on FIR. 
 
 Note that Fortran variables are not necessarily named objects, they can also be
-the result of function references returning POINTERs. fir.declare will also
+the result of function references returning POINTERs. hfir.declare will also
 accept such variables to be described in the IR (a unique name will be built
 from the caller scope name and the function name.). In general, fir.declare
 will allow to view every memory storage as a variable, and this will be used to
 describe and use compiler created array temporaries.
 
 ## Adding an expression value concept in HLFIR
 
 Currently, Fortran expressions can be represented as SSA values for scalar

 after the last use of the hlfir.expr. Note that, at least at first, lowering
 may help FIR to find the last use of a hlfir.expr by explicitly inserting a
 hlfir.finalize %expr operation that may turn into a no-op if the expression is
 not later materialized in memory.
 
 It is nonetheless not intended that such abstract types be used as block
 arguments to avoid introducing allocations and descriptor manipulations.
 
-#### fir.declare operation
+#### hlfir.declare operation
 
 Motivation: represent variables, linking together a memory storage, shape,
 length parameters, attributes and the variable name.
 
 Syntax:
 ```
-%var = fir.declare %base [shape %extent1, %extent2, ...] [lbs %lb1, %lb2, ...] [typeparams %l1, ...] {fir.def = mangled_variable_name, attributes} : [(....) ->] T
+%var = hlfir.declare %base [shape %extent1, %extent2, ...] [lbs %lb1, %lb2, ...] [typeparams %l1, ...] {fir.def = mangled_variable_name, attributes} : [(....) ->] T1, T2
 ```
 
-%var will have the same type as %base. When no debug info is generated, the
-operation can be replaced by %base when lowering to LLVM.
+%var#0 will have a FIR memory type that is allowed for HLFIR variables. %var#1
+will have the same type as %base, it is intended to be used when lowering HLFIR
+to FIR in order to avoid creating unnecessary fir.box (that would became
+runtime descriptors). When an HLFIR operation has access to the defining
+hlfir.declare of its variable operands, the operation codegen will be allowed
+to replaced the %var#0 reference by the simpler %var#1 reference.
 
 - Extents should only be provided if %base is not a fir.box and the entity is an
   array.
 - lower bounds should only be provided if the entity is an array and the lower
   bounds are not default (all ones). It should also not be provided for POINTERs
   and ALLOCATABLES since the lower bounds may change.
 - type parameters should be provided for entities with length parameters, unless
   the entity is a CHARACTER where the length is constant in %base type.
 - The attributes will include the Fortran attributes: TARGET (fir.target),
   POINTER (fir.ptr), ALLOCATABLE (fir.alloc), CONTIGUOUS (fir.contiguous),
   OPTIONAL (fir.optional), VOLATILE (fir.volatile), ASYNCHRONOUS (fir.async).
   They will also indicate when an entity is part of an equivalence by giving the
   equivalence name (fir.equiv = mangled_equivalence_name).
 
-fir.declare will be used for all Fortran variables, except the ones created via
+hlfir.declare will be used for all Fortran variables, except the ones created via
 the ASSOCIATE construct that will use hlfir.associate described below.
 
-fir.declare will also be used when creating compiler created temporaries, in
+hlfir.declare will also be used when creating compiler created temporaries, in
 which case the fir.tmp attribute will be given.
 
 Examples:
 
-| FORTRAN                                 | FIR                                                                                                     |
-| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| REAL :: X                                 | %mem = fir.alloca f32 <br> %x = fir.declare %mem {fir.def = "\_QPfooEx"} : fir.ref<f32>                                                                                                     |
-| REAL, TARGET :: X(10)                     | %mem = fir.alloca f32 <br> %nval = fir.load %n <br> %x = fir.declare %mem {fir.def = "\_QPfooEx", fir.target} : fir.ref<fir.array<10xf32>>                                                  |
-| REAL :: X(N)                              | %mem = // … alloc or dummy argument <br> %nval = fir.load %n : i64 <br> %x = fir.declare %mem shape %nval {fir.def = "\_QPfooEx"} : (i64) -> fir.ref<fir.array<?xf32>>                      |
-| REAL :: X(0:)                             | %mem = // … dummy argument <br> %c0 = arith.constant 0 : index <br> %x = fir.declare %mem lbs %c0 {fir.def = "\_QPfooEx"} : (index) -> fir.box<fir.array<?xf32>>                            |
-| <br>REAL, POINTER :: X(:)                 | %mem = // … dummy argument, or local, or global <br> %x = fir.declare %mem {fir.def = "\_QPfooEx", fir.ptr} :  fir.ref<fir.box<fir.ptr<fir.array<?xf32>>>>                                  |
-| REAL, ALLOCATABLE :: X(:)                 | %mem = // … dummy argument, or local, or global <br> %x = fir.declare %mem {fir.def = "\_QPfooEx", fir.alloc} :  fir.ref<fir.box<fir.heap<fir.array<?xf32>>>>                               |
-| CHARACTER(10) :: C                        | %mem = //  … dummy argument, or local, or global <br> %c = fir.declare %mem lbs %c0 {fir.def = "\_QPfooEc"} :  fir.ref<fir.char<10>>                                                        |
-| CHARACTER(\*) :: C                        | %unbox = fir.unbox %bochar (fir.boxchar<1>) -> (fir.ref<fir.char<?>>, index) <br> %c = fir.declare %unbox#0 typeparams %unbox#1 {fir.def = "\_QPfooEc"} : (index) ->  fir.ref<fir.char<?>>  |
-| CHARACTER(\*), OPTIONAL, ALLOCATABLE :: C | %mem = // … dummy argument <br> %c = fir.declare %mem {fir.def = "\_QPfooEc", fir.alloc, fir.optional, fir.assumed\_len\_alloc} :  fir.ref<fir.box<fir.heap<fir.char<?>>>>                  |
-| TYPE(T) :: X                              | %mem = //  … dummy argument, or local, or global <br> %x = fir.declare %mem {fir.def = "\_QPfooEx"} : fir.ref<fir.type<t{...}>>                                                             |
-| TYPE(T(L)) :: X                           | %mem = //  … dummy argument, or local, or global <br> %lval = fir.load %l <br> %x = fir.declare %mem typeparams %lval {fir.def = "\_QPfooEx"} : fir.box<fir.type<t{...}>>                   |
-| CLASS(\*), POINTER :: X                   | %mem = //  … dummy argument, or local, or global <br> %x = fir.declare %mem {fir.def = "\_QPfooEx", fir.ptr} : fir.class<fir.ptr<None>>                                                     |
-| REAL :: X(..)                             | %mem = //  … dummy argument <br> %x = fir.declare %mem {fir.def = "\_QPfooEx"} : fir.box<fir.array<..xf32>>                                                                                 |
+| FORTRAN                                   | HLFIR                                                                                                                                                                                                                    |
+| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| REAL :: X                                 | %mem = fir.alloca f32 <br> %x = hlfir.declare %mem {fir.def = "\_QPfooEx"} : fir.ref<f32>, fir.ref<f32>                                                                                                                  |
+| REAL, TARGET :: X(10)                     | %mem = fir.alloca f32 <br> %nval = fir.load %n <br> %x = hlfir.declare %mem {fir.def = "\_QPfooEx", fir.target} : fir.ref<fir.array<10xf32>>, fir.ref<fir.array<10xf32>>                                                 |
+| REAL :: X(N)                              | %mem = // … alloc or dummy argument <br> %nval = fir.load %n : i64 <br> %x = hlfir.declare %mem shape %nval {fir.def = "\_QPfooEx"} : (i64) -> fir.box<fir.array<?xf32>>, fir.ref<fir.array<?xf32>>                      |
+| REAL :: X(0:)                             | %mem = // … dummy argument <br> %c0 = arith.constant 0 : index <br> %x = hlfir.declare %mem lbs %c0 {fir.def = "\_QPfooEx"} : (index) -> fir.box<fir.array<?xf32>>, fir.box<fir.array<?xf32>>                            |
+| <br>REAL, POINTER :: X(:)                 | %mem = // … dummy argument, or local, or global <br> %x = hlfir.declare %mem {fir.def = "\_QPfooEx", fir.ptr} :  fir.ref<fir.box<fir.ptr<fir.array<?xf32>>>>, fir.ref<fir.box<fir.ptr<fir.array<?xf32>>>>                |
+| REAL, ALLOCATABLE :: X(:)                 | %mem = // … dummy argument, or local, or global <br> %x = hlfir.declare %mem {fir.def = "\_QPfooEx", fir.alloc} :  fir.ref<fir.box<fir.heap<fir.array<?xf32>>>>, fir.ref<fir.box<fir.heap<fir.array<?xf32>>>>            |
+| CHARACTER(10) :: C                        | %mem = //  … dummy argument, or local, or global <br> %c = hlfir.declare %mem lbs %c0 {fir.def = "\_QPfooEc"} :  fir.ref<fir.char<10>>, fir.ref<fir.char<10>>                                                            |
+| CHARACTER(\*) :: C                        | %unbox = fir.unbox %bochar (fir.boxchar<1>) -> (fir.ref<fir.char<?>>, index) <br> %c = hlfir.declare %unbox#0 typeparams %unbox#1 {fir.def = "\_QPfooEc"} : (index) ->  fir.boxchar<1>, fir.ref<fir.char<?>>             |
+| CHARACTER(\*), OPTIONAL, ALLOCATABLE :: C | %mem = // … dummy argument <br> %c = hlfir.declare %mem {fir.def = "\_QPfooEc", fir.alloc, fir.optional, fir.assumed\_len\_alloc} :  fir.ref<fir.box<fir.heap<fir.char<?>>>>, fir.ref<fir.box<fir.heap<fir.char<?>>>>    |
+| TYPE(T) :: X                              | %mem = //  … dummy argument, or local, or global <br> %x = hlfir.declare %mem {fir.def = "\_QPfooEx"} : fir.ref<fir.type<t{...}>>, fir.ref<fir.type<t{...}>>                                                             |
+| TYPE(T(L)) :: X                           | %mem = //  … dummy argument, or local, or global <br> %lval = fir.load %l <br> %x = hlfir.declare %mem typeparams %lval {fir.def = "\_QPfooEx"} : fir.box<fir.type<t{...}>>, fir.box<fir.type<t{...}>>                   |
+| CLASS(\*), POINTER :: X                   | %mem = //  … dummy argument, or local, or global <br> %x = hlfir.declare %mem {fir.def = "\_QPfooEx", fir.ptr} : fir.class<fir.ptr<None>>  fir.class<fir.ptr<None>>                                                      |
+| REAL :: X(..)                             | %mem = //  … dummy argument <br> %x = hlfir.declare %mem {fir.def = "\_QPfooEx"} : fir.box<fir.array<..xf32>>, fir.box<fir.array<..xf32>>                                                                                |
+
+#### fir.declare operation
+
+Motivation: keep variable information available in FIR, at least with
+the intent to be able to produce debug information.
+
+Syntax:
+```
+%var = fir.declare %base [shape %extent1, %extent2, ...] [lbs %lb1, %lb2, ...] [typeparams %l1, ...] {fir.def = mangled_variable_name, attributes} : [(....) ->] T
+```
+
+%var will have the same type as %base. When no debug info is generated, the
+operation can be replaced by %base when lowering to LLVM. Otherwise, the
+operation is similar to hlfir.declare and will be produced from it.
 
 #### hlfir.associate operation
 
 Motivation: represent Fortran associations (both from variables and expressions)
 and allow keeping actual/dummy argument association information after inlining.
 
 Syntax:
 ```
 %var = hlfir.associate %expr_or_var {fir.def = mangled_uniq_name, attributes} (AnyExprOrVarType) -> AnyVarType
 ```
 
 hlfir.associate is used to represent the following associations:
 - Dummy/Actual association on the caller side (the callee side uses
-  fir.declare).
+  hlfir.declare).
 - Host association in block constructs when VOLATILE/ASYNC attributes are added
   locally
 - ASSOCIATE construct (both from variable and expressions).
 
 When the operand is a variable, hlfir.associate allows changing the attributes
 of the variable locally, and to encode certain side-effects (like
 copy-in/copy-out when going from a non-contiguous variable to a contiguous
 variable, with the help of the related hlfir.end_association operation).

 
 The hlfir.end_associate is a placeholder to later insert
 deallocation/finalization if the variable was associated with an expression,
 and to insert copy-out/deallocation if the variable was associated with another
 variable with a copy-in.
 
 Syntax:
 ```
-hlfir.end_association %var [%original_variable] {fir.ref = var_mangled_name, attributes}
+hlfir.end_association %var [%original_variable] {attributes}
 ```
 
 
 The attributes can be:
 -   copy_out (copy out the associated variable back into the original variable
     if a copy-in occurred)
 -   finalize_copy_in (deallocate the temporary storage for the associated
     variable if a copy-in occurred but the associated variable was not modified

 
 Motivation: mark end of life of local variables
 
 Mark the place where a local variable will go out of scope. The main goal is to
 retain this information even after local variables are inlined.
 
 Syntax:
 ```
-hlfir.finalize %var {fir.ref = var_mangled_name, attributes}
+hlfir.finalize %var {attributes}
 ```
 
 The attributes can be:
 -   finalize: indicate that a finalizer should be run on the entity associated
     with the variable (There is currently no way to deduce this only from the
     variable type in FIR).
 
 Note that finalization will not free the local variable storage if it was
-allocated on the heap. If lowering created the storage passed to fir.declare via
-a fir.allocmem, lowering should insert a fir.freemem after the hlfir.finalize.
-This could help making fir.allocmem to fir.alloca promotion simpler, and also
-because finalization may be run without the intent to deallocate the variable
-storage (like on INTENT(OUT) dummies).
+allocated on the heap. If lowering created the storage passed to hlfir.declare
+via a fir.allocmem, lowering should insert a fir.freemem after the
+hlfir.finalize.  This could help making fir.allocmem to fir.alloca promotion
+simpler, and also because finalization may be run without the intent to
+deallocate the variable storage (like on INTENT(OUT) dummies).
 
 
 #### hlfir.designate
 
 Motivation: Represent designators at a high-level and allow representing some
 information about derived type components that would otherwise be lost, like
 component lower bounds.
 
 Represent Fortran designators in a verbatim way: both triplet, and component
 parts.
 
 Syntax:
 ```
-%var = hlfir.designate %base [“component”,] [(%i, %k:l%:%m)] [substr ub, lb] [imag|real] [shape extent1, extent2, ....] [lbs lb1, lb2, .....] [typeparams %l1, ...] {fir.ref = base_mangled_name, fir.def = mangled_name, attributes}
+%var = hlfir.designate %base [“component”,] [(%i, %k:l%:%m)] [substr ub, lb] [imag|real] [shape extent1, extent2, ....] [lbs lb1, lb2, .....] [typeparams %l1, ...] {attributes}
 ```
 
 hlfir.designate is intended to encode a single part-ref (as defined by the
 fortran standard). That means that a(:)%x(i, j, k) must be split into two
 hlfir.designate: one for a(:), and one for x(i, j, k).  If the base is ranked,
 and the component is an array, the subscripts are mandatory and must not
 contain triplets. This ensures that the result of a fir.designator cannot be a
 "super-array".

 The choice of using one based indicies is to match Fortran default for
 array variables, so that there is no need to generate bound adjustments
 when working with one based array variables in an expression.
 
 Illustration: “A + B” represented with a hlfir.elemental.
 
 ```
 %add = hlfir.elemental (%i:index, %j:index) shape %shape (!fir.shape<2>) -> !hlfir.expr<?x?xf32> {
-  %belt = hlfir.designate %b, %i, %j {fir.ref = _QPfooEb, fir.def = _QPfooEb.des001}: (!fir.ref<!fir.array<?x?xf32>>, index, index) -> !fir.ref<f32>
-  %celt = hlfir.designate %c, %i, %j {fir.ref = _QPfooEa, fir.def = _QPfooEa.des002} : (!fir.ref<!fir.array<?x?xf32>>, index, index) -> !fir.ref<f32>
+  %belt = hlfir.designate %b, %i, %j : (!fir.box<!fir.array<?x?xf32>>, index, index) -> !fir.ref<f32>
+  %celt = hlfir.designate %c, %i, %j : (!fir.box<!fir.array<?x?xf32>>, index, index) -> !fir.ref<f32>
   %bval = fir.load %belt : (!fir.ref<f32>) -> f32
   %cval = fir.load %celt : (!fir.ref<f32>) -> f32
   %add = arith.addf %bval, %cval : f32
   fir.result %res : f32
 }
 ```
 
 In contexts where it can be proved that the array operands were not modified
-   3. For each assignments, check if the RHS/LHS operands value may depend
     - Yes, split the forall loops. Insert a “forall temps” before the loops for
       the “smallest” part that may overlap (which may be the whole RHS, or some
       RHS sub-part, or some LHS indices). In the first nest, evaluate this
       overlapping part into the temp. In the next forall loop nest, modify the
       assignment to use the temporary, and add the [no_overlap] flag to indicate
       no further temporary is needed. Insert code to finalize the temp after its
       usage.
 
-### Tagging variable uses in high-level operations (fir.ref attribute)
-
-All operations defined above that accept "variables" (i.e: memory addresses or
-box values that were produced by fir.declare, hlfir.associate, or
-hlfir.designate) must have a fir.ref = mangled_name_attribute that matches the
-fir.def on the operation that created them (it will be added automatically by
-the operation builder). That is to ensure optimization passes do not merge
-seemingly identical operations using variables with different properties, and
-also to ensure that the matching defining operation can always be retrieved to
-get all the variable properties (shape, bounds, type parameters and
-attributes).
-
-Two other alternatives have been considered and rejected:
-- Using MLIR symbols. This has been rejected because MLIR symbols are mainly
-  intended to deal with globals and functions that may refer to each other
-  before being defined. Their processing is not as light as normal values, and
-  would require to turn every FIR operation with a region into an MLIR symbol
-  table. This would especially be annoying given fir.designator also produce
-  variables with their own properties, which would imply creating a lot of MLIR
-  symbols. All the operations that both accept variable and expression operands
-  would also either need to be more complex in order to both accept SSA values
-  or MLIR symbol operands (or some fir.as_expr %var operation should be added to
-  turn a variable into an expression). Given all variable definitions will
-  dominates their uses, it seems more adequate to use an SSA model with named
-  attributes. Using SSA values also makes the transition and mix with
-  lower-level FIR operations smoother: a variable SSA usage can simply be
-  replaced by lower-level FIR operations using the same SSA value.
-- Another alternative could be making all operations defining variables return
-  fir.box, and repeating the variable attributes (fir.target...) on all
-  operations using the variable. This would allow the link between the variable
-  definition and usage to become broken (variable could travel as block
-  arguments). But this would risk littering the codegen with fir.box
-  manipulations (creating, writing and reading to descriptors) that may lead to
-  poor performance. Maintaining all the attributes on the operations would also
-  be more cumbersome than only maintaining the variable name in the fir.ref
-  attribute.
-
-Lower-level operations (the current FIR operations), do not require this strong
-link between a memory address and the variable definition, and it will not be
-necessary to add fir.ref attributes to those. During alias analysis on FIR using
-lower-level operations (like loads and stores), any memory reference that cannot
-be resolved to a Fortran variable or some unrelated temporary allocation is
-considered as potentially overlapping.
-
-The variable definition will be guaranteed to have a unique name after lowering,
-and some care might have to be taken when later duplicating regions that define
-variables in a way that could lead a variable usage to have two dominating
-definitions with the same name (this could for instance happen after inlining
-two calls to the same procedure inside the same region). Inlining will need to
-take care of those conflicts. This could be done by randomizing the inlined
-variable name attributes (like by adding a counter index that is incremented
-after each call inlining).
-
 ## New HLFIR Transformation Passes
 
 ### Mandatory Passes (translation towards lower-level representation)
 
 Note that these passes could be implemented as a single MLIR pass, or successive
 passes.
 
 -   Forall rewrites (getting rid of hlfir.forall)
subroutine foo(a, b)
   a = b
 end subroutine
 ```
 
 Lowering output:
 
 ```HLFIR
 func.func @_QPfoo(%arg0: !fir.box<!fir.array<?xf32>>, %arg1: !fir.box<!fir.array<?xf32>>) {
-  %a = fir.declare %arg0 {fir.def = "_QPfooEa"} : !fir.box<!fir.array<?xf32>>
-  %b = fir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>
-  hlfir.assign %b to %a {fir.ref = "_QPfooEb,_QPfooEa"}: !fir.box<!fir.array<?xf32>>
+  %a = hlfir.declare %arg0 {fir.def = "_QPfooEa"} : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
+  %b = hlfir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
+  hlfir.assign %b#0 to %a#0 : !fir.box<!fir.array<?xf32>>
   return
 }
 ```
 
 HLFIR array assignment lowering pass:
 -   Query: can %b value depend on %a? No, they are two different argument
     associated variables that are neither target nor pointers.
 -   Lower to assignment to loop:
 
 ```HFLIR
 func.func @_QPfoo(%arg0: !fir.box<!fir.array<?xf32>>, %arg1: !fir.box<!fir.array<?xf32>>) {
-  %a = fir.declare %arg0 {fir.def = "_QPfooEa"} : !fir.box<!fir.array<?xf32>>
-  %b = fir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>
+  %a = hlfir.declare %arg0 {fir.def = "_QPfooEa"} : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
+  %b = hlfir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
 
-  %ashape = hlfir.shape_of %a {fir.ref = "_QPfooEa"}
-  %bshape = hlfir.shape_of %b {fir.ref = "_QPfooEb"}
+  %ashape = hlfir.shape_of %a#0
+  %bshape = hlfir.shape_of %b#0
   %shape = hlfir.shape_meet %ashape, %bshape
   %extent = hlfir.get_extent %shape, 0
 
   %c1 = arith.constant 1 : index
 
   fir.do_loop %i = %c1 to %extent step %c1 unordered {
-    %belt = hlfir.designate %b, %i {fir.ref = "_QPfooEb", "fir.def=_QPfooEb.des001"}
-    %aelt = hlfir.designate %a, %i {fir.ref = "_QPfooEa", "fir.def=_QPfooEa.des002"}
-    hlfir.assign %belt to %aelt {fir.ref = "_QPfooEb.des001,_QPfooEa.des002"}: fir.ref<f32>, fir.ref<f32>
+    %belt = hlfir.designate %b#0, %i
+    %aelt = hlfir.designate %a#0, %i
+    hlfir.assign %belt to %aelt : fir.ref<f32>, fir.ref<f32>
   }
   return
 }
 ```
 
 HLFIR variable operations to memory translation pass:
 -   hlfir.designate is rewritten into fir.array_coor operation on the variable
     associated memory buffer, and returns the element address
 -   For numerical scalar, hlfir.assign is rewritten to fir.store (and fir.load
     of the operand if needed), for derived type and characters, memory copy
     (and padding for characters) is done.
 -   hlfir.shape_of are lowered to fir.box_dims, here, no constant information
     was obtained from any of the source shape, so hlfir.shape_meet is a no-op,
     selecting the first shape (a conformity runtime check could be inserted
     under debug options).
--   fir.declare are kept (they are no-ops) so that it will be possible to
-    generate debug information for LLVM.
+-   hlfir.declare are translated into fir.declare that are no-ops and will allow
+    generating debug information for LLVM.
 
-This pass would wrap operations defining variables (fir.declare/hlfir.designate)
+This pass would wrap operations defining variables (hlfir.declare/hlfir.designate)
 as fir::ExtendedValue, and use all the current helpers operating on it
 (e.g.: fir::factory::genScalarAssignment).
 
 ```
 func.func @_QPfoo(%arg0: !fir.box<!fir.array<?xf32>>, %arg1:
   !fir.box<!fir.array<?xf32>>) {
   %a = fir.declare %arg0 {fir.def = "_QPfooEa"} : !fir.box<!fir.array<?xf32>>
   %b = fir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>
   %c1 = arith.constant 1 : index
   %dims = fir.box_dims %a, 1
   fir.do_loop %i = %c1 to %dims#1 step %c1 unordered {
     %belt = fir.array_coor %b, %i : (!fir.box<!fir.array<?xf32>>, index) -> fir.ref<f32>
     %aelt = fir.array_coor %a, %i : (!fir.box<!fir.array<?xf32>>, index) -> fir.ref<f32>
     %bval = fir.load %belt : f32
     fir.store %bval to %aelt : fir.ref<f32>
   }
   return
 }
 ```
 
-This reaches the current FIR level (except fir.declare_op that can be kept until
+This reaches the current FIR level (except fir.declare that can be kept until
 LLVM codegen and dropped on the floor if there is no debug information
 generated).
 
 ### Example 2: array assignment with elemental expression
 
 ```Fortran
 subroutine foo(a, b, p, c)
   real, target :: a(:)
   real :: b(:), c(100)
   real, pointer :: p(:)
   a = b*p + c
 end subroutine
 ```
 
 Lowering output:
 
 ```HLFIR
 func.func @_QPfoo(%arg0: !fir.box<!fir.array<?xf32>>, %arg1: !fir.box<!fir.array<?xf32>>, %arg2: !fir.box<!fir.ptr<!fir.array<?xf32>>>, %arg3: !fir.ref<!fir.array<100xf32>>) {
-  %a = fir.declare %arg0 {fir.def = "_QPfooEa"} {fir.target} : !fir.box<!fir.array<?xf32>
-  %b =  fir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>
-  %p = fir.declare %arg2 {fir.def = "_QPfooEp", fir.ptr} : !fir.box<!fir.ptr<!fir.array<?xf32>>>
-  %c =  fir.declare %arg3 {fir.def = "_QPfooEc"} : !fir.ref<!fir.array<100xf32>>
-  %bshape = hlfir.shape_of %b {fir.ref = "_QPfooEb"}
-  %pshape = hlfir.shape_of %p {fir.ref = "_QPfooEp"}
+  %a = hlfir.declare %arg0 {fir.def = "_QPfooEa"} {fir.target} : !fir.box<!fir.array<?xf32>, !fir.box<!fir.array<?xf32>
+  %b =  hlfir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
+  %p = hlfir.declare %arg2 {fir.def = "_QPfooEp", fir.ptr} : !fir.box<!fir.ptr<!fir.array<?xf32>>>, !fir.box<!fir.ptr<!fir.array<?xf32>>>
+  %c =  hlfir.declare %arg3 {fir.def = "_QPfooEc"} : !fir.ref<!fir.array<100xf32>>, !fir.ref<!fir.array<100xf32>>
+  %bshape = hlfir.shape_of %b#0
+  %pshape = hlfir.shape_of %p#0
   %shape1 = hlfir.shape_meet %bshape, %pshape
   %mul = hlfir.elemental(%i:index) %shape1 {
-    %belt = hlfir.designate %b, %i {fir.ref = "_QPfooEb", fir.def= "_QPfooEb.des001"}
-    %p_lb = hlfir.get_lbound %p, 1 {fir.ref = "_QPfooEp"}
+    %belt = hlfir.designate %b#0, %i
+    %p_lb = hlfir.get_lbound %p#0, 1
     %i_zero = arith.subi %i, %c1
     %i_p = arith.addi %i_zero,  %p_lb
-    %pelt = hlfir.designate %p, %i_p {fir.ref = "_QPfooEp", fir.def= "_QPfooEp.des002"}
+    %pelt = hlfir.designate %p#0, %i_p
     %bval = fir.load %belt : f32
     %pval = fir.load %pelt : f32
     %mulres = arith.mulf %bval, %pval : f32
      fir.result %mulres : f32
   }
   %cshape = hlfir.shape_of %c
   %shape2 = hlfir.shape_meet %cshape, %shape1
   %add =  hlfir.elemental(%i:index) %shape2 {
     %mulval = hlfir.apply %mul, %i : f32
-    %celt = hlfir.designate %c, %i {fir.ref = "_QPfooEc", fir.def= "_QPfooEc.des003"}
+    %celt = hlfir.designate %c#0, %i
     %cval = fir.load %celt
     %add_res = arith.addf %mulval, %cval
     fir.result %add_res
   }
-  hlfir.assign %add to %a {fir.ref = "_QPfooEa"} : hlfir.expr<?xf32>, !fir.box<!fir.array<?xf32>
+  hlfir.assign %add to %a#0 : hlfir.expr<?xf32>, !fir.box<!fir.array<?xf32>
   return
 }
 ```
 
 Step 1: hlfir.elemental inlining: inline the first hlfir.elemental into the
 second one at the hlfir.apply.
 
 
 ```HLFIR
 func.func @_QPfoo(%arg0: !fir.box<!fir.array<?xf32>>, %arg1: !fir.box<!fir.array<?xf32>>, %arg2: !fir.box<!fir.ptr<!fir.array<?xf32>>>, %arg3: !fir.ref<!fir.array<100xf32>>) {
-  %a = fir.declare %arg0 {fir.def = "_QPfooEa"} {fir.target} : !fir.box<!fir.array<?xf32>
-  %b =  fir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>
-  %p = fir.declare %arg2 {fir.def = "_QPfooEa", fir.ptr} : !fir.box<!fir.ptr<!fir.array<?xf32>>>
-  %c =  fir.declare %arg3 {fir.def = "_QPfooEp"} : !fir.ref<!fir.array<100xf32>>
-  %bshape = hlfir.shape_of %b {fir.ref = "_QPfooEb"}
-  %pshape = hlfir.shape_of %p {fir.ref = "_QPfooEp"}
+  %a = hlfir.declare %arg0 {fir.def = "_QPfooEa"} {fir.target} : !fir.box<!fir.array<?xf32>, !fir.box<!fir.array<?xf32>
+  %b =  hlfir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
+  %p = hlfir.declare %arg2 {fir.def = "_QPfooEp", fir.ptr} : !fir.box<!fir.ptr<!fir.array<?xf32>>>, !fir.box<!fir.ptr<!fir.array<?xf32>>>
+  %c =  hlfir.declare %arg3 {fir.def = "_QPfooEc"} : !fir.ref<!fir.array<100xf32>>, !fir.ref<!fir.array<100xf32>>
+  %bshape = hlfir.shape_of %b#0
+  %pshape = hlfir.shape_of %p#0
   %shape1 = hlfir.shape_meet %bshape, %pshape
   %cshape = hlfir.shape_of %c
   %shape2 = hlfir.shape_meet %cshape, %shape1
   %add =  hlfir.elemental(%i:index) %shape2 {
-    %belt = hlfir.designate %b, %i {fir.ref = "_QPfooEb", fir.def= "_QPfooEb.des001"}
-    %p_lb = hlfir.get_lbound %p, 1 {fir.ref = "_QPfooEp"}
+    %belt = hlfir.designate %b#0, %i
+    %p_lb = hlfir.get_lbound %p#0, 1
     %i_zero = arith.subi %i, %c1
     %i_p = arith.addi %i_zero,  %p_lb
-    %pelt = hlfir.designate %p, %i_p {fir.ref = "_QPfooEp", fir.def= "_QPfooEp.des002"}
+    %pelt = hlfir.designate %p#0, %i_p
     %bval = fir.load %belt : f32
     %pval = fir.load %pelt : f32
     %mulval = arith.mulf %bval, %pval : f32
-    %celt = hlfir.designate %c, %i {fir.ref = "_QPfooEc", fir.def= "_QPfooEc.des003"}
+    %celt = hlfir.designate %c#0, %i
     %cval = fir.load %celt
     %add_res = arith.addf %mulval, %cval
     fir.result %add_res
   }
-  hlfir.assign %add to %a {fir.ref = "_QPfooEa"} : hlfir.expr<?xf32>, !fir.box<!fir.array<?xf32>
+  hlfir.assign %add to %a#0 : hlfir.expr<?xf32>, !fir.box<!fir.array<?xf32>
   return
 }
 ```
 
 Step2: alias analysis around the array assignment:
 
 -   May %add value depend on %a variable?
 -   Gather variable and function calls in %add operand tree (visiting
     hlfir.elemental regions)
 -   Gather references to %b, %p, and %c. %p is a pointer variable according to
     its defining operations. It may alias with %a that is a target. -> answer
     yes.
 -   Insert temporary, and duplicate array assignments, that can be lowered to
     loops at that point
 
 Note that the alias analysis could have already occurred without inlining the
 %add hlfir.elemental.
 
 
 ```HLFIR
 func.func @_QPfoo(%arg0: !fir.box<!fir.array<?xf32>>, %arg1: !fir.box<!fir.array<?xf32>>, %arg2: !fir.box<!fir.ptr<!fir.array<?xf32>>>, %arg3: !fir.ref<!fir.array<100xf32>>) {
-  %a = fir.declare %arg0 {fir.def = "_QPfooEa"} {fir.target} : !fir.box<!fir.array<?xf32>
-  %b =  fir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>
-  %p = fir.declare %arg2 {fir.def = "_QPfooEp", fir.ptr} : !fir.box<!fir.ptr<!fir.array<?xf32>>>
-  %c =  fir.declare %arg3 {fir.def = "_QPfooEc"} : !fir.ref<!fir.array<100xf32>>
-  %bshape = hlfir.shape_of %b {fir.ref = "_QPfooEb"}
-  %pshape = hlfir.shape_of %p {fir.ref = "_QPfooEp"}
+  %a = hlfir.declare %arg0 {fir.def = "_QPfooEa"} {fir.target} : !fir.box<!fir.array<?xf32>, !fir.box<!fir.array<?xf32>
+  %b =  hlfir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
+  %p = hlfir.declare %arg2 {fir.def = "_QPfooEp", fir.ptr} : !fir.box<!fir.ptr<!fir.array<?xf32>>>, !fir.box<!fir.ptr<!fir.array<?xf32>>>
+  %c =  hlfir.declare %arg3 {fir.def = "_QPfooEc"} : !fir.ref<!fir.array<100xf32>>, !fir.ref<!fir.array<100xf32>>
+  %bshape = hlfir.shape_of %b#0
+  %pshape = hlfir.shape_of %p#0
   %shape1 = hlfir.shape_meet %bshape, %pshape
   %cshape = hlfir.shape_of %c
   %shape2 = hlfir.shape_meet %cshape, %shape1
   %add =  hlfir.elemental(%i:index) %shape2 {
-    %belt = hlfir.designate %b, %i {fir.ref = "_QPfooEb", fir.def= "_QPfooEb.des001"}
-    %p_lb = hlfir.get_lbound %p, 1 {fir.ref = "_QPfooEp"}
+    %belt = hlfir.designate %b#0, %i
+    %p_lb = hlfir.get_lbound %p#0, 1
     %i_zero = arith.subi %i, %c1
-    %i_p = arith.addi %i_zero,  %p_lb
-    %pelt = hlfir.designate %p, %i_p {fir.ref = "_QPfooEp", fir.def= "_QPfooEp.des002"}
+    %i_p = arith.addi %i_zero, %p_lb
+    %pelt = hlfir.designate %p#0, %i_p
     %bval = fir.load %belt : f32
     %pval = fir.load %pelt : f32
     %mulval = arith.mulf %bval, %pval : f32
-    %celt = hlfir.designate %c, %i {fir.ref = "_QPfooEc", fir.def= "_QPfooEc.des003"}
+    %celt = hlfir.designate %c#0, %i
     %cval = fir.load %celt
     %add_res = arith.addf %mulval, %cval
     fir.result %add_res
   }
   %extent = hlfir.get_extent %shape2, 0: (fir.shape<1>) -> index
   %tempstorage = fir.allocmem %extent : fir.heap<fir.array<?xf32>>
-  %temp = fir.declare %tempstorage, shape %extent {fir.def = QPfoo.temp001} : (index) -> fir.heap<fir.array<?xf32>>
-  hlfir.assign %add to %temp : no_overlap {fir.ref = "QPfoo.temp001"} : hlfir.expr<?xf32>, !fir.box<!fir.array<?xf32>
-  hlfir.assign %temp to %a : no_overlap {fir.ref = " QPfoo.temp001,_QPfooEa"} : hlfir.expr<?xf32>, !fir.box<!fir.array<?xf32>
-  hlfir.finalize %temp {fir.ref = "QPfoo.temp001"}
+  %temp = hlfir.declare %tempstorage, shape %extent {fir.def = QPfoo.temp001} : (index) -> fir.box<fir.array<?xf32>>, fir.heap<fir.array<?xf32>>
+  hlfir.assign %add to %temp#0 no_overlap : hlfir.expr<?xf32>, !fir.box<!fir.array<?xf32>>
+  hlfir.assign %temp to %a#0 : no_overlap  : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
+  hlfir.finalize %temp#0
   fir.freemem %tempstorage
   return
 }
 ```
 
 Step 4: Lower assignments to regular loops since they have the no_overlap
 attribute, and inline the hlfir.elemental into the first loop nest.
 
 ```HLFIR
 func.func @_QPfoo(%arg0: !fir.box<!fir.array<?xf32>>, %arg1: !fir.box<!fir.array<?xf32>>, %arg2: !fir.box<!fir.ptr<!fir.array<?xf32>>>, %arg3: !fir.ref<!fir.array<100xf32>>) {
-  %a = fir.declare %arg0 {fir.def = "_QPfooEa"} {fir.target} : !fir.box<!fir.array<?xf32>
-  %b =  fir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>
-  %p = fir.declare %arg2 {fir.def = "_QPfooEp", fir.ptr} : !fir.box<!fir.ptr<!fir.array<?xf32>>>
-  %c =  fir.declare %arg3 {fir.def = "_QPfooEc"} : !fir.ref<!fir.array<100xf32>>
-  %bshape = hlfir.shape_of %b {fir.ref = "_QPfooEb"}
-  %pshape = hlfir.shape_of %p {fir.ref = "_QPfooEp"}
+  %a = hlfir.declare %arg0 {fir.def = "_QPfooEa"} {fir.target} : !fir.box<!fir.array<?xf32>, !fir.box<!fir.array<?xf32>
+  %b =  hlfir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>, !fir.box<!fir.array<?xf32>>
+  %p = hlfir.declare %arg2 {fir.def = "_QPfooEp", fir.ptr} : !fir.box<!fir.ptr<!fir.array<?xf32>>>, !fir.box<!fir.ptr<!fir.array<?xf32>>>
+  %c =  hlfir.declare %arg3 {fir.def = "_QPfooEc"} : !fir.ref<!fir.array<100xf32>>, !fir.ref<!fir.array<100xf32>>
+  %bshape = hlfir.shape_of %b#0
+  %pshape = hlfir.shape_of %p#0
   %shape1 = hlfir.shape_meet %bshape, %pshape
   %cshape = hlfir.shape_of %c
   %shape2 = hlfir.shape_meet %cshape, %shape1
   %extent = hlfir.get_extent %shape2, 0: (fir.shape<1>) -> index
   %tempstorage = fir.allocmem %extent : fir.heap<fir.array<?xf32>>
-  %temp = fir.declare %tempstorage, shape %extent (index) fir.def = QPfoo.temp001} : fir.heap<fir.array<?xf32>>
+  %temp = hlfir.declare %tempstorage, shape %extent {fir.def = QPfoo.temp001} : (index) -> fir.box<fir.array<?xf32>>, fir.heap<fir.array<?xf32>>
   fir.do_loop %i = %c1 to %shape2 step %c1 unordered {
-    %belt = hlfir.designate %b, %i {fir.ref = "_QPfooEb", fir.def= "_QPfooEb.des001"}
-    %p_lb = hlfir.get_lbound %p, 1 {fir.ref = "_QPfooEp"}
+    %belt = hlfir.designate %b#0, %i
+    %p_lb = hlfir.get_lbound %p#0, 1
     %i_zero = arith.subi %i, %c1
     %i_p = arith.addi %i_zero,  %p_lb
-    %pelt = hlfir.designate %p, %i_p {fir.ref = "_QPfooEp", fir.def= "_QPfooEp.des002"}
+    %pelt = hlfir.designate %p#0, %i_p
     %bval = fir.load %belt : f32
     %pval = fir.load %pelt : f32
     %mulval = arith.mulf %bval, %pval : f32
-    %celt = hlfir.designate %c, %i {fir.ref = "_QPfooEc", fir.def= "_QPfooEc.des003"}
+    %celt = hlfir.designate %c#0, %i
     %cval = fir.load %celt
     %add_res = arith.addf %mulval, %cval
-    %tempelt = hlfir.designate %temp, %i {fir.ref = "_QPfoo.temp001", fir.def="_QPfoo.temp001.des004"}
-    hlfir.assign %add_res to %tempelt {fir.ref = "_QPfoo.temp001.des004"}: f32, fir.ref<f32>
+    %tempelt = hlfir.designate %temp#0, %i
+    hlfir.assign %add_res to %tempelt : f32, fir.ref<f32>
   }
   fir.do_loop %i = %c1 to %shape2 step %c1 unordered {
-    %aelt = hlfir.designate %a, %i {fir.ref = "_QPfooEa", fir.def= "_QPfooEa.des005"}
-    %tempelt = hlfir.designate %temp, %i {fir.ref = "_QPfoo.temp001", fir.def="_QPfoo.temp001.des006"}
-    hlfir.assign %add_res to %tempelt {fir.ref = "_QPfoo.temp001.des005,_QPfooEa.des005"}: f32, fir.ref<f32>
+    %aelt = hlfir.designate %a#0, %i
+    %tempelt = hlfir.designate %temp#0, %i
+    hlfir.assign %add_res to %tempelt : f32, fir.ref<f32>
   }
-  hlfir.finalize %temp {fir.ref = "QPfoo.temp001"}
+  hlfir.finalize %temp#0
   fir.freemem %tempstorage
   return
 }
 ```
 
 Step 5 (may also occur earlier or several times): shape propagation.
 -   %shape2 can be inferred from %cshape that has constant shape: the
     hlfir.shape_meet results can be replaced by it, and if the option is set,
     conformance checks can be added for %a, %b and %p.
 -   %temp is small, and its fir.allocmem can be promoted to a stack allocation
 
 ```HLFIR
 func.func @_QPfoo(%arg0: !fir.box<!fir.array<?xf32>>, %arg1: !fir.box<!fir.array<?xf32>>, %arg2: !fir.box<!fir.ptr<!fir.array<?xf32>>>, %arg3: !fir.ref<!fir.array<100xf32>>) {
   // .....
   %cshape = fir.shape %c100
   %extent = %c100
   // updated fir.alloca
   %tempstorage = fir.alloca %extent : fir.ref<fir.array<100xf32>>
-  %temp = fir.declare %tempstorage {fir.def = "_QPfoo.temp001"} : fir.ref<fir.array<100xf32>>
+  %temp = hlfir.declare %tempstorage, shape %extent {fir.def = QPfoo.temp001} : (index) -> fir.box<fir.array<?xf32>>, fir.heap<fir.array<?xf32>>
   fir.do_loop %i = %c1 to %c100 step %c1 unordered {
     // ...
   }
   fir.do_loop %i = %c1 to %c100 step %c1 unordered {
     // ...
   }
-  hlfir.finalize %temp {fir.ref = "QPfoo.temp001"}
+  hlfir.finalize %temp#0
   // deleted fir.freemem %tempstorage
   return
 }
 ```
 
 Step 6: lower hlfir.designate/hlfir.assign in a translation pass:
 
 At this point, the representation is similar to the current representation after

 - If the vector appears in a context where it can be modified (which can only
   be an assignment LHS, or in input IO), lowering could transform the
   hlfir.elemental into hlfir.forall (for assignments), or a fir.iter_while (for
   input IO) by inlining the elemental body into the created loops, and
   identifying the hlfir.designate producing the result.
 
 ```HFLFIR
 func.func @_QPfoo(%arg0: !fir.ref<!fir.array<?xf32>>, %arg1: !fir.ref<!fir.array<?xf32>>, %arg2: !fir.box<<!fir.array<?xi32>>) {
-  %a = fir.declare %arg0 {fir.def = "_QPfooEa"} : !fir.ref<!fir.array<?xf32>>
-  %b = fir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.ref<!fir.array<?xf32>>
-  %v = fir.declare %arg2 {fir.def = "_QPfooEv"} : !fir.box<!fir.array<?xi32>>
+  %a = hlfir.declare %arg0 {fir.def = "_QPfooEa"} : !fir.box<!fir.array<?xf32>>, !fir.ref<!fir.array<?xf32>>
+  %b = hlfir.declare %arg1 {fir.def = "_QPfooEb"} : !fir.box<!fir.array<?xf32>>, !fir.ref<!fir.array<?xf32>>
+  %v = hlfir.declare %arg2 {fir.def = "_QPfooEv"} : !fir.box<!fir.array<?xi32>>, !fir.box<!fir.array<?xi32>>
   %vshape = hlfir.shape_of %v : fir.shape<1>
   %bsection =  hlfir.elemental(%i:index) %vshape : (fir.shape<1>) -> hlfir.expr<?xf32> {
-    %v_elt = hlfir.designate %v, %i {fir.ref = "_QPfooEv", fir.def="_QPfooEv.des001"} : (!fir.box<!fir.array<?xi32>>, index) -> fir.ref<i32>
+    %v_elt = hlfir.designate %v#0, %i : (!fir.box<!fir.array<?xi32>>, index) -> fir.ref<i32>
     %v_val = fir.load %v_elt : fir.ref<i32>
     %cast = fir.convert %v_val : (i32) -> index
-    %b_elt = hlfir.designate %b, %v_val {fir.ref = "_QPfooEb", fir.def="_QPfooEb.des002"} : (!fir.ref<!fir.array<?xf32>>, index) -> fir.ref<f32>
+    %b_elt = hlfir.designate %b#0, %v_val : (!fir.ref<!fir.array<?xf32>>, index) -> fir.ref<f32>
     %b_val = fir.load %b_elt : fir.ref<f32>
     fir.result %b_elt
   }
   %extent = hlfir.get_extent %vshape, 0 : (fir.shape<1>) -> index
   %c1 = arith.constant 1 : index
   hlfir.forall (%i from %c1 to %extent step %c1) {
     %b_section_val = hlfir.apply %bsection, %i : (hlfir.expr<?xf32>, index) -> f32
-    %v_elt = hlfir.designate %v, %i {fir.ref = "_QPfooEv", fir.def="_QPfooEv.des003"} : (!fir.box<!fir.array<?xi32>>, index) -> fir.ref<i32>
+    %v_elt = hlfir.designate %v#0, %i : (!fir.box<!fir.array<?xi32>>, index) -> fir.ref<i32>
     %v_val = fir.load %v_elt : fir.ref<i32>
     %cast = fir.convert %v_val : (i32) -> index
-    %a_elt = hlfir.designate %a, %v_val {fir.ref = "_QPfooEa", fir.def="_QPfooEa.des004"} : (!fir.ref<!fir.array<?xf32>>, index) -> fir.ref<f32>
-    hlfir.assign %b_section_val to %a_elt {fir.ref="_QPfooEa.des004"} : f32, fir.ref<f32>
+    %a_elt = hlfir.designate %a#0, %v_val : (!fir.ref<!fir.array<?xf32>>, index) -> fir.ref<f32>
+    hlfir.assign %b_section_val to %a_elt  : f32, fir.ref<f32>
   }
   return
 }
 ```
 
 This would then be lowered as described in the examples above (hlfir.elemental
 will be inlined, hlfir.forall will be rewritten into normal loops taking into
 account the alias analysis, and hlfir.assign/hlfir.designate operations will be
 lowered to fir.array_coor and fir.store operations).
 
 # Alternatives that were not retained
 
 ## Using a non-MLIR based mutable CFG representation
 
 An option would have been to extend the PFT to describe expressions in a way
 that can be annotated and modified with the ability to introduce temporaries.
 This has been rejected because this would imply a whole new set of
 infrastructure and data structures while FIR is already using MLIR
 infrastructure, so enriching FIR seems a smoother approach and will benefit from
 the MLIR infrastructure experience that was gained.
 
+## Using symbols for HLFIR variables
+
+### Using attributes as pseudo variable symbols 
+
+Instead of introducing hlfir.declare, restricting what memory types an HLFIR
+variable it was considered to force the defining operation of HLFIR variable
+SSA values to always be retrievable. The idea was to add a fir.ref attribute
+that would repeat the name of the HLFIR variable. Using such attribute would
+prevent MLIR to merge to operations using different variable in a new block
+(which is the main reason why the defining op may become inaccessible).
+The advantage is that it allowed all Fortran information of variables (like
+attributes) to always be accessible in HLFIR when looking at their uses, and
+avoid requiring introducing fir.box usages for simply contiguous variables.
+The big drawback is that it implied naming all HLFIR variables, that cover
+much more than Fortran named variables. Naming designators with unique names
+was not very natural, and would make designator CSE harder.  It also made
+inlining harder, because inlining HLFIR code without any fir.def/ fir.ref
+attributes renaming would break the name uniqueness, which could lead to some
+operation using different variables to be merged, and to break the assumption
+that parent operation must be visible. Renaming would be possible, but would
+increase complexity and risks. Besides, inlining may not be the only
+transformation doing code motion, and whose complexity would be increased by
+the naming constraints.
+
+
+### Using MLIR symbols for variables
+
+Using MLIR symbols for HLFIR variables has been rejected because MLIR symbols
+are mainly intended to deal with globals and functions that may refer to each
+other before being defined. Their processing is not as light as normal values,
+and would require to turn every FIR operation with a region into an MLIR symbol
+table. This would especially be annoying given fir.designator also produce
+variables with their own properties, which would imply creating a lot of MLIR
+symbols. All the operations that both accept variable and expression operands
+would also either need to be more complex in order to both accept SSA values or
+MLIR symbol operands (or some fir.as_expr %var operation should be added to
+turn a variable into an expression). Given all variable definitions will
+dominates their uses, it seems more adequate to use an SSA model with named
+attributes. Using SSA values also makes the transition and mix with lower-level
+FIR operations smoother: a variable SSA usage can simply be replaced by
+lower-level FIR operations using the same SSA value.
+
 ## Using some existing MLIR dialects for the high-level Fortran.
 
 ### Why not using Linalg dialect?
 
 The linalg dialects offers a powerful way to represent array operations: the
 linalg.generic operation takes a set of input and output arrays, a related set
 of affine maps to represent how these inputs/outputs are to be addressed, and a
 region detailing what operation should happen at each iteration point, given the