[llvm-commits] [llvm] r55638 - /llvm/trunk/include/llvm/Function.h

[Duncan Sands]

> > actually it is theoretically useful to be able to specify readonly  
> > on a
> > call to a function that is not readonly: it means that this particular
> > call doesn't read memory (presumably because the function is being
> > passed a special value for some parameter) even though general calls
> > to it might.
> 
> How do you distinguish that ?

Consider the example of the llvm.log intrinsic.  Suppose you want to
generate this intrinsic for all uses of the log builtin in llvm-gcc.
Since (depending on flags like -fno-math-errno, -ffast-math) the gcc
log builtin may or may not write to memory (errno), and may or may not
read from memory (rounding mode), this could be reflected by defining
llvm.log as:

double llvm.log(double %x, i1 writes_errno, i1 uses_rmode)

This intrinsic cannot be marked readonly or readnone because it
isn't for all inputs.

Now when generating calls to the intrinsic, llvm-gcc can check its
-fno-math-errno and -ffast-math flags and generate a variety of
calls to the llvm intrinsic, with differing attributes:

call double llvm.log(double %x, i1 1, i1 1) ; math-errno and not fast-math
call double llvm.log(double %x, i1 0, i1 1) readonly ; no errno but not fast-math
call double llvm.log(double %x, i1 0, i1 0) readnone ; no errno and no rounding mode

Now you can do LTO on modules compiled with different -f flags and
everything will work out automagically.

Of course this isn't how things are done right now, but they could be
done this way.  It might even be a good idea!  I hope this explains how 
it could be useful to have a readonly/readnone call to a function that
is not itself readonly/readnone.

Ciao,

Duncan.