TREE_PUBLIC for module symbols?

[Paul Richard Thomas]

Dear FX and Janne,

Thank you for your helpful remarks. I had formed the opinion that IPR
was not important but wanted to act as devil's advocate to elicit
views on the matter.

The odd thing is that if TREE_PUBLIC is not set for the private
symbols, all works perfectly without optimization. Even at -O1 the
objects disappear as far as the linker is concerned, unless they are
referenced locally by a public procedure. Since submodules are meant
to be host associated associated with their ancestor module,
references from submodules should be able to effect the same thing. I
just don't see how to do it right now.....

Cheers

Paul

On 2 July 2015 at 08:40, Janne Blomqvist <blomqvist.janne@gmail.com> wrote:
> On Wed, Jul 1, 2015 at 9:51 PM, Paul Richard Thomas
> <paul.richard.thomas@gmail.com> wrote:
>>
>> Hi Damian,
>>
>> There is a double problem:
>>
>> (i) Since entities in submodules have to behave as if they are host
>> associated to the module, it means that all entities in the module
>> have to be visible. I have chosen to implement this by having two
>> parts to the module file; the first is the normal part, such that
>> other program units than submodules can use the module as usual. The
>> second part contains everything else and is only read by submodules.
>> This has the advantage of minimizing the changes. However, it means
>> that the potentially IPR sensitive part of the module is visible by
>> gunzipping the module file.
>
>
> I agree with FX that any IPR issues are not relevant here.
>
>>
>>
>> (ii) The fact that all the private entities in the module have to be
>> TREE_PUBLIC means that, in principle, they are visible and accessible
>> outside submodules. I do not think that this much of a problem but I
>> am worried that I do not know enough to be sure of this.
>
>
> Apart from making the compilation cascade issues worse for existing code as
> Damian mentioned, this could also affect inliner heuristics (assuming
> TREE_PUBLIC means what I recall it does). If a symbol is public the
> "standalone" version must exist in the object file, whereas if it's private
> it could be inlined into all callers and the "standalone" version be
> omitted. And if it's not possible to omit it, it might affect inliner
> heuristics whether it's worth inlining. For a trivial example, IIRC with -O1
> and higher gcc always inlines a private function which is called from only
> one location, regardless of its size. So by making private symbols public we
> might have bigger code and/or worse performance e.g. due to lack of constant
> propataion into inlined functions etc.
>
>>
>>
>> My thinking is that one could encrypt the private part of the module
>> file but, being open source, the key would be visible and even a
>> slightly determined hacker could expose the private entities. For this
>> reason, I do not think that it is worth trying.
>>
>> I would be very curious to know what the other brands have done, since
>> I think that this is a problem that is implicit to the introduction of
>> submodules. Of course, one of the advantages of submodules is that all
>> the IPR can be hidden there, if this is an issue. Maybe we in gfortran
>> should take the view that open source is where we are at?
>>
>> Cheers
>>
>> Paul
>>
>> On 1 July 2015 at 19:37, Damian Rouson <damian@sourceryinstitute.org>
>> wrote:
>> >
>> >
>> >> On Jul 1, 2015, at 3:42 AM, Paul Richard Thomas
>> >> <paul.richard.thomas@gmail.com> wrote:
>> >>
>> >> Dear Tobias,
>> >>
>> >> Following the latest version of my submodule patch, I have managed to
>> >> overcome the difficulty of making private symbols available to
>> >> submodules in a reasonably economical fashion. Of course, the solution
>> >> makes these symbols visible in the module file, albeit in a different
>> >> section to public symbols.
>> >
>> > How does this impact the compiler cascade?  If private entities appear
>> > in the module file, then won’t that cause other program scopes to be
>> > recompiled whenever there are changes to private symbols in the module file
>> > change.  My understanding is that preventing unnecessary compiler cascades
>> > was one of the primary motivations for submodules. If not preventing them is
>> > the cost of an economical solution, then it might be worth redefining
>> > economical to include the costs of compiling. :)
>> >
>> >>
>> >> Since private symbols are now visible in the module files, the meaning
>> >> or usefulness of privacy becomes rather moot, as already discussed on
>> >> the list.
>> >
>> > In light of what I wrote above, it might be time to consider paths other
>> > than storing private symbols in the module file.  However, as you know, I’m
>> > a fan of progressive steps.  It would be reasonable to accept otherwise
>> > unnecessary compiler cascades as a necessary evil of getting submodules into
>> > the compiler expediently, but I hope there will be subsequent consideration
>> > of a redesign after the initial submodule support is complete.
>> >
>> >> This conundrum is made still worse because module variables
>> >> have to be set TREE_PUBLIC, otherwise they disappear at any level of
>> >> optimization and leave the linker complaining verbosely.
>> >
>> > Ouch.  I think most Fortran programmers would rank runtime performance
>> > above compile-time performance.  Hmm… I guess it wouldn’t be the first time
>> > a new language construct didn’t achieve its intended purpose (preventing
>> > cascades), but let’s hope someone can propose a way to get both.
>> >
>> >>
>> >> Consider an example:
>> >> module foo
>> >>
>> >>  private
>> >>
>> >>  public bar
>> >>
>> >>  integer :: a = 1
>> >>
>> >>  interface
>> >>    module subroutine bar
>> >>    end subroutine
>> >>  end interface
>> >>
>> >> contains
>> >> end module
>> >>
>> >> submodule(foo) fooson
>> >>
>> >> contains
>> >>  module subroutine bar
>> >>    print *, a
>> >>    a = a+1
>> >>  end subroutine
>> >> end submodule
>> >>
>> >> program test
>> >>  use foo
>> >>  call bar
>> >>  call bar
>> >>  call bar
>> >>  call bar
>> >>  call bar
>> >> end program test
>> >>
>> >> Unless 'a' is forced to be TREE_PUBLIC the link stage fails at -O1 and
>> >> above. Is there an alternative to TREE_PUBLIC? If not, what are the
>> >> ramifications of making all module entities TREE_PUBLIC?
>> >
>> > An explanation for the layperson would be great if you don’t mind.
>> >
>> > Damian
>> >
>>
>>
>>
>> --
>> Outside of a dog, a book is a man's best friend. Inside of a dog it's
>> too dark to read.
>>
>> Groucho Marx
>
>
>
>
> --
> Janne Blomqvist



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx