Link-time resolved constant

[The Cuthour via Gcc]

Previous thread on binutils
https://sourceware.org/pipermail/binutils/2025-January/138334.html

I'd like to hear your opinion.
Can we once again promise that only modified files need to be recompiled?

Re: Link-time resolved constant

[The Cuthour via Gcc]

Thank you.

My plan is to make a higher compatibility version of ELF.
You may be able to call it ELF2.0

RFC: Link-time resolved constant

[The Cuthour via Gcc]

Previous thread on binutils
https://sourceware.org/pipermail/binutils/2025-January/138334.html

I'd like to hear your opinion.
Can we once again promise that only modified files need to be recompiled?

Re: ELF2.0: Linkable struct

[The Cuthour via Gcc]

On 2025/01/31 17:05, Jonathan Wakely wrote:



On Fri, 31 Jan 2025, 06:50 The Cuthour via Gcc, <mailto:gcc@gcc.gnu.org>> wrote:



Suppose we have the following two classes:

=== Vec.h ===
class Vec {
      int x, y, z;
};
=== end Vec.h ===

=== Pix.h ===
class Pix: Vec {
      int r, g, b;
};
=== end Pix.h ===

If we add or remove a member variable in class Vec, it requires
recompiling not only Vec.cc but also Pix.cc. I believe this is
a problem. Pix.o should be relinkable.


To solve this problem, I propose the Linkable struct. The term
Linkable struct is proposed in analogy to Linkable function.
C language can be considered a language of Linkable functions.
C language enhances the relinkability of functions by
compromising the optimization of inline functions. C language
does not need Linkable structs because structures are declared
individually in C. Object-oriented languages need Linkable
structs because classes (structures) are described as
differences from their base classes.

To achieve Linkable structs, I propose the Linkable constant.
This mechanism ensures that certain constants are determined
at link time and is realized by extending the ELF format. The
offsets of structure members are defined in a distributed
manner across object files using these constants, with their
values resolved at link time. The information for calculating
these constants is ideally stored in each object file in
Reverse Polish Notation (RPN) for each symbol. The Linkable
constant is also a compromise concerning the optimization of
inline access to structure members.


It also means that sizeof(Pix) is no longer a constant expression, which 
breaks the rules of the C++ language.


Imagine that Pix.cc contains:

static_assert(sizeof (Pix) <= 12);

The assertion passes when you compile it, but becomes invalid if you 
don't recompile after changing Vec.h


This is not feasible.


I believe that sizeof(Pix) is also a linkable constant. It is a
constant, and its value is determined at link time.

ELF2.0: Linkable struct

[The Cuthour via Gcc]

Suppose we have the following two classes:

=== Vec.h ===
class Vec {
int x, y, z;
};
=== end Vec.h ===

=== Pix.h ===
class Pix: Vec {
int r, g, b;
};
=== end Pix.h ===

If we add or remove a member variable in class Vec, it requires
recompiling not only Vec.cc but also Pix.cc. I believe this is
a problem. Pix.o should be relinkable.


To solve this problem, I propose the Linkable struct. The term
Linkable struct is proposed in analogy to Linkable function.
C language can be considered a language of Linkable functions.
C language enhances the relinkability of functions by
compromising the optimization of inline functions. C language
does not need Linkable structs because structures are declared
individually in C. Object-oriented languages need Linkable
structs because classes (structures) are described as
differences from their base classes.

To achieve Linkable structs, I propose the Linkable constant.
This mechanism ensures that certain constants are determined
at link time and is realized by extending the ELF format. The
offsets of structure members are defined in a distributed
manner across object files using these constants, with their
values resolved at link time. The information for calculating
these constants is ideally stored in each object file in
Reverse Polish Notation (RPN) for each symbol. The Linkable
constant is also a compromise concerning the optimization of
inline access to structure members.

Re: ELF2.0: Linkable struct

[The Cuthour via Gcc]

Hi


struct image
{
   vec2 pos[2];
   std::vector pixels;
};

Now if any of those structs are modified, members added or removed, it would
require recompilation of the whole code that uses it.  This is because the
memory offsets to access the fields change and might fall out of the
displacement range of the processor's instructions.  So to support your idea
the compiler would need to generate worst-case code to access any arbitrary
offsets which will drag down code performance.  The linker would need added
optimizing steps to undo this ... it sounds like a can of worms.


I believe that essentially refers to the inlining and optimization of 
code accessing struct members.


My proposal is simple: "Why not compromise on that for once?"

C language enhances the relinkability of functions by compromising the 
optimization of inline functions.


ELF2.0 enhances the relinkability of struct by compromising the 
optimization of inline access to structure members.

Re: ELF2.0: Linkable struct

[The Cuthour via Gcc]

Hi

On 2025/01/31 18:47, Jonathan Wakely wrote:

On Fri, 31 Jan 2025 at 08:28, The Cuthour  wrote:




On 2025/01/31 17:05, Jonathan Wakely wrote:



On Fri, 31 Jan 2025, 06:50 The Cuthour via Gcc, mailto:gcc@gcc.gnu.org>> wrote:


 Suppose we have the following two classes:

 === Vec.h ===
 class Vec {
   int x, y, z;
 };
 === end Vec.h ===

 === Pix.h ===
 class Pix: Vec {
   int r, g, b;
 };
 === end Pix.h ===

 If we add or remove a member variable in class Vec, it requires
 recompiling not only Vec.cc but also Pix.cc. I believe this is
 a problem. Pix.o should be relinkable.


 To solve this problem, I propose the Linkable struct. The term
 Linkable struct is proposed in analogy to Linkable function.
 C language can be considered a language of Linkable functions.
 C language enhances the relinkability of functions by
 compromising the optimization of inline functions. C language
 does not need Linkable structs because structures are declared
 individually in C. Object-oriented languages need Linkable
 structs because classes (structures) are described as
 differences from their base classes.

 To achieve Linkable structs, I propose the Linkable constant.
 This mechanism ensures that certain constants are determined
 at link time and is realized by extending the ELF format. The
 offsets of structure members are defined in a distributed
 manner across object files using these constants, with their
 values resolved at link time. The information for calculating
 these constants is ideally stored in each object file in
 Reverse Polish Notation (RPN) for each symbol. The Linkable
 constant is also a compromise concerning the optimization of
 inline access to structure members.


It also means that sizeof(Pix) is no longer a constant expression, which
breaks the rules of the C++ language.

Imagine that Pix.cc contains:

static_assert(sizeof (Pix) <= 12);

The assertion passes when you compile it, but becomes invalid if you
don't recompile after changing Vec.h

This is not feasible.


I believe that sizeof(Pix) is also a linkable constant. It is a
constant, and its value is determined at link time.



C++ requires constant expressions to be known during compilation, not
at link time.


A constant that is not determined at compile-time is akin to
constructor that is const but not constexpr. While it remains
constant throughout the program, its value is established only
at link-time, not at compile-time.

Re: ELF2.0: Linkable struct

[The Cuthour via Gcc]

Hi


C++ requires constant expressions to be known during compilation, not
at link time.


A constant that is not determined at compile-time is akin to
constructor that is const but not constexpr. While it remains
constant throughout the program, its value is established only
at link-time, not at compile-time.


That is not valid.
http://eel.is/c++draft/expr.sizeof#note-3
says that sizeof is an integral constant expression, so it can be used in
consteval or constexpr function constant evaluation or in constant
expressions.  You can't defer that to link time evaluation, the exact
values of the constant expressions may affect which templates are
instantiated etc., you'd basically need to defer all the compilation until
link time then.


I understand the concerns about the C++ standard requiring constant
expressions to be known during compilation. However, my proposal for
link-time evaluation offers significant flexibility and efficiency
improvements that could address current limitations in compile-time
constant expressions.

To ensure compatibility with existing C++ standards, we could:

1. Introduce a hybrid approach where essential constant expressions
are still resolved at compile-time, while less critical ones can be
deferred to link-time.

2. Provide clear guidelines and use cases for when and how link-time
constants should be used to avoid impacting template instantiation.

I believe this approach balances the advantages of link-time flexibility
with the needs of compile-time constant evaluations. I'd be happy to
discuss this further with specific examples and implementation
strategies.

To be honest, I currently have no intention of using link-time constants
for purposes other than the following:

--
struct Vec {
int x, y, z;
};

struct Pix : Vec {
int r, g, b;
};
--
|
|
V
--

// Linkable constant
int __offset_of_x_in_Pix = __offset_of_x_in_Vec;
int __offset_of_y_in_Pix = __offset_of_y_in_Vec;
int __offset_of_z_in_Pix = __offset_of_z_in_Vec;
int __offset_of_r_in_Pix = __sizeof_Vec;
int __offset_of_g_in_Pix = __offset_of_r_in_Pix + __sizeof_int;
int __offset_of_b_in_Pix = __offset_of_g_in_Pix + __sizeof_int;
int __sizeof_Pix = __offset_of_b_in_Pix + __sizeof_int;

--

Re: Link-time resolved constant

[The Cuthour via Gcc]

And I heard "That's already here. ELF gABI does the same thing."
Anyway I can't implement it myself. I hope wide discussion.
https://gcc.gnu.org/pipermail/gcc/2025-January/245358.html


On 2025/01/08 22:08, Trampas Stern wrote:

Go do it!
Do it so well and with such high quality that no one can ignore the 
results!


On Tue, Jan 7, 2025 at 1:26 PM The Cuthour > wrote:


Thank you.

My plan is to make a higher compatibility version of ELF.
You may be able to call it ELF2.0