llvm build bez inline funkcija

[klemo]

ej ekipa,

za profiling clang-a mi treba build platforme bez optimiranja
inline funkcija. Ovo mi baš ne radi:

CFLAGS="-fno-inline -fno-default-inline" CXXFLAGS="-fno-inline
-fno-default-inline" ../llvm/configure

ima li tko ideju kako to napravit?

tnx,
klemo.

[Alan Pavičić]

>
> ima li tko ideju kako to napravit?
>

ne baš, ali da vidim da li sam dobro shvatio pitanje -- ti pitaš kako
zbildati clang/llvm tako da nemaju inline fje, a ne kako pomoću njih
zbildati program koji nema inline, right?

--aka

[klemo]

Da, zanima me isključivo run-time profile samog clanga, npr.

valgrind --tool=callgrind clang test.cpp

bez obzira što je test.cpp, želim call-graph od samog procesa
kompilacije. Jedini problem su inline funkcije za koje se ne mogu
referencirati na kod kao kod običnih funkcija kad analiziram graf
poziva.

>
> --aka
>
> --
> You received this message because you are subscribed to the Google Groups "lang gang" group.
> To post to this group, send email to lang...@googlegroups.com.
> To unsubscribe from this group, send email to lang-gang+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lang-gang?hl=en.
>

[Marin Saric]

Mislim da ti je problem što je compiler koji slijedi ISO C++ dužan raditi inline određenih funkcija. Npr. accessori i slične funkcije definirane unutar same deklaracije moraju biti kompajlirane kao inline. Također sve što je navedeno kao "inline" mora biti inlineano ili se kompajler mora svojski pretvarati kao da je to inlineano. Za picajzle, vidjeti [dcl.fct.spec] u ISO/IEC 14882:2011.

Inlining je također i optimizacijska tehnika nevezana uz sam jezični standard. Npr. ako je tijelo funkcije kratko, ono se može inlineati u drugu funkciju ako kompajler procjeni da će to ubrzati izvođenje koda. 

Inlineing kod optimizacije se može gasiti, ali ne vjerujem da možeš ugasiti recimo inline svih funkcija deklariranih unutar deklaracije za klasu (7.1.2.1 u standardu, za picajzle).

Ako se može, i ja bi volio znati kako :-)

  Marin

2012/3/9 klemo <klemo.v...@gmail.com>

[Nebojsa Vujnovic]

Tvrdnja kompajer je duzan inline, malo je pre optimistična :)

Evo 7.1.2.2 iz standarda

A function declaration (8.3.5, 9.3, 11.4) with an inline specifier
declares an inline function. The inline
specifier indicates to the implementation that inline substitution of
the function body at the point of call is
to be preferred to the usual function call mechanism. An
implementation is not required to perform this
inline substitution at the point of call; however, even if this inline
substitution is omitted, the other rules for
inline functions defined by 7.1.2 shall still be respected.

Znaći naglasak je na preferred.

Sto se tice member funkcija definiranih u scopu definicije klase, one
sve imaju implicitno decl specf. inline.

Lijep pozdrav

On 10 ožu, 14:02, Marin Saric <marin.sa...@gmail.com> wrote:
> Mislim da ti je problem što je compiler koji slijedi ISO C++ dužan raditi
> inline određenih funkcija. Npr. accessori i slične funkcije definirane
> unutar same deklaracije moraju biti kompajlirane kao inline. Također sve
> što je navedeno kao "inline" mora biti inlineano ili se kompajler mora
> svojski pretvarati kao da je to inlineano. Za picajzle, vidjeti
> [dcl.fct.spec] u ISO/IEC 14882:2011.
>
> Inlining je također i optimizacijska tehnika nevezana uz sam jezični
> standard. Npr. ako je tijelo funkcije kratko, ono se može inlineati u drugu
> funkciju ako kompajler procjeni da će to ubrzati izvođenje koda.
>
> Inlineing kod optimizacije se može gasiti, ali ne vjerujem da možeš ugasiti
> recimo inline svih funkcija deklariranih unutar deklaracije za klasu
> (7.1.2.1 u standardu, za picajzle).
>
> Ako se može, i ja bi volio znati kako :-)
>   Marin
>

> 2012/3/9 klemo <klemo.vladi...@gmail.com>

[Marin Saric]

Spomenuo sam da će se kompajler morati svojski pretvarati da funkcije izgledaju inlineane. Evo baš na tom 7.1.2.2 sam uočio "even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected." Znači, to je onaj dio da ako kompajler izabere da ne inline-a funkciju, mora poštovati ostala pravila iz 7.1.2, tj. truditi se da sve i dalje izgleda kao da radiš sa inline funkcijom.

To je ponajprije 7.1.2.4 (boldanje moje):

2. An inline function shall be defined in every translation unit in which it is odr-used and shall have exactly the same definition in every case (3.2).

Ovaj dio 3.2 je objašnjenje koncepta odr (one definition rule) i pripadajućeg termina odr-used. E sad, sad pod pojašenjenje odr, ima stavka 3.2.3, boldanje je moje:

1. Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the standard or a user-defined library, or (when appropriate) it is implicitly defined (see 12.1, 12.4 and 12.8). An inline function shall be defined in every translation unit in which it is odr-used. 

Znači funkcije koje su deklarirane kao inline će ti se u najmanju ruku pojaviti u svakom translation unitu, tj. narodski, u svakom .o fajlu u kojemu se spominju. Ako kao kompajler slučajno ne možeš tu funkciju inlineati svejedno ćeš morati u svakom .o fajlu u kojem bilo tko poziva inline funkciju sintetizirati kod za nju, i eventualno dodijeliti joj pripadajući simbol (a taj simbol će zbog linkera morati biti različiti za svaki .o fajl).

Problem s praćenjem ponašanja programa je onda što će poziv inlineanoj funkciji završiti na jednoj od tko zna koliko kopija tih funkcija ovisno u koliko se različitih translation unita ona spomenula. Sad sve ovisi o debug simbolima koji su emitirane uz kopije tih inline funkcija, ali ne vidim zašto bi se tu kompajler ponašao imalo drugačije nego kao i kod normalnog inlineanja, znači po meni rekonstrukcija call stacka s normalnim alatima i dalje ima poprilično problema:

 imaš kopije jedne funkcije po programskom kodu. Prepušten si na milost i nemilost debug simbolima, kao i u normalnom slučaju kad kompajler napravi inline, ali definitivno nećeš imati slučaj gdje će ti ta funkcija magično postati "normalna" pa da se za nju definira jedan simbol po cijelom programu koji se onda lako može lookupati kad pogledaš stack frame.

2012/3/10 Nebojsa Vujnovic <nvuj...@inet.hr>

[Nebojsa Vujnovic]

Ok, samo kažem da nije dužan napraviit inline kako kod recimo
__forceinline (MS ovog exstensiona
znam da i gcc ima nesto tako ali mi se neda trazit) to se odnosilo na
ovaj dio "dužan napraviti inline"
što se ostalog tiće to stoji.

On 10 ožu, 16:24, Marin Saric <marin.sa...@gmail.com> wrote:
> Spomenuo sam da će se kompajler morati svojski pretvarati da funkcije
> izgledaju inlineane. Evo baš na tom 7.1.2.2 sam uočio "even if this inline
> substitution is omitted, the other rules for inline functions defined by
> 7.1.2 shall still be respected." Znači, to je onaj dio da ako kompajler
> izabere da ne inline-a funkciju, mora poštovati ostala pravila iz 7.1.2,
> tj. truditi se da sve i dalje izgleda kao da radiš sa inline funkcijom.
>
> To je ponajprije 7.1.2.4 (boldanje moje):
>

>    1.
>
>    An inline function *shall be defined in every translation unit* in which

>    it is odr-used and shall have exactly the same definition in every case
>    (3.2).
>
> Ovaj dio 3.2 je objašnjenje koncepta odr (one definition rule) i
> pripadajućeg termina odr-used. E sad, sad pod pojašenjenje odr, ima stavka
> 3.2.3, boldanje je moje:
>

>    1.
>
>    Every program shall contain *exactly one definition* of every *non-inline
>    * function or variable that is odr-used in that program; no diagnostic

>    required. The definition can appear explicitly in the program, it can be
>    found in the standard or a user-defined library, or (when appropriate)

>    it is implicitly defined (see 12.1, 12.4 and 12.8). An *inline
> function*shall be defined in every translation unit in which it is

> odr-used.
>
> Znači funkcije koje su deklarirane kao inline će ti se u najmanju ruku
> pojaviti u svakom translation unitu, tj. narodski, u svakom .o fajlu u
> kojemu se spominju. Ako kao kompajler slučajno ne možeš tu funkciju
> inlineati svejedno ćeš morati u svakom .o fajlu u kojem bilo tko poziva
> inline funkciju sintetizirati kod za nju, i eventualno dodijeliti joj
> pripadajući simbol (a taj simbol će zbog linkera morati biti različiti za
> svaki .o fajl).
>
> Problem s praćenjem ponašanja programa je onda što će poziv inlineanoj
> funkciji završiti na jednoj od tko zna koliko kopija tih funkcija ovisno u
> koliko se različitih translation unita ona spomenula. Sad sve ovisi o debug
> simbolima koji su emitirane uz kopije tih inline funkcija, ali ne vidim
> zašto bi se tu kompajler ponašao imalo drugačije nego kao i kod normalnog
> inlineanja, znači po meni rekonstrukcija call stacka s normalnim alatima i
> dalje ima poprilično problema:
>  imaš kopije jedne funkcije po programskom kodu. Prepušten si na milost i
> nemilost debug simbolima, kao i u normalnom slučaju kad kompajler napravi
> inline, ali definitivno nećeš imati slučaj gdje će ti ta funkcija magično
> postati "normalna" pa da se za nju definira jedan simbol po cijelom
> programu koji se onda lako može lookupati kad pogledaš stack frame.
>

> 2012/3/10 Nebojsa Vujnovic <nvujn...@inet.hr>