This PR fixes `not yet implemented: procedure pointer component in
structure constructor` as shown in the following test case.
```
MODULE M
TYPE :: DT
PROCEDURE(Fun), POINTER, NOPASS :: pp1
END TYPE
CONTAINS
INTEGER FUNCTION Fun(Arg)
INTEGER :: Arg
Fun = Arg
END FUNCTION
END MODULE
PROGRAM MAIN
USE M
IMPLICIT NONE
TYPE (DT) :: v2
PROCEDURE(FUN), POINTER :: pp2
v2 = DT(pp2)
v2 = DT(bar())
CONTAINS
FUNCTION BAR() RESULT(res)
PROCEDURE(FUN), POINTER :: res
END
END
```
Cray pointee symbols can be host associated from a module or host
procedure while the related cray pointer is not explicitly associated.
This caused the "not yet implemented: lowering symbol to HLFIR" to fire
when lowering a reference to the cray pointee and fetching the cray
pointer.
This patch:
- Ensures cray pointers are always instantiated when instantiating a
cray pointee.
- Fix internal procedure lowering to deal with cray pointee host
association like it does for pointers (the lowering strategy for cray
pointee is to create a pointer that is updated with the cray pointer
value before being fetched).
This should fix the bug reported in
https://github.com/llvm/llvm-project/issues/85420.
A mold argument need to be added to the hlfir.element_addr and set in
lowering so that when the hlfir.element_addr need to be turned into an
hlfir.elemental operation because the designator must be turned into a
value, the mold can be set on the hlfir.elemental to later allocate the
temporary according the the dynamic type.
This situation happens whenever the vector subscripted polymorphic
designator does not appear as an assignment left-hand side, or as an
IO-input item.
I initially thought retrieving the mold would be tricky if the dynamic
type of the designator was set by a part-ref of the right of the vector
subscripts ("array(vector)%polymorphic_comp"), but this turned out to be
impossible because:
1. A derived type component can be polymorphic only if it has the
POINTER or ALLOCATABLE attribute (F2023 C708).
2. Vector-subscripted part are ranked and F2023 C919 prohibits any
part-ref on the right of the rank part to have the POINTER or
ALLOCATABLE attribute.
=> If a vector subscripted designator is polymorphic, the vector
subscripted part is the rightmost part, and the mold is the base of the
vector subscripted part. This makes the retrieval of the mold easy in
lowering. The mold argument is always set to be the base of the vector
subscripted part when lowering the vector subscripted part, and it is
removed at the end of the designator lowering if the designator is not
polymorphic. This way there is no need to find back the mold from the
inside of the hlfir.element_addr body.
Allocatable components of structure constructors were not deallocated.
Deallocate them without calling final subroutines.
This was already properly done for array constructors.
In fortran, it is possible to give a negative "i" in "character(i)" in
which case the standard says the length is zero. So the length must be
sanitized as max(0, user_input) in lowering.
This is already done when lowering specification parts, but was not done
when "character(i)" appears in array constructors. Sanitize the length
when lowering SetLength in lowering.
Fixes https://github.com/llvm/llvm-project/issues/80270
This PR adds lowering the reference to a function that returns a
procedure pointer. It also fixed intrinsic ASSOCIATED to take such
argument.
---------
Co-authored-by: jeanPerier <jperier@nvidia.com>
Start implementing assumed-rank support as described in
https://github.com/llvm/llvm-project/blob/main/flang/docs/AssumedRank.md
This commit holds the minimal support for lowering calls to procedure
with assumed-rank arguments where the procedure implementation is done
in C.
The case for passing assumed-size to assumed-rank is left TODO since it
will be done a change in assumed-size lowering that is better done in
another patch.
Care is taken to set the lower bounds to zero when passing non allocatable no pointer as descriptor
to a BIND(C) procedure as required per 18.5.3 point 3. This was not done before while the requirements also applies to non assumed-rank descriptors. This change required special attention with IGNORE_TKR(t) to avoid emitting invalid fir.rebox operations (the actual argument type must be used in this case as the output type).
Implementation of Fortran procedure with assumed-rank arguments is still
TODO.
There is no need to gather the length parameters from the parameter
symbols when facing a deferred length allocatable components in a
structure constructor, the length is set as part of the assignment given
the value.
Remove the checks for derived type runtime info symbols, this is not
relevant for what is being tested here.
Lower procedure pointer components, except in the context of structure
constructor (left TODO).
Procedure pointer components lowering share most of the lowering logic
of procedure poionters with the following particularities:
- They are components, so an hlfir.designate must be generated to
retrieve the procedure pointer address from its derived type base.
- They may have a PASS argument. While there is no dispatching as with
type bound procedure, special care must be taken to retrieve the derived
type component base in this case since semantics placed it in the
argument list and not in the evaluate::ProcedureDesignator.
These components also bring a new level of recursive MLIR types since a
fir.type may now contain a component with an MLIR function type where
one of the argument is the fir.type itself. This required moving the
"derived type in construction" stackto the converter so that the object
and function type lowering utilities share the same state (currently the
function type utilty would end-up creating a new stack when lowering its
arguments, leading to infinite loops). The BoxedProcedurePass also
needed an update to deal with this recursive aspect.
This patch is fixing two issue relative to the dynamic dispatch for
polymorphic entities.
1. Fix the `requireDispatchCall` function. It was checking for the first
symbol of the component but this is not the one to be checked. Instead
the last symbol of the base of the component object is the one to check
to know if it is polymorphic object with a dispatch call or not. This is
demonstrated in the new added test in `flang/test/Lower/dispatch.f90`
where the first symbol would point to `q` which is monomorphic and would
result in a simple `fir.call`
2. Fix the pass object in a no pass situation. In a no pass situation
the pass object is lowered anyway to be able to do the lookup in the
binding table. It was previously lowered wrongly an lead to unresolved
lookup. The base of the component is the passed object and should be
lowered. To achieve this, the `gen(DataRef)` entry point is exposed form
`ConvertExprToHLFIR` through a `convertDataRefToValue` function. The
same test added in `flang/test/Lower/dispatch.f90` is checking for the
correct passed object.
In addition couple of tests were updated to HLFIR since the lowering
used only works with it.
**Scope of the PR:**
1. Lowering global and local procedure pointer declaration statement
with explicit or implicit interface. The explicit interface can be from
an interface block, a module procedure or an internal procedure.
2. Lowering procedure pointer assignment, where the target procedure
could be external, module or internal procedures.
3. Lowering reference to procedure pointers so that it works end to end.
**PR notes:**
1. The first commit of the PR does not include testing. I would like to
collect some comments first, which may alter the output. Once I confirm
the implementation, I will add some testing as a follow up commit to
this PR.
2. No special handling of the host-associated entities when an internal
procedure is the target of a procedure pointer assignment in this PR.
**Implementation notes:**
1. The implementation is using the HLFIR path.
2. Flang currently uses `getUntypedBoxProcType` to get the
`fir::BoxProcType` for `ProcedureDesignator` when getting the address of
a procedure in order to pass it as an actual argument. This PR inherits
the same design decision for procedure pointer as the `fir::StoreOp`
requires the same memory type.
Note: this commit is actually resubmitting the original commit from
PR #70461 that was reverted. See PR #73221.
**Scope of the PR:**
1. Lowering global and local procedure pointer declaration statement
with explicit or implicit interface. The explicit interface can be from
an interface block, a module procedure or an internal procedure.
2. Lowering procedure pointer assignment, where the target procedure
could be external, module or internal procedures.
3. Lowering reference to procedure pointers so that it works end to end.
**PR notes:**
1. The first commit of the PR does not include testing. I would like to
collect some comments first, which may alter the output. Once I confirm
the implementation, I will add some testing as a follow up commit to
this PR.
2. No special handling of the host-associated entities when an internal
procedure is the target of a procedure pointer assignment in this PR.
**Implementation notes:**
1. The implementation is using the HLFIR path.
2. Flang currently uses `getUntypedBoxProcType` to get the
`fir::BoxProcType` for `ProcedureDesignator` when getting the address of
a procedure in order to pass it as an actual argument. This PR inherits
the same design decision for procedure pointer as the `fir::StoreOp`
requires the same memory type.
The front-end is making implicit conversions explicit in assignment and
structure constructors.
While this generally helps and is needed by semantics to fold structure
constructors correctly, this is incorrect when the LHS or component is
an allocatable. The RHS may have non default lower bounds that should be
propagated to the LHS, and making the conversion explicit changes the
semantics. In the structure constructor, the situation is even worse
since Fortran 2018 7.5.10 point 7 allows the value to be a reference to
an unallocated allocatable, and adding an explicit conversion in
semantics will cause a segfault.
This patch removes the explicit convert in semantics when the
LHS/component is a whole allocatable, and update lowering to deal with
the conversion insertion, dealing with preserving the lower bounds and
the tricky structure constructor case.
OpenACC/OpenMP atomic lowering needs a finer control over expression
lowering. This patch allows mapping evaluate::Expr<T> to mlir::Value so
that any subsequent expression lowering will use these values when an
operand is a mapped Expr<T>.
This is an alternative to
https://github.com/llvm/llvm-project/pull/69866 From which I took the
test and some of the logic to extract the non-atomic sub-expression.
---------
Co-authored-by: Nimish Mishra <neelam.nimish@gmail.com>
Type extension is currently handled in FIR by inlining the parents
components as the first member of the record type.
This is not correct from a memory layout point of view since the storage
size of the parent type may be bigger than the sum of the size of its
component (due to alignment requirement). To avoid making FIR types
target dependent and fix this issue, make the parent component a single
component with the parent type at the beginning of the record type.
This also simplifies addressing since parent component is now a "normal"
component that can be designated with hlfir.designate.
StructureComponent lowering however is a bit more complex since the
symbols in the structure component may refer to subcomponents of parent
types.
Notes:
1. The fix is only done in HLFIR for now, a similar fix should be done
in ConvertExpr.cpp to fix the path without HLFIR (I will likely still do
it in a new patch since it would be an annoying bug to investigate for
people testing flang without HLFIR).
2. The private component extra mangling is useless after this patch. I
will remove it after 1.
3. The "parent component" TODO in constant CTOR is free to implement for
HLFIR after this patch, but I would rather remove it and test it in a
different patch.
As shown in #64315, there were issues when trying to lower two flavors
of Fortran code that implicitly perform `CHARACTER` conversion.
This PR addresses those issues.
It is possible for a derived type extending a type with private
components to define components with the same name as the private
components.
This was not properly handled by lowering where several fir.record type
component names could end-up being the same, leading to bad generated
code (only the first component was accessed via fir.field_index, leading
to bad generated code).
This patch handles the situation by adding the derived type mangled name
to private component.
A Cray pointee reference must be done using the characteristics
(bounds, type params) of the original pointee declaration, but
using the actual address value of the associated Cray pointer.
There might be multiple Cray pointees associated with the same
Cray pointer.
The proposed solution is to lower each Cray pointee into a POINTER
variable with a descriptor. The descriptor is initialized at the point
of declaration of the pointee, though its base_addr is set to null.
Before each reference of the Cray pointee its descriptor's base_addr
is updated to the current value of the Cray pointer.
The update of the base_addr is done using PointerAssociateScalar
runtime call, which just updates the base_addr of the descriptor.
This is a temporary solution just to make Cray pointers work
to the same extent they work with FIR lowering.
Unlike other executable constructs with associating selectors, the
selector of a SELECT RANK construct can have the ALLOCATABLE or POINTER
attribute, and will work as an allocatable or object pointer within
each rank case, so long as there is no RANK(*) case.
Getting this right exposed a correctness risk with the popular
predicate IsAllocatableOrPointer() -- it will be true for procedure
pointers as well as object pointers, and in many contexts, a procedure
pointer should not be acceptable. So this patch adds the new predicate
IsAllocatableOrObjectPointer(), and updates some call sites of the original
function to use the new one.
Differential Revision: https://reviews.llvm.org/D159043
In case of unlimited polymorphic type, there is no derived type
spec, so use NoneType explicitly.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D157751
The parenthesis' operand is used as a mold for the generated
hlfir.elemental.
Depends on D157316
Reviewed By: tblah, clementval
Differential Revision: https://reviews.llvm.org/D157318
The problem appeared as a segfault for case like this:
```
type t
character(11), allocatable :: c
end type
character(12), alloctable :: x
type(t) y
y = t(x)
```
The frontend representes `y = t(x)` as `y=t(c=%SET_LENGTH(x,11_8))`.
When 'x' is unallocated the hlfir.set_length lowering results in
segfault. It could probably be handled in hlfir.set_length lowering
by using NULL base for the hlfir.declare depending on the allocation
status of 'x', but I am not sure if !hlfir.expr, in general, is supposed
to represent an expression created from unallocated allocatable.
I believe in Fortran that would mean referencing an unallocated
allocatable, which is not allowed.
I decided to special case `SET_LENGTH` in structure constructor,
so that we use its 'x' operand as the RHS for the assign operation
implying the isAllocatable check for cases when 'x' is allocatable.
This requires setting keep_lhs_length_if_realloc flag for the assign
operation. Note that when the component being intialized has
deferred length the frontend does not produce `SET_LENGTH`.
Differential Revision: https://reviews.llvm.org/D155151
If I understand it correctly, the TODO is intended to catch cases
when we may need to create a temporary array for polymorphic entities
resulting from a vector subscription, i.e. when the final expression
type of hlfir.elemental_addr is polymorphic. The TODO check was done
very early, so it kicked in for cases where the it should not have.
For example,
```
type t
integer n
end type
class(t), pointer :: p(:)
... p(vector_of_indices)%n
```
Such designators are supported by FIR lowering and can be currently
supported by HLFIR, but the TODO prevented this. I just moved the TODO
check later in the lowering pipeline.
I also updated the comment trying to describe my understanding of how
the correct mold entity can be computed for the elemental operation
producing HLFIR expression of polymorphic type.
This change provides 34 new passes in my nag testing.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D154814
When an initializer value is missing for an allocatable component
in a structure constructor, the RHS is NULL() expression.
We should just skip this part of the initializer, since the component
must become unallocated (as it is from the initialization).
Runtime detected rank mismatch when we tried to pass NULL() box
RHS for assigning it to the unallocated component of rank 1, 2, etc.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D154906
Currently, when a (legacy) DEC structure contained other DEC structure
declarations, the related component names were not added to the
containing DerivedTypeDetails component_names. This lead to bugs in
later phase when visiting the components (like in when lowering the
type to FIR/MLIR).
When an EntityDecl is visited and the scope is a DEC structure, add
the entity to the component names of this DEC structure.
Differential Revision: https://reviews.llvm.org/D154216
This patch adds 'unordered' attribute handling the HLFIR elementals'
builders and fixes the attribute handling in lowering and transformations.
Depends on D154031, D154032
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D154035
Component-by-component assignment must be able to handle unallocated
allocatable values in structure constructor. F2018 7.5.10 p. 7 states
that the component must have unallocated status as a result of such
construction. The structure constructor temporary is initialized
such that all the allocatable components are unallocated, so we just
need to make sure not to do the component assignment if RHS is deallocated.
Depends on D152482 (the same LIT test is affected)
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D152493
When `AssignOp` is used with LHS that is a compiler generated temporary
special care must be taken to initialize the temporary and avoid
finalizations of its components. This change-set adds optional
`temporary_lhs` attribute for `AssignOp` to convey this information
to HLFIR-to-FIR conversion pass. Currently, this results in
calling `AssignTemporary` runtime for doing the assignment.
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D152482
I tried this patch, first. Some tests failed because of the extra
finalizations for the temporary LHSs: when LHS component is a derived
type with final subprograms, the finalizations might be detected
by counting/printing in the final subprograms and treated as errors
in the tests, because they are not expected.
So I also tried to reuse the StructureConstructor code lowering to FIR
followed by AsExprOp to produce the HLFIR "value". Unfortunately,
this did not resolve the finalization issues, because AsExprOp may
end up being bufferized into AssignOp as well.
So the extra finalizations are inherent problem for AssignOp,
and it has to be resolved separately. Thus, I decided to proceed
with a "cleaner" direct lowering to HLFIR (the initial patch).
I am thinking about adding an extra flag for AssignOp that would
indicate that the LHS is a compiler generated temporary, so we could
use something like AssignTemporary() in HLFIR-to-FIR converter.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D151752
With this change, the lowering provides full slice triples for
designators like ...%array_comp%im/re, so that the codegen
does not have to figure it out for the array_comp.
Basically, ...%array_comp%im/re is lowered the same way
as ...%array_comp(:,:,...)%im/re.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D150842
Without the TODO, MLIR verifier fails because of invalid hlfir.declare
or fir.alloca that lowering produces.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D150911
Currently complex division is lowered to a fir.divc operation and the
fir.divc is later converted to a sequence of llvm operations to perform
complex division, however this causes issues for extreme values when
the calculations overflow.
This patch changes the lowering of complex division to use the Intrinsic
Call functionality to lower into library calls (for single, double,
extended and quad precisions) or an MLIR complex dialect division operation
(for half and bfloat precisions).
A new wrapper function `genLibSplitComplexArgsCall` is written to handle
the case of the arguments of the Complex Library calls being split to
its real and imaginary real components.
Note 1: If the Complex To Standard conversion of division operation
matures then we can use it for all precisions. Currently it has the
same issues as the conversion of fir.divc.
Note 2: A previous patch (D145808) did the same but during conversion of
the fir.divc operation. But using function calls at that stage leads to
ABI issues since the conversion to LLVM is not aware of the complex target
rewrite.
Note 3: If the patch is accepted, fir.divc can be removed from FIR. We
can use the complex.div operation where any transformation is required.
Reviewed By: vzakhari, PeteSteinfeld, DavidTruby, jeanPerier
Differential Revision: https://reviews.llvm.org/D149546
The implied-do index value has 'index' type, and it has to be
converted to the original ac-do-variable's data type.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D150150
This patch lowers assignments to vector subscripted designators into the
newly added hlfir.elemental_addr and hlfir.region_assign.
Note that the codegen of these operation to FIR is still TODO and will
still emit a TODO message when trying to compile programs end to end.
Differential Revision: https://reviews.llvm.org/D149962
I removed the barriers a bit fast. Some mold is needed on
hlfir.elemental for polymorphic vector subscripted designator (and for
parenthesized polymorphic) so that a temporary can be later created.
The parenthesized array case may also just used asExpr and that
could later use AssignTemporary to deal with this. But the vector
subscripted designator case will need to use some new runtime
to get some mold allocation done for the temp.
Add TODOs in the meantime.
Differential Revision: https://reviews.llvm.org/D149970
Lower vector subscripted designators as values when they appear outside
of the assignment left-hand side and input IO contexts.
This matches Fortran semantics where vector subscripted designators cannot
be written to outside of the two contexts mentioned above: they are
passed/taken by value where they appear.
This patch uses the added hlfir.element_addr to lower vector designators
in lowering. But when reaching the end of the designator lowering, the
hlfir.element_addr is turned into an hlfir.elemental when lowering is
not asking for the hlfir.elemental_addr.
This approach allows lowering vector subscripted in the same way in
while visiting the designator, and only adapt to the context at the
edge.
The part where lowering uses the hlfir.elemental_addr will be
done in further patch as it requires lowering assignments in the
new hlfir.region_assign op, and there is not codegen yet for these
new operations.
Differential Revision: https://reviews.llvm.org/D149480
Skip the parent components when they are not at the end of
designators.
Generate an hlfir.parent_comp for parent component at the end
of designators.
Differential Revision: https://reviews.llvm.org/D144948
This is the first and biggest chunk that introduces support for
array constructor to HLFIR.
This patch:
- adds a new ConvertArrayConstructor.cpp that centralizes the
code dealing with array constructor lowering.
- introduces a framework to lower array constructor according to
different strategies: A common analysis of the array constructor is
done, and based on that, a lowering startegy is selected and driven
through the ac-values of the array constructor. See
ConvertArrayConstructor.cpp comments for more details.
- implements the first strategy that creates a temporary inlined and
updates it with inlined code. This strategy can only be used if the
temporary can be pre-allocated (i.e: the extents and length parameters
can be pre-computed without evaluating any ac-values), and if all the
ac-value expressions are scalars.
For the sake of simplicity, characters and derived type will be enabled
once all the strategies are added.
Reviewed By: clementval, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D144102
- Add a convertProcedureDesignatorToHLFIR that converts the
fir::ExtendedValue from the current lowering to a
fir.boxproc/tuple<fir.boxproc, len> mlir::Value.
- Allow fir.boxproc/tuple<fir.boxproc, len> as hlfir::Entity values
(a function is an address, but from a Fortran entity point of view,
procedure that are not procedure pointers cannot be assigned to, so
it makes a lot more sense to consider those as values).
- Modify symbol association to not generate an hlfir.declare for dummy
procedures. They are not needed and allowing hlfir.declare to declare
function values would make its verifier and handling overly complex
for little benefits (maybe an hlfir.declare_proc could be added if it
turnout out useful later for debug info and attributes storing
purposes).
- Allow translation from hlfir::Entity to fir::ExtendedValue.
convertToBox return type had to be relaxed because some intrinsics
handles both object and procedure arguments and need to lower their
object arguments "asBox". fir::BoxValue is not intended to carry
dummy procedures (all its member functions would make little sense
and its verifier does not accept such type).
Note that AsAddr, AsValue and AsBox will always return the same MLIR
value for procedure designators because they are always handled the
same way in FIR.
Differential Revision: https://reviews.llvm.org/D143585
These will be useful for sharing code with intrinsic argument processing
when lowering hlfir transformational intrinsic operations to FIR in
the BufferizeHLFIR pass.
Differential Revision: https://reviews.llvm.org/D143503
Lower extents and lower bounds inquiries with a compile time
constant DIM that cannot be folded by the front-end.
Differential Revision: https://reviews.llvm.org/D143476
Implement the TODO. Be careful to use and propagate the expression
type to create the temporary since the mlir value may have been computed
with a different value type (e.g., i1 for logical) that should not be
used for in memory values that must have Fortran types.
Co-authored-by: Tom Eccles <tom.eccles@arm.com>
Differential Revision: https://reviews.llvm.org/D143421
This will allow IntrinsicCall to be used in passes to implement hlfir
transformational intrinsic operations.
Differential Revision: https://reviews.llvm.org/D143084
In lowering to HLFIR, deal with user calls involving a mix of:
- dummy with VALUE
- Polymorphism
- contiguous dummy
- assumed shape dummy
- OPTIONAL arguments
- NULL() passed to OPTIONAL arguments.
- elemental calls
Does not deal with assumed ranked dummy arguments.
This patch unifies the preparation of all arguments that must be passed
in memory and are not passed as allocatable/pointers.
For optionals, the same argument preparation is done, except the utility
that generates the IR for the argument preparation is called inside a
fir.if.
The addressing of array arguments in elemental calls is delayed so that
it can also happen during this argument preparation, and be placed in
the fir.if when the array may be absent.
Structure helpers are added to convey a prepared dummy argument and the
data that may be needed to do the clean-up after the call (temporary
storage deallocation or copy-out). And a utility is added to wrap
the preparation code inside a fir.if and convey these values through
the fir.if.
Certain aspects of this patch brings the HLFIR lowering support beyond
what the current lowering to FIR supports (e.g. handling of NULL(), handling
of optional in elemental calls, handling of copy-in/copy-out involving
polymorphic entities).
Differential Revision: https://reviews.llvm.org/D142695
The previous patches allowed lowering allocatable/and pointer designator
expressions with HLFIR.
This patch updates the bridge genExprMutableBox to use HLFIR lowering
when HLFIR flag is set. For allocate and deallocate lowering that use
genExprMutableBox, no other change is needed.
For pointer assignments, the code doing the pointer assignments in the
bridge can be reused and is simply moved so that it can be shared, and
the "explicit context" special cases of the previous lowering are
by-passed.
The code doing pointer assignment revealed that convertExprToAddress
did not match the previous genExprAddr behavior (that actually
does not create temps for "x" where x is not contiguous).
Instead of trying to copy the old behavior that is a bit weird (was
dictated by the implementation rather than design). Update
convertExprToAddress to do something sensible and that works with
the current genExprAddr usages (if anything, it should saves bogus
array section temps).
Differential Revision: https://reviews.llvm.org/D142197
