[Info-vax] LLVM, volatile and async VMS I/O and system calls

[John Reagan]

On Wednesday, September 22, 2021 at 4:26:00 PM UTC-4, Simon Clubley wrote:
> On 2021-09-22, Bob Gezelter <geze... at rlgsc.com> wrote: 
> > Simon, 
> >
> > Good technical question. 
> > 
> > In general, optimizers work within basic blocks. The example of concern is not a single basic block. 
> > 
> > A basic block is a section of code with one entry and one exit. Simple IF statements fall within that category. However, any out-of-line code invocation does not. 
> > 
> > The presence of the SYS$QIO system service, which one way or another involves a CALL, ends the basic block, as the optimizer cannot know what is modified by the out-of-line call or its descendants. 
> >
> But VMS writes directly into your process space at some random time 
> X later _after_ you have returned from sys$qio() and are potentially 
> busy doing something else. 
> 
> From the viewpoint of the application, it's exactly the same as hardware 
> choosing to write an updated value into a register while your bare-metal 
> code is busy doing something else. 
> 
> How does the compiler know VMS has done that or are there enough 
> sequence points even in the VMS asynchronous I/O model for this 
> to still work fine without having to use the volatile attribute, 
> even in the presence of an highly aggressive optimising compiler ?
> Simon. 
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP 
> Walking destinations on a map are further away than they appear.

So LLVM and gcc are good optimizers.  They battle with each other all the time for everybody's benefit.  However, GEM is a pretty good optimizer too.  Alpha GEM code is really good.  It started wobbly with EV4 but grew into a tight code generator.  GEM Itanium does not take advantage of the machines speculative or advance loads which puts it behind the HPUX compiler but it holds its own.

LLVM's has many optimization passes for specific targets.  The whole list is not run on every target.

For LLVM, it is way more than just "volatile" loads and stores.  Optimizers need way more than that.  For LLVM, look at

https://llvm.org/docs/AliasAnalysis.html
https://llvm.org/docs/Passes.html
https://llvm.org/docs/Atomics.html
https://llvm.org/docs/LangRef.html#tbaa-metadata
https://llvm.org/docs/MemorySSA.html


BTW, GEM also has a TBAA mechanism which uses callbacks from GEM back to the frontend to ask about alias-information.  It allows the alias analysis to be specific to the language semantics.