> Quoting Jan Hubicka :
>
>> The behaviour change is about COMDAT functions that are larger than call
>> overhead but either called just once or small enough so code growth caused
>> by inlining is smaller than the function body size itself. In these cases
>> we made the assumption that overall pr
Quoting Jan Hubicka :
The behaviour change is about COMDAT functions that are larger than call
overhead but either called just once or small enough so code growth caused
by inlining is smaller than the function body size itself. In these cases
we made the assumption that overall program size wi
> Quoting Richard Guenther :
>
>> That is, we no longer optimistically assume that comdat functions
>> can be eliminated if there are no callers in the local TU in 4.5
>> (but we did in previous releases).
>
> But if the function is very simple, the only reason to keep it would be
> if its address
On Fri, Jul 2, 2010 at 4:06 PM, Frank Ch. Eigler wrote:
> Joern Rennecke writes:
>
>> [...] But if the function is very simple, the only reason to keep
>> it would be if its address was taken somewhere, or if we tailcall
>> it.
>
> ... or to make it available from gdb as an inferior call.
We do
Joern Rennecke writes:
> [...] But if the function is very simple, the only reason to keep
> it would be if its address was taken somewhere, or if we tailcall
> it.
... or to make it available from gdb as an inferior call.
- FChE
Taras Glek wrote:
On 07/01/2010 02:45 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 11:36 PM, Taras Glek wrote:
On 07/01/2010 02:27 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glekwrote:
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual si
Quoting Richard Guenther :
That is, we no longer optimistically assume that comdat functions
can be eliminated if there are no callers in the local TU in 4.5
(but we did in previous releases).
But if the function is very simple, the only reason to keep it would be
if its address was taken some
On 07/01/2010 02:45 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 11:36 PM, Taras Glek wrote:
On 07/01/2010 02:27 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glekwrote:
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where
On Thu, Jul 1, 2010 at 11:36 PM, Taras Glek wrote:
> On 07/01/2010 02:27 PM, Richard Guenther wrote:
>>
>> On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
>>>
>>> On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where -Os is losing size and
spee
On 07/01/2010 02:27 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where -Os is losing size and speed
we can try
to do something about them.
According to our code size reports,
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
> On 06/30/2010 03:06 PM, Jan Hubicka wrote:
>>
>> If you can find actual simple examples where -Os is losing size and speed
>> we can try
>> to do something about them.
>>
>
> According to our code size reports, inlining is completely screwed for
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where -Os is losing size and speed we
can try
to do something about them.
According to our code size reports, inlining is completely screwed for
C++ wrapper classes like ones often used for smart pointers, arr
12 matches
Mail list logo
