[Simh] clang (was Re: XCode and LTO)

[Sergey Oboguev]

Hi Mark,

The goal is to prevent smart compiler from collapsing the loops in  
rom_read_delay, especially the bottom loop, by optimizing them.
Declaring "loopval" as volatile does just that, by effectively disabling  
compiler's capability to optimize, and does it in a portable way.

Disabling inlining of rom_swapb, in fact, does not provide such guarantee long 
term.
It may shut off compiler's optimizations today, but once the compiler  (or 
compilers) gets even smarter in the future, it can some day figure  out the code 
"does not need" to call rom_swapb.
Compiler may leave the function un-inlined, but just figure out it does  not 
need to be called and optimize the whole loop construct away.

Therefore volatile is both portable and -- long-term -- safer approach.
The caveat is, compilers do have bugs and can sometimes disregard volatile 
declaration.
See for ex. "Volatiles Are Miscompiled, and What to Do about It"
http://dl.acm.org/citation.cfm?id=1450093
Note that in older versions of LLVM used to be a particularly bad  offender, 
miscompiling (in LLVC-GCC version 2.2) 19% of volatile  references, however it 
got better since then.

So when using volatile it's worth to take some extra steps that reduce  
probability of triggering compiler's bug, particularly avoiding  declaring 
variable in question as local scope.
Or, perhaps even better, what Eide & Regehr suggest in the mentioned article: 
instead of  accessing variable directly, perform accesses via via per-type 
accessor  routines. Or both.

Thanks,
Sergey


----- Original Message ----
From: Mark Pizzolato - Info Comm <Mark at infocomm.com>
To: Craig A. Berry <craigberry at mac.com>; Mark Pizzolato - Info Comm 
<Mark at infocomm.com>
Cc: Sergey Oboguev <oboguev at yahoo.com>; "simh at trailing-edge.com" 
<simh at trailing-edge.com>
Sent: Fri, April 27, 2012 1:36:48 PM
Subject: RE: [Simh] clang (was Re:  XCode and LTO)

On Friday, April 27, 2012, at 1:15 PM, Craig A. Berry wrote:
> On Apr 27, 2012, at 2:52 PM, Mark Pizzolato - Info Comm wrote:
> 
> > On Friday, April 27, 2012, at 10:44 AM, Sergey Oboguev wrote:
> >> Declaring "loopval" as volatile (and perhaps global, rather than
> >> on-stack, to reduce chances of compiler disregarding volatile
> >> declaration) might do the trick.
> >
> > The goal really isn't to cause a memory reference, but really to avoid the
> inlining on this specific function.  We're trying to do enough 'spinning' to 
>slow
> things down predictably here.
> 
> Doesn't it amount to the same thing?  If the function gets inlined, then a
> subsequent optimization step may realize loopval never changes and
> eliminate even the inlined function calls.  Preventing inlining prevents that.
> But making loopval volatile is like saying it's a device register or something
> that can be changed from outside of the program, right?  So that also
> prevents it from optimizing out references to loopval (even if the function 
>it's
> passed to gets inlined) since the compiler doesn't know when it might
> change.  This is speculative as I haven't tried to analyze any assembler 
>listings
> (and they don't always reflect exactly what the optimizer did), but I suspect
> that's the gist of it.

I guess, in the end it either way is OK (as long as the variable is global as 
Sergey suggested).  I'm checking in that version.

> In other words, I'm not sure if it matters much which way we go, especially
> since I *think* this code is just involved with spinning up the virtual ROM 
and
> doesn't do much after the simulator is up and running.

It's only purpose is to allow the ROM diagnostics to pass which will then let 
the
ROM believe that the hardware is in good enough shape to allow the system to 
boot.
If a powerup diag fails, the ROM won't allow a boot.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120427/8a0aa55b/attachment-0002.html>