[llvm-commits] [llvm-gcc-4.2] r55783 - in /llvm-gcc-4.2/trunk/gcc: llvm-convert.cpp llvm-internal.h

Dale Johannesen dalej at apple.com
Thu Sep 4 13:51:18 PDT 2008


On Sep 4, 2008, at 1:23 PMPDT, Duncan Sands wrote:

>>> Hi Dale, since the llvm intrinsics are presumably readnone
>>> (hence don't set errno, and don't read the floating point
>>> mode - so they are what you want in "fast math" mode) shouldn't
>>> these expansions only be done if the gcc builtins are marked
>>> "const"?  IIRC, gcc marks these builtins "const" or "readonly"
>>> depending on platform requirements and whether fast-math is
>>> being used.
>>
>> You may be right.  The way sqrt is handled maybe?
>
> Well, I think it's important to check the gcc builtin's "pureness"
> against that of the llvm intrinsic, since turning (for example)
> a "pure" (readonly) gcc builtin into a readnone ("const") llvm
> intrinsic seems like a clear no-no, whether fast-math is set or
> not.  This will automagically take care of no-errno math, since
> gcc adjusts the builtin's attributes based on whether that flag
> is set or not (IIRC; easy to check by playing with flags and
> seeing what attributes are output into the bitcode if you don't
> convert them into llvm intrinsics).  There's also the question of
> whether the llvm intrinsics pre-suppose fast-math, i.e. whether using
> the intrinsics is telling the code-generators that can make
> fast-math assumptions.  I don't think that's the case, so there
> should be no need to check the fast-math flag.

My view is that the intrinsic just means "this has the semantics of  
log2 (etc.) in C".
I think it's wrong for the back end to be keying off the C names; not  
all languages
are C, not all dialects are C99, and not all environments are hosted.

Thus I'd prefer to leave errno checking to the back end as well, but  
since Darwin
never sets errno it's not a big deal here, and I'm OK with checking it  
as part of
the conversion if you want.  There is precedent with sqrt.  I did mark  
the intrinsics
as IntrNoMem, so it needs to be checked somewhere (or that needs to be  
changed).

I don't intend this to have any connection with -ffast-math.




More information about the llvm-commits mailing list