Unneeded storage pool init/final

Unneeded storage pool init/final

[Stanley R. Allen]

Does anyone know?

Given this package spec and body:

------------- pack1.ads ------------------
with Ada.Finalization;
use Ada.Finalization;
package Pack1 is

    type List is limited private;

    procedure Create (L : in out List; Value: Integer);

    function Equal (A, B : List) return Boolean;


private

    type List is new Limited_Controlled with record
        Num_Elements : Integer;
    end record;

    type List_Pointer is access all List;

end Pack1;

------------- pack1.adb ---------------
package body Pack1 is

    procedure Create (L : in out List; Value : Integer) is
    begin
        L.Num_Elements := Value;
    end Create;

    function Equal (A, B : List) return Boolean is
        type Const_Lp is access constant List;
    begin
        return Const_Lp '(A'access) = B'access
                or else A.Num_Elements = B.Num_Elements;
    end Equal;

end Pack1;
----------------------------------------

My understanding is that the declaration of Const_Lp
will cause a storage pool to be initialized and
finalized every time Equal is executed, even though no
allocation is performed, and the type is only needed for
the qualified expression used in the return statement.

At least, that is how I understand things based on
the following output from the gnat compiler (using
gcc -c -gnatdg pack1.adb):

-------------------------------------------
with system.tasking_soft_links;

package body pack1 is
   
   procedure create (l : in out list; value : integer) is
   begin
      l.num_elements := value;
      return;
   end create;
   
   function equal (a : list; b : list) return boolean is
      F1b : finalizable_ptr := null;
      
      procedure _clean is
      begin
         abort_defer.all;
         finalize_list (F1b);
         abort_undefer.all;
         return;
      end _clean;
   begin
      type const_lp is access constant list;
      freeze const_lp [
         const_lpL : list_controller;
         _init_proc (const_lpL);
         attach_to_final_list (F1b, finalizable?(const_lpL), 1);
         initialize (const_lpL);
      ]
      return const_lp'(a'access) = b'access or else
        a.num_elements = b.num_elements;
   at end
      _clean;
   end equal;
end pack1;
pack1_E := true;

----------------------------------------------

So, my questions are:

Is a pool being created by the declaration of Const_Lp?

Is it the creation of the pool which causes GNAT to
perform initialization/finalization in the implicit
code shown above (because Root_Storage_Pool is based
on Ada.Finalization.Limited_Controlled)?

Is there a way to eliminate this implicit code?
(After all, it is overkill for the purpose for 
which type Const_Lp exists, namely to give me the
ability to ask if a'access=b'access).

(I know that I can move the declaration of Const_Lp
out to the library level and change the 'access
references to 'unchecked_access; this is good as 
a workaround, but it makes Const_Lp more visible 
than I like.)

These two approaches don't achieve the desired
effect (at least as far as GNAT is concerned,
because I still see the implicit code using
gnat -c -gnatdg):

    for Const_Lp'Storage_Size use 0;

    for Const_Lp'Storage_Pool use List_Pointer'Storage_Pool;

Either these are not valid ways of eliminating the
pool or its init/final code, or the GNAT compiler
doesn't optimize out the init/final code in these
cases.

If better optimization would solve the problem,
then is it possible for a compiler to recognize
that no allocation is taking place in the original
code, and use that knowledge to optimize away the
init/final code, or is there some case in the Ada
rules which makes this impossible?

Am I missing something obvious?

-- 
Stanley Allen
mailto:s_allen@hso.link.com