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

[Devang Patel]

On Sep 24, 2008, at 3:05 AM, Duncan Sands wrote:

>>> 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.


The pass that updates readonly and readone status can look at call  
llvm.log parameters and do the right thing.
-
Devang