On Fri, 12 Oct 2012, Jason Merrill wrote:
> > Consider instead the following expansion:
> >
> > __thread void (*i_initialize)(void) = i_init;
>
> That would work too, though it wouldn't have the benefit of link-compatibility
> with __thread (for variables that don't need dynamic initialization)
On 10/11/2012 03:48 PM, Alexandre Oliva wrote:
This is not entirely clear to me; where is i defined in the first place?
Um, it's defined where the user writes the definition, like any other
variable.
Is it i_init that defines and tests i_initialized?
Yes.
Consider instead the following
On Oct 11, 2012, Jason Merrill wrote:
> On 10/11/2012 11:14 AM, Alexandre Oliva wrote:
>> How about marking the singleton containing the call to the initializer
>> as always_inline, but not the initializer itself?
>>
>> The compiler can then infer that initialized is set on the first inlined
>>
On 10/11/2012 11:14 AM, Alexandre Oliva wrote:
How about marking the singleton containing the call to the initializer
as always_inline, but not the initializer itself?
The compiler can then infer that initialized is set on the first inlined
call and optimize away subsequent tests and initializer
On Oct 3, 2012, Jason Merrill wrote:
> int& lazy_i()
> {
> static int i = init;
> return i;
> }
> If the initialization is expensive or order-sensitive, this is a
> useful alternative to initialization on load
> An interesting property of such functions is that they only have
> side-effect
On 10/05/2012 04:20 PM, Xinliang David Li wrote:
So init () will be unconditionally called on entry to the wrapper?
In that case, you should probably go to the other extreme -- mark the
wrapper as noinline and expanded as if they are builtins -- but run
into the tricky issues of 'attributes' as
On Fri, Oct 5, 2012 at 1:12 PM, Jason Merrill wrote:
> On 10/05/2012 03:46 PM, Xinliang David Li wrote:
>>
>> 1) As mentioned in this thread -- when the wrapper is inlined, the
>> pure attribute will be lost. It will give compiler hard time to
>> optimize away the guard code
>
>
> The wrapper does
On 10/05/2012 03:46 PM, Xinliang David Li wrote:
1) As mentioned in this thread -- when the wrapper is inlined, the
pure attribute will be lost. It will give compiler hard time to
optimize away the guard code
The wrapper doesn't actually check the guard; that happens in the init
function, whic
The semantics of the 'first' reference of the TLS variable has
changed, and this change is introduced by the implementation. It is no
longer safe to do DCE as
thread_local int x = ..;
int foo()
{
x;
...
}
but should be safe to do DSE as
int foo()
{
x = ...; // Dead
x = ...;
..
}
On 10/05/2012 04:46 AM, Richard Guenther wrote:
Ok, so then let me make another example to try breaking a valid program
with the thread_local wrapper being pure:
There is also my example earlier in the thread.
i;
if (init_count != 1)
__builtin_abort ();
is that valid?
I believe
On Thu, Oct 4, 2012 at 8:02 PM, Jason Merrill wrote:
> On 10/04/2012 01:42 PM, Richard Guenther wrote:
>>
>> So I suppose the testcase that would be "valid" but break with using
>> pure would be instead
>>
>> int main()
>> {
>>int x = init_count;
>>int *p = get_me();
>>if (init_count =
On 10/04/2012 01:42 PM, Richard Guenther wrote:
So I suppose the testcase that would be "valid" but break with using
pure would be instead
int main()
{
int x = init_count;
int *p = get_me();
if (init_count == x)
__builtin_abort();
int *q = get_me();
if (init_count == x)
On Thu, Oct 4, 2012 at 7:15 PM, Jakub Jelinek wrote:
> On Thu, Oct 04, 2012 at 07:08:02PM +0200, Richard Guenther wrote:
>> But isn't it a fact that it _cannot_ modify init_count? If the second call
>> is CSEable then it cannot have side-effects that are observable at
>> the call site. Is the fo
On 10/04/2012 01:15 PM, Richard Guenther wrote:
That is, I am confused about the distinction you seem to make between
the static variable 'initialized' and the global 'init_count'.
The distinction is that "initialized" is an implementation detail that
once set is never cleared; it is the mecha
On Thu, Oct 04, 2012 at 07:08:02PM +0200, Richard Guenther wrote:
> But isn't it a fact that it _cannot_ modify init_count? If the second call
> is CSEable then it cannot have side-effects that are observable at
> the call site. Is the following an example you would consider to fall
> under your
On Thu, Oct 4, 2012 at 7:08 PM, Richard Guenther
wrote:
> On Thu, Oct 4, 2012 at 5:22 PM, Jason Merrill wrote:
>> On 10/04/2012 09:07 AM, Richard Guenther wrote:
>>>
>>> Ugh. Especially with the above (you can DCE those calls) makes this
>>> severly mis-specified ... and any implementation error
On Thu, Oct 4, 2012 at 5:22 PM, Jason Merrill wrote:
> On 10/04/2012 09:07 AM, Richard Guenther wrote:
>>
>> Ugh. Especially with the above (you can DCE those calls) makes this
>> severly mis-specified ... and any implementation error-prone (look what
>> mess our losely defined 'malloc' attribute
On 10/04/2012 09:07 AM, Richard Guenther wrote:
Ugh. Especially with the above (you can DCE those calls) makes this
severly mis-specified ... and any implementation error-prone (look what
mess our losely defined 'malloc' attribute opened ...).
I thought of a testcase like
int *p = get_me ();
On Thu, Oct 4, 2012 at 2:56 PM, Jason Merrill wrote:
> On 10/04/2012 08:45 AM, Jakub Jelinek wrote:
>>
>> On Thu, Oct 04, 2012 at 10:42:59AM +0200, Richard Guenther wrote:
>>>
>>> On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill wrote:
>>> If the result is not needed, are we allowed to remove a call
On Thu, Oct 04, 2012 at 08:56:03AM -0400, Jason Merrill wrote:
> >I think the plan was for these functions not to return any value,
>
> No, I'm talking about the wrapper function which returns a reference
> to the variable (as in my example).
Sure, but I thought you want to inline the wrapper fun
On 10/04/2012 08:45 AM, Jakub Jelinek wrote:
On Thu, Oct 04, 2012 at 10:42:59AM +0200, Richard Guenther wrote:
On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill wrote:
If the result is not needed, are we allowed to remove a call to this
function?
No. Unless you know the same function has been al
On Thu, Oct 04, 2012 at 10:42:59AM +0200, Richard Guenther wrote:
> On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill wrote:
> If the result is not needed, are we allowed to remove a call to this
> function?
No. Unless you know the same function has been already called.
> So - what's wrong with usi
On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill wrote:
> In C++ there is a common idiom called "initialize on first use". In its
> simplest form it looks like
>
> int& lazy_i()
> {
> static int i = init;
> return i;
> }
>
> If the initialization is expensive or order-sensitive, this is a useful
On 10/03/2012 07:06 PM, Joseph S. Myers wrote:
On Wed, 3 Oct 2012, Jason Merrill wrote:
My implementation of dynamic initialization of TLS variables as mandated by
the C++11 and OpenMP standards uses this idiom implicitly, so I'd really like
to be able to optimize away multiple calls.
I'd tho
On Wed, 3 Oct 2012, Jason Merrill wrote:
> My implementation of dynamic initialization of TLS variables as mandated by
> the C++11 and OpenMP standards uses this idiom implicitly, so I'd really like
> to be able to optimize away multiple calls.
I'd thought that dynamic initialization of TLS varia
In C++ there is a common idiom called "initialize on first use". In its
simplest form it looks like
int& lazy_i()
{
static int i = init;
return i;
}
If the initialization is expensive or order-sensitive, this is a useful
alternative to initialization on load
(http://www.parashift.com/c++
26 matches
Mail list logo
