[llvm-commits] [llvm-gcc-4.2] r55796 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

[Chris Lattner]

On Sep 9, 2008, at 1:07 AM, Duncan Sands wrote:
>>> Hi Dale, thinking about this more, I started wondering
>>> why you want to produce llvm.pow and friends at all.
>>> Does it actually bring any advantage?
>>
>> Functionally, no, the point is to get C semantics out of the  
>> optimizers.
>
> Well, given that you have several versions of each routine
> (eg: pow that writes errno, pow that does not write errno
> but uses the rounding mode, pow that does not write errno
> and does not use the rounding mode), that makes for a lot
> of intrinsics!  Don't forget that SimplifyLibcalls performs
> simplifications that apply to all those different pow variants.

If anyone cared enough, this could be modeled by adding additional i1  
arguments to llvm.pow.  There is no need to make multiple different  
intrinsics.

> That said, I think it is useful to distinguish between
> SimplifyLibcalls (SLC) and the rest of the compiler.

Yes, SLC is specific to code that is using the standard C library.  If  
you were writing a compiler for some language which had 'sin' mean  
something unusual, you'd just not run it.

> The SLC pass is special in that it only exists to muck
> around with the standard system library, so it's not
> unreasonable that it recognizes standard library functions.
> It can always be turned off (llvm-gcc has logic for that).

Yes, however, this also isn't sufficient.  GCC has options like -fno- 
builtin-sin or something like that (which disable individual builtins).

There are a couple of ways to handle this.  One way to handle this is  
to completely disable simplifylibcalls (and friends) when any builtin  
is disabled.  Another is to add an intrinsic for every standard C  
function we care about (not very attractive, but possible) and have  
the front-end do the lowering of call to intrinsic.  A third approach  
would be to add a note attribute to functions that are disabled, e.g.  
a "not a builtin function" attribute or something like that.

> So, excluding SLC, what about the rest of the compiler?
>
> Well, ConstantFolding.cpp will constant fold a range of
> libcalls too.  That's not so great - something should be
> done about this (not sure what).  Probably llvm-gcc's
> logic should turn this off too, but it currently doesn't...

Yes, this would require solution #2 or #3 if anyone cared enough.

> The other place is codegen:
> SelectionDAGBuild.cpp turns several things into SDNodes:
> not just pow and cos intrinsics but also functions called
> "cos".  Two comments about this: (1) it implies that the
> llvm intrinsics must be readnone and not readonly; (2) I
> think the recognizing of names like "sin" should be dropped
> and only intrinsics used here (this is maybe what you had in
> mind). Let me explain (1): why an SDNode shouldn't be generated
> unless the function is readnone.  Consider the following
> program:

There are really two issues w.r.t. rounding mode.

1) we don't model it at all in the IR.  Theoretically, we'd like to  
support the C99 pragmas, avoid moving FP operations (like adds) across  
rounding mode changes, etc.

2) in the absence of proper modeling, we aren't always conservative  
about our handling.  For example, you're example of moving a cos  
across a rounding mode change.  However, we already move add/sub/mul/ 
div across rounding mode changes, so I'm not sure how cos is that  
different.

-Chris