Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?

2007-10-15 Thread Darryl Miles
Andrew Haley wrote: This doesn't sound very different from the small memory model. With the small model, the program and its symbols must be linked in the lower 2 GB of the address space, but pointers are still 64 bits. This is the default model for gcc on GNU/Linux. It would be possible in th

Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?

2007-10-15 Thread Darryl Miles
Andrew Haley wrote: Darryl Miles writes: > Andrew Haley wrote: > I'm not aware of a small memory model until now, let alone that I maybe > actually using it already and that its already what I'm making an > inquiry about. Reading the gcc documentation would h

Re: Optimization of conditional access to globals: thread-unsafe?

2007-10-27 Thread Darryl Miles
Comments inline below v Tomash Brechko wrote: Consider this piece of code: extern int v; void f(int set_v) { if (set_v) v = 1; } f: pushl %ebp movl%esp, %ebp cmpl$0, 8(%ebp) movl$1, %e

Re: Optimization of conditional access to globals: thread-unsafe?

2007-10-27 Thread Darryl Miles
Dave Korn wrote: On 27 October 2007 18:27, Darryl Miles wrote: The "unintended write-access" optimization is a massive headache for developers of multi-threaded code. But it's a boon for the autovectoriser, because it means it can transform code with a branch into straight-li

Re: Optimization of conditional access to globals: thread-unsafe?

2007-10-28 Thread Darryl Miles
David Miller wrote: The compiler simply cannot speculatively load or store to variables with global visibility. s/with global visibility/with visibility outside the scope of the functional unit the compiler is able to see at compile time/ Which basically means the compiler is king for doing

Re: Optimization of conditional access to globals: thread-unsafe?

2007-10-29 Thread Darryl Miles
David Miller wrote: From: Darryl Miles <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 04:53:49 + What are the issues with "speculative loads" ? The conditional might be protecting whether the pointer is valid and can be dereferenced at all. This then leads into the questio

Re: Optimization of conditional access to globals: thread-unsafe?

2007-10-29 Thread Darryl Miles
skaller wrote: Ah .. ok I think I finally see. Thanks! The code ensures well definedness by checking the establishment of the required invariant and dynamically chosing whether or not to do the access on that basis .. and the optimisation above defeats that by lifting the access out of the condit

Re: Optimization of conditional access to globals: thread-unsafe?

2007-10-29 Thread Darryl Miles
Michael Matz wrote: if (condition) *p = value; (i.e. without any synchronization primitive or in fact anything else after the store in the control region) and expect that the store indeed only happens in that control region. And this expectation is misguided. Had they written it like:

Re: Optimization of conditional access to globals: thread-unsafe?

2007-10-29 Thread Darryl Miles
Michael Matz wrote: Don't you need the barrier before. This is to ensure it completed the condition test completely first before it then processed the assignment expression. if(condition) { somebarrier(); *p = value; } The issue is not that the store is done too late, but that a write-acces