You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
int %main(int %argc, ubyte** %argv) {
%malloc_206 = malloc [10 x ubyte]
%malloc_206.sub = getelementptr [10 x ubyte]* %malloc_206, int 0, int 0
free ubyte* %malloc_206.sub
ret int 0
}
The text was updated successfully, but these errors were encountered:
* This fixes a number of issues.
When dealing with values (including aggregates) that have dependent type,
FIR requires that we thread the type parameter values through the IR.
Note that boxed values contain type parameters inside the box. It is a
requirement that the type parameter(s) can be recovered from a box
value.
- Add verifiers that determine if an Op requires type parameters or
not and checks that the correct number of parameters is specified.
- Fix lowering to add the proper number of type parameters.
- Fix transformations that were losing type parameter information.
Fix code gen bug that was scaling the size of an element twice.
Fix tests to reflect these changes.
* Rework the code that is meant to recover the type parameters from a
boxed value. We cannot handle derived types with LEN parameters at all.
Boxed values are immutable, of course, so recovering data from them
should not be controversial.
Boxed variables need to be reconsidered. It may be possible currently to
have a variable of type box that is in a logical inconsistent state, so
it would be incorrect to read its state directly. Simplifying this
should be considered.
Also:
- refactor redundant type tests to use the SPOT tests from FIRType.h
- replace the term "length parameter" with "LEN parameter" to be
consistent and to follow the Fortran surface syntax, which uses LEN.
troelsbjerre
pushed a commit
to troelsbjerre/llvm-project
that referenced
this issue
Jan 10, 2024
Extended Description
The optimizer doesn't remove malloc/free instructions when the allocated memory
is not used.
My example (but it does the same with simply a couple of malloc/free instructions)
Before optimization:
int %main(int %argc, ubyte** %argv)
{
%c_19 = alloca ubyte*
%malloc_206 = malloc ubyte, uint 10
store ubyte* %malloc_206, ubyte** %c_19
%tmp_207 = load ubyte** %c_19
free ubyte* %tmp_207
ret int 0
}
After optimization:
int %main(int %argc, ubyte** %argv) {
%malloc_206 = malloc [10 x ubyte]
%malloc_206.sub = getelementptr [10 x ubyte]* %malloc_206, int 0, int 0
free ubyte* %malloc_206.sub
ret int 0
}
The text was updated successfully, but these errors were encountered: